あけましておめでとうございました。（やや出遅れ感）
新年という事で、この一年、どういった技術開発に取り組んでいきたいかをざーっと書き出してみる事にする。
これらのうち、いくつかはPostgreSQL本体機能の強化を伴うものであったりするので、ある程度計画的にモノゴトを進めないといけないワケで…。
PG-Strom v2.0
先ず最優先で取り組むのが、PostgreSQL v9.6への対応。
CPUパラレル実行と、新しいオプティマイザへの対応でかなり大きなアーキテクチャ上の変更を伴ったものの、全体としてはよりシンプルな設計に落とし込む事ができている。
ちなみに、現状だとこの程度までは動くようになっている。
集約演算がGroupAggregateとGpuPreAggの二段階に分解されており、GpuPreAggはGatherの配下で並列に動作している事に注目。
postgres=# EXPLAIN (ANALYZE, VERBOSE)
SELECT cat, count(*), avg(aid), max(bid)
FROM t0
WHERE aid < 50000 and cid > 50000
GROUP BY cat;
QUERY PLAN
------------------------------------------------------------------------------------------------
GroupAggregate (cost=91050.50..91070.84 rows=26 width=48)
(actual time=1754.432..1755.056 rows=26 loops=1)
Output: cat, pgstrom.sum((pgstrom.nrows())),
pgstrom.favg((pgstrom.pavg((pgstrom.nrows((aid IS NOT NULL))),
(pgstrom.psum((aid)::bigint))))),
max((pgstrom.pmax(bid)))
Group Key: t0.cat
-> Sort (cost=91050.50..91052.32 rows=728 width=48)
(actual time=1754.381..1754.524 rows=910 loops=1)
Output: cat, (pgstrom.nrows()), (pgstrom.pavg((pgstrom.nrows((aid IS NOT NULL))),
(pgstrom.psum((aid)::bigint)))),
(pgstrom.pmax(bid))
Sort Key: t0.cat
Sort Method: quicksort Memory: 160kB
-> Gather (cost=90938.54..91015.89 rows=728 width=48)
(actual time=1749.313..1753.732 rows=910 loops=1)
Output: cat, (pgstrom.nrows()), (pgstrom.pavg((pgstrom.nrows((aid IS NOT NULL))),
(pgstrom.psum((aid)::bigint)))),
(pgstrom.pmax(bid))
Workers Planned: 4
Workers Launched: 4
-> Parallel Custom Scan (GpuPreAgg) on public.t0 (cost=89938.54..89943.09 rows=182 width=48)
(actual time=1670.139..1673.636 rows=182 loops=5)
Output: cat, (pgstrom.nrows()),
pgstrom.pavg((pgstrom.nrows((aid IS NOT NULL))),
(pgstrom.psum((aid)::bigint))),
(pgstrom.pmax(bid))
Reduction: Local
GPU Projection: t0.cat, pgstrom.nrows(), pgstrom.nrows((t0.aid IS NOT NULL)),
pgstrom.psum((t0.aid)::bigint), pgstrom.pmax(t0.bid), t0.aid, t0.cid
Outer Scan: public.t0 (cost=4000.00..87793.21 rows=2496387 width=12)
(actualtime=14.663..274.534 rows=500187 loops=5)
Outer Scan Filter: ((t0.aid < 50000) AND (t0.cid > 50000))
Rows Removed by Outer Scan Filter: 1499813
Extra: slot-format
Worker 0: actual time=1724.195..1728.058 rows=182 loops=1
Worker 1: actual time=1570.952..1573.837 rows=182 loops=1
Worker 2: actual time=1738.205..1742.053 rows=182 loops=1
Worker 3: actual time=1569.055..1571.961 rows=182 loops=1
Planning time: 0.907 ms
Execution time: 1759.557 ms
(25 rows)また、PG-Strom v2.0では、PostgreSQL v9.6へのキャッチアップだけではなく、いくつか目玉となる機能を準備中である。
一つは、これまで何度か紹介している SSD-to-GPU P2P DMA 機構。そしてもう一つは、BRINインデックスへの対応である。
SSD-to-GPU P2P DMA
SSD-to-GPU P2P DMA (NVMe-Strom) は、NVIDIA社製GPUのGPUDirect RDMA機構を利用したもので、PostgreSQLのデータブロックが格納されているNVMe-SSDのデータブロックからGPUへとダイレクトにデータ転送を行う。ファイルシステムを介する事によるオーバーヘッドや、RAMへの無駄なコピーが発生しないため、スループットを稼げるという特長がある。
現状では、GpuScanワークロード下においてNVMe-SSD 1個から成る区画からのデータ転送に対応しており、シングルプロセス性能で1.4GB/sのスキャン性能を出している。
PostgreSQL v9.6対応の過程で、GpuJoinやGpuPreAggの直下にテーブルスキャンが入る場合、これらのロジックはGpuScanがテーブルをスキャンするための関数を直接呼ぶように改良されているので、特別な事は何もしなくても『ストレージからデータを読んだ時点で既にJOIN/GROUP BYが完了している』という状態を作り出す事はできるはず。
PG-Strom v2.0に向けた課題はSoft-RAID0/1への対応。Linuxの場合、基本的には128KB単位で順番にストライピングがかかっているだけなので、技術的にはそう難しい話ではないと考えている。
DC用途向けに、PCIe x8スロット接続で5～6GB/s程度のSeqRead性能を持つNVMe-SSD製品が各社から出てきているので、計算上は、SSD二枚から全力でGPUにデータを流し込む事ができれば、GPUの持つPCIe x16スロットの帯域を飽和させられる事になる。
BRINインデックス対応
BRINインデックス自体はPostgreSQL v9.5から搭載されている機能で、特に時系列データのように
- ある一定範囲の値を持つデータが物理的な近傍に集まっている
- データの更新頻度が小さい
- データサイズが大きい
といった特徴を備えたデータセットに向いており、例えば、センサデータをPostgreSQLに収集して解析するといったワークロードに有効な機能。
BRINインデックス自体は、永安さんのこちらの記事が詳しいです。
pgsqldeepdive.blogspot.jp
PG-Stromとしては、搭載RAMが比較的小さなGPUを使うという事もあり、B-treeのようなランダムメモリアクセスを前提としたインデックスへの対応は厳しい。
ただ、条件句の評価はGPUの数千コアを使って並列処理が可能であるものの、インデックスの選択率が高くなると分の悪い勝負なので『このブロックは明らかに該当行なし』という事が分かっているなら、それを読み飛ばしたい。
GpuScanがBRINインデックスを理解し、必要のないブロックを読み飛ばす事ができるようになれば、例えばIoTのキーワードに絡めてセンサデータの集積・解析用途に、という使い方もできるハズである。
特に、PG-Stromはカラムナーを前提としたDWHではないので、生データをそのまま処理させても高速化できるという点は強みになるだろう。
PL/CUDA
PL/CUDAに関しては、言語バインディングに関してする事は（できる事は）多くないので、その周辺領域を拡充していきたい。
一つは、PostgreSQLにおける可変長データの1GB越え。
現状、全ての可変長データの基盤となっている varlena 構造は、最大でも1GBまでのデータしか持てないため、PL/CUDA関数の引数としてarray-matrixを渡す時には、例えば問題領域をうまく分割してデータサイズを1GB未満に抑えてやらないといけない。
昨年10月のCBI学会で発表した研究でも、1000万件の化合物データ（1.3GB）をロードするにはサイズが大きすぎたので、安全マージンも見て4分割した上でGPU側へロードしている。
しかし、昨今のGPUでは10GB近く、あるいはそれ以上のメモリを搭載するのが常識的になりつつあり、問題領域を1GB以内に抑えねばならない、、、というのはユーザにいかにも不都合である。
先にpgsql-hackersにデザインプロポーザルを投げたところ、Robert Haasから『varlenaとは別の体系で可変長データを保持するフォーマットを作成すべき』とサジェスチョンがあり、自分もこの方針には同意。3月のcommit-festまでにはパッチを投稿し、2018年リリース予定のPostgreSQL v11でのマージを目指したい。
もう一つは、現状、複雑な計算ロジックを個々のユーザ毎に書かねばならないという点である。
2017年1月時点でPL/CUDAを実証できたワークロードとしては、k-NN法類似度サーチや、k-meansクラスタリングがあるが、例えば MADLib のような統計解析パッケージで提供されているアルゴリズムの、全部とは言わないまでも、使用頻度が高く計算負荷の高いものをGPUで計算するようパッケージ化できれば、ユーザの裾野はより広がるだろうし、仮にカスタマイズが必要となっても骨格となるアルゴリズムのGPU実装が既に存在する事で省力化が可能となるハズである。
PG-Strom v3.0へ向けた種まき
In-memory Columnar Cache
NVMe-SSDとの密連携の他にI/O系処理を高速化する方策として、通常のPostgreSQLテーブル（行形式）の脇に、予めDMAバッファ上に列形式にデータを再編したキャッシュを持たせる機構を考えている。
このキャッシュはBackground-workerにより非同期で作成され、そのため、スキャンする区間のうち一部領域しか列形式のキャッシュが構築されていないかもしれない。しかし、その場合でもPG-StromはGPUで行形式データを扱えるので（多少のパフォーマンス差に目をつぶれば）大きな問題とはならない。
データ本体とキャッシュを別に持つ場合、必ず一貫性制御が複雑で頭の痛い問題として立ちはだかる。
アイデアとしては、これを避けるために ALL_VISIBLE フラグが 1 であるブロックのみを列形式キャッシュに持たせる。
ALL_VISIBLE=1であるブロックは、MVCC制御に関わらず、全てのレコードが全てのトランザクションから可視である事が保証されている。そのため、複雑な同時実行制御に頭を悩ませる必要はなく、全てのレコードの内容を単純に列データとして展開すればよい。
問題は、PostgreSQL側でテーブルが更新され、ALL_VISIBLE フラグが 0 にクリアされた時のinvalidation処理である。
現状、ここにフックを挟む事はできないので、PostgreSQL側の機能強化を行う必要がある。
デザインプロポーザルを出し、この処理を行うにふさわしい場所とフックの仕様を固めていきたい。
GpuSort(+LIMIT)
PG-Strom v2.0では、実はGpuSort機能の廃止を予定している。これは、ソートという問題の性質上、ある程度問題規模が大きくならないとGPUによる処理時間メリットが出てこない一方で、一度にGPUでソートを行う件数が多くなればなるほど、初期データのローディングに時間がかかるようになり、非同期・多重処理のメリットを得にくいからである。
そのため、GPUでソートを行うセグメントサイズを小さくして単位ローディング時間を短くする一方で、CPUでのMergeSort処理の割合が大きくなるか、それとも、セグメントサイズを大きくするかというジレンマに悩まされてきた。
（で、最終的にはそれほど速くならない事が多かったり・・・。）
根本的な原因は、GPUで処理を行ってもソートではデータ件数を減らす事が不可能な点にある。なので、GpuSortを有効に活かすには、何がしか『データ件数を減らせる』パターンでのソートに限った方が利口だ。
例えば、LIMIT句で『上位xx件を取り出す』という事が明らかな場合に限り、GpuSortを使用するというパターンであれば十分に効果を発揮する事ができるだろう。
これにはPostgreSQL本体側で、『LIMIT句でxx件のデータが要求されますよ』という事を下位のノードに伝えてやる仕組みが必要だが、PostgreSQL v10 向けにパッチを出しており、ある程度レビューも進んでいるので間に合うだろうとは踏んでいる。
こんな感じで2017年の開発ロードマップについて考えてみたが、さてさて、大晦日に振り返ってどの程度きちんとやれているでしょうか。
