並列クエリを実行するPostgreSQLのアーキテクチャ

並列クエリを実行する
PostgreSQLのアーキテクチャ
The PG-Strom Project
KaiGai Kohei <kaigai@kaigai.gr.jp>

PostgreSQL v9.6の目玉機能
Database Lounge Tokyo #1 - The architecture of PostgreSQL to run parallel queries2
パラレルクエリ
並列にクエリを処理すること

本日のアジェンダ
▌先史時代 (~v9.2)
▌要素技術 (v9.3~v9.5)
▌並列クエリの実現 (v9.6)
▌今後の動向 (v9.7~)
▌お知らせとお願い

fork(2)
accept(2)
PostgreSQLのアーキテクチャ (1/3) – postmasterと子プロセス
▌マルチプロセス
 1プロセス：1スレッド
 プロセス内に閉じた処理であれば、
同期/排他を考える必要なし
▌postmasterの役割
 PostgreSQL起動時の初期化
 共有メモリ、ロック、管理構造体、etc...
 accept(2)してfork(2)
 子プロセスの動作状況を管理
postmaster
bgwriter
autovacuum
backend
backend
backend
backend
walwriter
shared memory
storage

▌子プロセスの上限
 max_connections + max_workers
 PGPROC配列他、プロセス管理に
必要なデータ構造を初期化時に
確保するため。
 サイジング的観点も。
▌例：PGPROC配列
 pid、ラッチ、待機中ロック等を含む
 postmasterや他のbackendが、
並行プロセスの状態を知る。
postmaster
bgwriter
autovacuum
backend
backend
backend
backend
walwriter
pg_ctl
NUM_AUXILIARY_PROCS MaxBackends
SIGTERM
SIGTERM
PGPROC配列

▌子プロセスの上限
 max_connections + max_workers
 PGPROC配列他、プロセス管理に
必要なデータ構造を初期化時に
確保するため。
 サイジング的観点も。
▌例：PGPROC配列
 pid、ラッチ、待機中ロック等を含む
 postmasterや他のbackendが、
並行プロセスの状態を知る。
postmaster
bgwriter
autovacuum
backend
backend
backend
backend
walwriter
NUM_AUXILIARY_PROCS MaxBackends
SIGCHLD
Crash
reaper
SIGQUIT

fork(2)
accept(2)
postmasterと子プロセス – 先史時代 (~v9.2以前)
postmaster
bgwriter
autovacuum
backend
backend
backend
backend
walwriter
shared memory
storage
特定用途の
ワーカープロセス
PostgreSQLの
ユーザセッションに対応
“何か”をするために
ワーカープロセスを
起動する事ができなかった。
(....自分でインフラを作れば別だけど....)

拡張モジュールだって非同期処理がしたい！ (1/2)
拡張モジュール独自の
処理を行うワーカープロセス
DB Tech Showcase 2014/Tokyo 発表資料より

拡張モジュールだって非同期処理がしたい！ (2/2)
To: pgsql-hackers
拡張モジュールが独自にワーカーを
定義できるよう、postmasterを拡張して
みました。いかがなものでしょ？
From: Alvaro Herrera
同感。Windows対応機能とかが必要な
ので、Simonが送ってくれたパッチと併
せて作り直してみました。
2012年4月頃：
To: pgsql-hackers
ありがとうございます。じゃあ、私は
レビューの方で協力させてください。
(FDWのタスクもあるので....)
と、いった話もあり、、、
PgSQL 9.3
新機能

並列クエリの実現に向けて – 必要な要素技術
▌オンデマンドでワーカープロセスを起動する
 Dynamic background worker
▌バックエンドプロセス～ワーカープロセス間で通信する
 Dynamic shared memory
 Shared memory message queue / Shared memory table of contents
▌一貫したトランザクションのイメージを使用する
 Parallel context
▌処理を複数のワーカーに分割し、後で集約する
 Gather node & Partial SeqScan
 Plan Serialization / Deserialization
▌並列処理を意識したクエリ実行計画
 Optimizer enhancement
 Upper Path Optimization
▌拡張モジュールとの連携
 FDW/Custom-Scan

bgworker
bgworker
bgworker
bgworker
Dynamic Background Worker
 max_worker_processes の範囲内なら、
動的にbgworkerを登録可能に
 登録と同時にpostmasterへシグナルを送り、
可及的速やかにbgworkerプロセスを起動
する。
 誰かが大量に bgworker を使っていると、
必ずしも十分な数の bgworker を確保でき
ない可能性がある。
 PostgreSQLのパラレルクエリは、仮に
bgworkerを一個も使えない状況であっても、
動作はするよう設計されている。
v9.4
課題： postmaster起動時にしかBackground Workerを登録できなかった。
postmaster
backend
backend
PGPROC配列
BackgroundWorker配列
max_worker_processes
RegisterDynamic-
BackgroundWorker()
SIGUSR1

fork(2)
bgworker
bgworker
bgworker
bgworker
Dynamic Shared Memory
▌Static shared memory
 PostgreSQLにおける従来の共有メモリ
 起動時に一定サイズを確保。後で拡張できない。
 ポインタはポータブル。どのプロセスから見ても
同じ仮想アドレスに存在する。
▌Dynamic shared memory
 PostgreSQL v9.4で導入された内部のインフラ
 オンデマンドで任意のサイズを確保。
 dsm_handle (=32bit値) さえ渡せば、他のプロ
セスでも同じメモリ領域をマップ可能
 ポインタは非ポータブル。セグメント先頭からの
オフセットによって値を表現する必要がある。
 トランザクションが終了 (commit/abort) すると
自動的に cleanup される。
v9.4
課題：共有メモリは postmaster 起動時に確保したきり。あとで動的に追加できなかった。
backend
backend
static shared memory
backend
postmaster
dynamic
shared memory
起動時に一定サイズの共有メモリを獲得
アドレス空間は fork(2) で継承されるため、
ポインタはポータブル
オンデマンドで共有メモリを獲得。
同じ仮想アドレスにmmap(2)される保証はなく、
dsm_handle + offsetで表現する必要がある。
dsm_create()
dsm_handle
dsm_attach()

Multi Version Concurrency Control (1/2)
データベース
テーブル
データ領域
Table
タプルヘッダ領域
struct HeapTupleHeaderData
{
struct HeapTupleFields
{
TransactionId t_xmin; /* inserting xact ID */
TransactionId t_xmax; /* deleting or locking xact ID */
union
{
CommandId t_cid; /* inserting or deleting command ID, or both */
TransactionId t_xvac; /* old-style VACUUM FULL xact ID */
} t_field3;
} t_heap;
ItemPointerData t_ctid; /* current TID of this or newer tuple */
uint16 t_infomask2; /* number of attributes + various flags */
uint16 t_infomask; /* various flag bits, see below */
uint8 t_hoff; /* sizeof header incl. bitmap, padding */
/* ^ - 23 bytes - ^ */
bits8 t_bits[FLEXIBLE_ARRAY_MEMBER]; /* bitmap of NULLs */
/* MORE DATA FOLLOWS AT END OF STRUCT */
};

Multi Version Concurrency Control (2/2)
▌可視性を判定するルール（ざっくり）
 xmin: タプルを作った人のトランザクションID。十分に古い時は Freezed (無限遠)。
 xmin: このタプルを更新/削除した人のトランザクションID。
 ざっくり言えば xmin ≦ 自分のXID ≦ xmax である時にタプルが見えるイメージ。
 ※もちろん、並行トランザクションやSAVEPOINTの扱いで色々やっているので、↑をま
んま信じないでください。
▌並列クエリがビューを共有するには
 トランザクションのスナップショットをExport、ワーカー側でこれを再現してやる。
 同一のスナップショットからは同一のビューが得られる。
xmin xmax cmax/cmin x y z
14684 0 0 100 ‘aaa’ 200
14684 0 0 101 ‘bbb’ 200
14684 14691 1 102 ‘ccc’ 210
14685 14691 0 103 ‘ddd’ 205
14685 0 1 104 ‘eee’ 210
snapshot
xmin, xmax, xip[],
...など
ユーザー列システム列

Parallel Context
▌プランを実行して同一の結果が返ってくるためには
 同一のトランザクション分離レベルを持つ
 同一の Snapshot を持つ
 GUC変数の設定が同一である
 同一の拡張モジュールがロードされている
 volatileなSQL関数が含まれていない
 .....など。
▌ParallelContext
 特定の Backend の状態をシリアライズして共有メモリ上に記録。
 Bgworker側では、共有メモリの dsm_handle を使用してシリアライズされた
呼び出し元 Backend の状態を取得し、状態を再現する。
初期設定を終えた後、Parallel Contextに紐付けられた関数を呼び出す。
この状態で表スキャンを行うと、呼び出し元 Backend と同一の可視性判定が
行われる。
課題：各bgworkerは同一のMVCC判定、同一の実行環境を持たねばならない。
v9.5

Gather & Partial SeqScan (1/3)
table
shared buffer
storage manager
shared
state
Partial
SeqScan
Partial
SeqScan
Partial
SeqScan
Partial
SeqScan
Gather
結果
shm_mq
shared memory
message queue
bgworker１個あたり、
平均 nrows/4行を
読み出す
v9.6

shared
state
Partial
SeqScan
Partial
SeqScan
Partial
SeqScan
Partial
SeqScan
Gather
結果
shm_mq
shared memory
message queue
qualifier qualifier qualifier qualifier
行数を削る行数を削る行数を削る行数を削る
v9.6

▌Gatherノードの役割
 bgworkerを起動する。
 もし起動できなかったら？  従来のPostgreSQLと同様に、シングルプロセスで動作。
 parallel-contextを介してbgworkerに実行コンテキストを渡す
 Gatherノード配下のPlan-SubTreeや、トランザクション状態など。
 shm_mqを介してbgworkerから結果を受け取る
 メッセージ受け渡しコストが意外と高く、バッファも大きくない (64KB/worker)。
▌Gatherノード配下で動作するノードの働き
行を生成するノードその他のノード
シングルプロセス実行と同様
入力に対して出力を行う
互いに出力が重複しないよう
出力を行う
v9.6

Nested-Loop in Parallel
Nested-
Loop
Parallel
SeqScan
Index
Scan
outer
table
inner
table
Nested-
Loop
Parallel
SeqScan
Index
Scan
inner
table
Nested-
Loop
Parallel
SeqScan
Index
Scan
inner
table
Gather
結果
nrows/3 行nrows/3 行
nrows/3 行
こっち側がNULLになる可能性の
あるOUTER JOINは無理
v9.6

Hash-Join in Parallel
Hash-Join
Parallel
SeqScanSeqScan
outer
table
inner
table
Hash-Join
Parallel
SeqScanSeqScan
inner
table
Hash-Join
Parallel
SeqScanSeqScan
inner
table
Gather
nrows/3 行
Hash Hash Hash
結果
こっち側がNULLになる可能性の
あるOUTER JOINは無理
v9.6

Aggregation in Parallel
table nrows/4 行nrows/4 行
Final
Aggregate
Parallel
SeqScan
Parallel
SeqScan
Parallel
SeqScan
Parallel
SeqScan
Partial
Aggregate
Partial
Aggregate
Partial
Aggregate
Partial
Aggregate
Gather
count(X),
sum(X)
結果
count(X),
sum(X)
count(X),
sum(X)
count(X),
sum(X)
AVG(X) = 𝑠𝑢𝑚(𝑋) 𝑐𝑜𝑢𝑛𝑡(𝑋)
SELECT AVG(X) FROM tbl
GROUP BY category;
v9.6

並列クエリ実行例 (1/2)
postgres=# set max_parallel_workers_per_gather = 1000;
SET
postgres=# EXPLAIN ANALYZE SELECT cat, avg(ax) FROM t0 NATURAL JOIN t1 GROUP BY cat;
QUERY PLAN
----------------------------------------------------------------------------------------------------------
Finalize GroupAggregate (cost=1789416.68..1789418.37 rows=26 width=12)
(actual time=10958.136..10958.196 rows=26 loops=1)
Group Key: t0.cat
-> Sort (cost=1789416.68..1789417.14 rows=182 width=36)
Sort Key: t0.cat
Sort Method: quicksort Memory: 55kB
-> Gather (cost=1789391.39..1789409.85 rows=182 width=36)
Workers Planned: 7
Workers Launched: 7
-> Partial HashAggregate (cost=1788391.39..1788391.65 rows=26 width=36)
Group Key: t0.cat
-> Hash Join (cost=3674.00..1288390.99 rows=100000080 width=12)
Hash Cond: (t0.aid = t1.aid)
-> Parallel Seq Scan on t0 (cost=0.00..976191.26 rows=14285726 width=8)
-> Hash (cost=1935.00..1935.00 rows=100000 width=12)
Buckets: 131072 Batches: 2 Memory Usage: 3180kB
-> Seq Scan on t1 (cost=0.00..1935.00 rows=100000 width=12)
Planning time: 0.328 ms
Execution time: 10958.825 ms
(18 rows)

並列クエリ実行例 (2/2)
postgres=# EXPLAIN ANALYZE SELECT cat, avg(ax) FROM t0 NATURAL JOIN t1 GROUP BY cat;
QUERY PLAN
--------------------------------------------------------------------------------------
HashAggregate (cost=4493751.30..4493751.63 rows=26 width=12)
Group Key: t0.cat
-> Hash Join (cost=3674.00..3993750.90 rows=100000080 width=12)
Hash Cond: (t0.aid = t1.aid)
-> Hash (cost=1935.00..1935.00 rows=100000 width=12)
Buckets: 131072 Batches: 2 Memory Usage: 3180kB
Planning time: 0.900 ms
Execution time: 77128.944 ms
(10 rows)

CPU+GPU Hybrid Parallel
SeqScan
outer
table
inner
table
Gather
結果
Final Aggregate
GpuPreAgg
GpuHashJoin
SeqScan
inner
table
GpuPreAgg
GpuHashJoin
SeqScan
inner
table
GpuPreAgg
GpuHashJoin
nrows/3 行
CustomScanノード上に
CPU+GPUパラレル機能を
実装
v9.6+PG-Strom

オプティマイザの改良 (1/3)
▌従来のオプティマイザ
 前半： Scan + Joinの組合せをコストベースで判断
 後半：ソート、集約、Window関数など、その他のロジックを問答無用で付加
 改善ポイント
① 並列化してはならないサブプランは排除しなければならない。
② 後半のプラン生成もコストベースで行う必要がある。
v9.6
課題：並列処理を実行するか（できるか）否か、コストベースで判断しなければならない。
SELECT cat, avg(X)
FROM t1 NATURAL JOIN t2 NATURAL JOIN t3
GROUP BY cat
ORDER BY cat;
HJ: t1x(t2xt3)
cost=100
HJ: (t1xt2)xt3
cost=5000
HJ: (t1xt3)xt2
cost=200
NL: (t1xt2)xt3
cost=3000
NL: (t1xt3)xt2
cost=240
NL: t1x(t2xt3)
cost=50
前半後半
NL: t1x(t2xt3)
cost=50
Agg by cat
NL: t1x(t2xt3)
cost=50
Sort by cat
Agg by cat

オプティマイザの改良 (2/3)
▌consider_parallel
 このScan/JoinがGatherノード配下で
実行してよいかどうかを示すフラグ
▌partial_pathlist
 Gatherノード配下で実行する際に、
各bgworker間で重複排除ができる
候補パスのリスト
 必ずしも cheapest とは限らない。
▌例） JOINのパスを作る時
 inner/outer側が共に
consider_parallel=trueで、
JOIN自身も並列化可能ならOK
 partial_pathlist 中のパスでコスト最安
のパスに GatherPath を付加し、シーケ
ンシャル実行も含む、最も安いパスを
選択する。
typedef struct RelOptInfo
{
NodeTag type;
RelOptKind reloptkind;
/* all relations included in */
Relids relids;
/* size estimates */
double rows;
:
/* consider parallel paths? */
bool consider_parallel;
:
/* Path structures */
List *pathlist;
List *ppilist;
/* partial Paths */
List *partial_pathlist;
struct Path *cheapest_startup_path;
struct Path *cheapest_total_path;
struct Path *cheapest_unique_path;
:
}

オプティマイザの改良 (3/3) – 二段階集約
▌後半のプラン生成もコストベースに変更
 現状、集約演算がこれに対応。ソート等も可能性？はありそう。
▌従来の集約演算
 シーケンシャルに処理するが、プロセス間データコピーは必要ない。
▌二段階集約(Partial + Final Aggregation)
 並列処理可能だが、件数が増えるに伴ってshm_mqがボトルネックとなる。
 Partial Agg) 集約関数の中間結果を生成する。各プロセスにMapした結果の生成。
 Final Agg) 中間結果を受け取り、平均値や標準偏差などを出力。Reduceに相当。
HJ: t1x(t2xt3)
cost=100
HJ: (t1xt2)xt3
cost=5000
HJ: (t1xt3)xt2
cost=200
NL: (t1xt2)xt3
cost=3000
NL: (t1xt3)xt2
cost=240
NL: t1x(t2xt3)
cost=50
前半後半
NL: t1x(t2xt3)
cost=50
Agg by cat
NL: t1x(t2xt3)
cost=50
Final Agg by cat
Partial Agg by cat
Or
Gather
どちらのパスを使用して集約演算を行うか？

今後の展望
▌Partial Sort + Merge Join
▌Hash table in shared memory
▌Declarative Partitioning
 Append Pushdown
 Inner-Hash size reduction
▌Asynchronous Execution
▌Better Plan Construction
v9.7~

【拡散希望】 – ユーザを探しています (1/2)
▌試用ユーザ募集中
 GPUを活用した高速 In-database Analytics/Computing に興味のある方。
 教師なし学習アルゴリズム (非階層/階層型クラスタリング) を実装し、実データによる
評価を行いたい。
 評価環境の提供と、アルゴリズムの実装はPG-Stromプロジェクトで実施。
ワークロードと評価用データをご提供いただける方を探しています。
 評価環境： CPU: E5-2670v3 x2, RAM: 384GB, GPU: Tesla K20 or GTX1080
CREATE FUNCTION kmeans(matrix, int)
RETURNS vector
AS $$
$$ LANGUAGE ‘plcuda’;
User define CUDA logic
(通常のSQL関数として記述可能)
User defined
CUDA code
PG-Strom’s matrix
support routines
GPU Kernel for
SQL function
‘kmeans()’
実行時ビルド
PG-Strom
Input
buffer
Output
buffer
SQL関数実行結果
matrixのロード
ユーザCUDAロジックの定義：

【拡散希望】 – ユーザを探しています (2/2)
CREATE OR REPLACE FUNCTION
gpu_similarity(int[], -- key bitmap (1xM matrix)
int[], -- ID array (Nx1 matrix)
int[]) -- fingerprint bitmap (NxM matrix)
RETURNS float4[]
AS $$
#plcuda_begin
#plcuda_num_threads gpu_similarity_main_num_threads
:
fp_map = (cl_uint *)ARRAY_MATRIX_DATAPTR(arg3.value);
for (i=0; i < width; i++, fp_map += height)
{
bitmap = fp_map[get_global_id()];
sum_and += __popc(keymap[i] & bitmap);
sum_or += __popc(keymap[i] | bitmap);
}
/* similarity */
dest[get_global_id()] =
(sum_or > 0 ? (cl_float)sum_and / (cl_float)sum_or : 0.0);
:
#plcuda_end
$$ LANGUAGE 'plcuda';

まとめ
▌PostgreSQLのプロセスモデル
 1プロセス – 1スレッド
 postmasterが子プロセスの起動生成を管理。
▌PostgreSQLの並列クエリの考え方
 “並列” 向けの特別対応は必要最小限に。既存のコードをAs-Isで動作させる。
 各コアでPartial xxxScanが一部分を読出し、最後にGatherで集約
スタースキーマ / 典型的OLAPワークロードでの効果が期待。
 一方、各コアで効率的にデータを削減できないと却って非効率になる事も…。
▌過去数バージョンにおけるインフラ強化
 v9.3 Background Worker
 v9.4 Dynamic Background Worker,
Dynamic Shared Memory, shm_mq, shm_toc, etc...
 v9.5 Parallel Context, Sub-plan serialization, etc...
 v9.6 Gather & Partial SeqScan,
Two phase aggregation,
Upper Path Optimization, etc...

並列クエリを実行するPostgreSQLのアーキテクチャ

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (11)

Similar a 並列クエリを実行するPostgreSQLのアーキテクチャ

Similar a 並列クエリを実行するPostgreSQLのアーキテクチャ (20)

Más de Kohei KaiGai

Más de Kohei KaiGai (20)

Último

Último (10)

並列クエリを実行するPostgreSQLのアーキテクチャ