(JP) GPGPUがPostgreSQLを加速する

1. GPGPUがPostgreSQLを加速する～“超”メニーコアによる検索高速化～ NEC OSS推進センター The PG-Strom Project 海外浩平 <kaigai@ak.jp.nec.com> (Tw: @kkaigai)

2. 自己紹介 ▌名前: 海外浩平 ▌所属： NEC OSS推進センター ▌好きなもの：コアの多いプロセッサ ▌嫌いなもの：コアの少ないプロセッサ ▌経歴: HPC  OSS/Linux  SAP  GPU/PostgreSQL ▌Tw: @kkaigai ▌主な仕事 SELinux周り諸々 (2004~) •Lockless AVC、JFFS2 XATTRなど PostgreSQL周り諸々 (2008~) •SE-PostgreSQL、Security Barrier View、Writable FDWなど PG-Strom (2012~) DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 2

3. 処理性能向上のアプローチ Page. 3 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL スケールアウトスケールアップホモジニアス・スケールアップヘテロジニアス・スケールアップ +

4. GPU (Graphic Processor Unit) の特徴 ▌GPUの特徴 チップに占める演算ユニットの比率が高い キャッシュ・制御ロジックの比率が小さい 単純な演算の並列処理に向く。複雑なロジックの処理は苦手。 値段の割にコア数が多い •GTX750Ti(640core)で 1万5千円くらい GPU CPU Model Nvidia Tesla K20X Intel Xeon E5-2690 v3 Architecture Kepler Haswell Launch Nov-2012 Sep-2014 # of transistors 7.1billion 3.84billion # of cores 2688 (simple) 12 (functional) Core clock 732MHz 2.6GHz, up to 3.5GHz Peak Flops (single precision) 3.95TFLOPS 998.4GFLOPS (AVX2使用) DRAM size 6GB, GDDR5 768GB/socket, DDR4 Memory band 250GB/s 68GB/s Power consumption 235W 135W Price $3,000 $2,094 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 4 SOURCE: CUDA C Programming Guide (v6.5)

5. GPU活用による計算の例 – 縮約アルゴリズム ● item[0] step.1 step.2 step.4 step.3 N個のGPUコアによる Σi=0...N-1item[i] 配列総和の計算 ◆ ● ▲ ■ ★ ● ◆ ● ● ◆ ▲ ● ● ◆ ● ● ◆ ▲ ■ ● ● ◆ ● ● ◆ ▲ ● ● ◆ ● item[1] item[2] item[3] item[4] item[5] item[6] item[7] item[8] item[9] item[10] item[11] item[12] item[13] item[14] item[15] log2N ステップで items[]の総和を計算 HW支援によるコア間の同期機構

6. 半導体技術のトレンド (1/2) – ヘテロジニアス化 ▌マルチコアCPUから、CPU/GPU統合型アーキテクチャへの移行 ▌HW性能向上からSWがフリーランチを享受できた時代は終わりつつある。 HW特性を意識してSWを設計しないと、半導体の能力を引き出せない。 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 6 SOURCE: THE HEART OF AMD INNOVATION, Lisa Su, at AMD Developer Summit 2013

7. 半導体技術のトレンド (2/2) – ダークシリコン問題 ▌CPU/GPU統合型アーキテクチャの背景 トランジスタ集積度向上のスピード > トランジスタあたり消費電力削減のスピード 排熱が追いつかないので、全ての回路に同時に電力供給するワケにはいかない。 同じチップ上に特性の異なる回路を実装。ピーク電力消費を抑える。 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 7 SOURCE: Compute Power with Energy-Efficiency, Jem Davies, at AMD Fusion Developer Summit 2011

8. RDBMSとボトルネックを考える (1/2) DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 8 Storage Processor データ RAM データサイズ > RAM容量データサイズ < RAM容量 Storage Processor データ RAM 将来は？ Processor 広帯域 RAM 不揮発型 RAM データ

9. 現代のメモリボトルネックの世界 Join、Aggregation、Sort、Projectionなど戦略 •バーストしやすいアクセスパターン •並列計算アルゴリズムの適用伝統的なディスクI/Oボトルネックの世界 SeqScan、IndexScanなど戦略 •I/Oの量 (サイズ、回数) を減らす •ディスク分散 (RAID) RDBMSとボトルネックを考える (2/2) DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 9 Processor RAM Storage 帯域：数十~数百GB/s 帯域：数百MB/s～数GB/s

10. PG-Stromのアプローチ ▌PG-Stromとは PostgreSQL用の拡張モジュール SQL処理ワークロードの一部をGPUで並列実行し、高速化を実現。 Full-Scan、Hash-Join、Aggregate の３種類のワークロードに対応 (2014年11月時点のβ版での対応状況) ▌コンセプト SQL構文からGPU用のネイティブ命令を動的に生成。JITコンパイル。 CPU/GPU協調による非同期並列実行 ▌利点 利用者からは完全に透過的に動作。 •SQL構文や周辺ツール、ドライバを含めPostgreSQL向けのソフトウェア資産を利用可 GPU+OSSの組み合わせにより、低コストでの性能改善が計れる。 ▌注意点 ただし、現時点ではインメモリ・データストアが前提。 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 10

11. PostgreSQL PG-Strom PG-Stromのアーキテクチャ (1/2) DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 11 GPU Code Generator Storage Storage Manager Shared Buffer Query Parser Query Optimizer Query Executor SQL問い合わせ構文解析実行計画作成クエリ実行 Custom-Plan APIs GpuScan GpuHashJoin GpuPreAgg GPU Program Manager PG-Strom OpenCL Server Message Queue

12. PG-Stromのアーキテクチャ (2/2) ▌OpenCL ヘテロジニアス計算環境を用いた並列計算フレームワーク NVIDIAやAMDのGPUだけでなく、CPU並列にも適用可能 言語仕様にランタイムコンパイラを含む。 ▌行指向データ構造 PostgreSQLの共有バッファをDMA転送元として利用する。 GPUの性能を引き出すには列指向データが最適ではあるものの、行列変換が非常にコスト高で本末転倒に。 ▌Custom-Plan APIs あたかもPostgreSQLのSQL処理ロジックであるかのように、拡張モジュールがスキャンやジョインを実装するための機能。 PostgreSQL v9.5に向けて提案し、現在、開発者コミュニティにおいて議論が進められている。 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 12

13. PG-Stromの処理イメージ – Hash-Joinのケース DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 13 Inner relation Outer relation Inner relation Outer relation Hash表 Hash表次処理次処理 CPU側は Join結果を参照するだけ CPUによる Hash表探索 CPUによる Projection処理並列 Projection 並列Hash表探索標準のHash-Join実装 GpuHashJoin実装

14. ベンチマーク (1/2) – Simple Tables Join [測定条件] ▌2億件 x 10万件 x 10万件 ... のINNER JOINをテーブル数を変化させながら実行 ▌使用したクエリ： SELECT * FROM t0 natural join t1 [natural join t2 ...]; ▌全てのテーブルは事前にバッファにロード済み ▌HW: Express5800 HR120b-1, CPU: Xeon E5-2640, RAM: 256GB, GPU: NVIDIA GTX980 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 14 178.7 334.0 513.6 713.1 941.4 1181.3 1452.2 1753.4 29.1 30.5 35.6 36.6 43.6 49.5 50.1 60.6 0 200 400 600 800 1000 1200 1400 1600 1800 2000 2 3 4 5 6 7 8 9 Query response time number of joined tables Simple Tables Join PostgreSQL PG-Strom

15. ベンチマーク (2/2) – Aggregation + Tables Join [測定条件] ▌2億件 x 10万件 x 10万件 ... のINNER JOINをテーブル数を変化させながら実行 ▌使用したクエリ： SELECT cat, AVG(x) FROM t0 natural join t1 [natural join t2 ...] GROUP BY CAT; ▌他の測定条件は前試験と同一 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 15 157.4 238.2 328.3 421.7 525.5 619.3 712.8 829.2 44.0 43.2 42.8 45.0 48.5 50.8 61.0 66.7 0 100 200 300 400 500 600 700 800 900 1000 2 3 4 5 6 7 8 9 Query response time number of joined tables Aggregation + Tables Join PostgreSQL PG-Strom

16. PG-Strom開発の歴史 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 16 2011 2月海外、ドイツへ赴任 5月 PGconf 2011 2012 1月最初のプロトタイプを実装 5月疑似コード実行のアプローチ 8月 Background Worker & Writable FDWの提案 2013 7月 PG-Stromの開発がお仕事になる 11月 CustomScan Interfaceの提案 2014 2月 CUDAからOpenCLへの移行 6月 GpuScan、GpuSort、 GpuHashJoinを実装 9月 GpuSortを破棄、GpuPreAggを実装 10月列指向キャッシュを破棄 11月 β版を公開

17. 着想 – 2011年5月頃 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 17 http://ja.scribd.com/doc/44661593/PostgreSQL-OpenCL-Procedural-Language PGconf 2011 @ Ottawa, Canada

18. PgOpenclプロジェクトからの着想 Page. 18 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL A列 B列 C列 D列 E列要約：画像データみたく長大なBLOBが入っている時に、そいつをGPUで並列処理させてやるとイイよ！ Parallel Image Searching Using PostgreSQL PgOpenCL @ PGconf 2011 Tim Child (3DMashUp) 幅の小さいデータでも、大量の行を並べれば長大なBLOBと同じく GPU並列処理が効くのでは？

19. 実際に作ってみた – 2011年末のクリスマス休暇 CUDAを利用 ( 現在はOpenCL) FDW (Foreign Data Wrapper) を利用 ( 現在はCustomPlan APIs) 列指向データ構造 ( 現在は行指向データ構造) DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 19 CPU vanilla PostgreSQL PostgreSQL + PG-Strom 行フェッチとWHERE句評価の繰り返し一度に複数行を取り出し非同期DMA & 起動機Kernel実行 CUDA Compiler : 共有バッファからの行を取り出し : WHERE句の評価並列実行による実行時間短縮 CPU GPU Synchronization SELECT * FROM table WHERE sqrt((x-256)^2 + (y-100)^2) < 10; code for GPU GPUコードの自動生成と、 Just-in-timeコンパイル CPUによる逐次実効よりも応答速度を短縮 GPU Device

20.  元々は外部データソースをPostgreSQLの表として見せるためのAPI群  “外部テーブル” へのアクセスは、ドライバがPostgreSQLの行を生成する  データ構造を自由に規定できる  処理ロジックを自由に規定できる FDW (Foreign Data Wrapper) とは Query Executor Regular Table Foreign Table Foreign Table Foreign Table File FDW Oracle FDW PG-Strom FDW storage Regular Table storage Query Planner Query Parser Exec Exec Exec Exec SQL Query DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU Page. 20 acceleration on PostgreSQL CSV Files ....... .... .... ... ... ... . ... ... . .... .. .... .. . .. .. . . . .. . Other DBMS

21. 当時の実装 ▌問題点 GPUアクセラレーションの対象が Foreign Tableに限られていた。 当時のForeign TableはRead-Only オフロード対象のワークロードが全件スキャンのみ 初回クエリが微妙にもっさり 要約：とても使い勝手が悪い。 PGconf.EU 2012 / PGStrom - GPU Accelerated Asynchronous Execution Module 21 ForeignTable (pgstrom) value a[] rowmap value b[] value c[] value d[] <not used> <not used> Table: my_schema.ft1.b.cs 10300 {10.23, 7.54, 5.43, … } 10100 {2.4, 5.6, 4.95, … } ②Calculation ①Transfer ③Write-Back Table: my_schema.ft1.c.cs {‘2010-10-21’, …} {‘2011-01-23’, …} {‘2011-08-17’, …} 10100 10200 10300 外部テーブルの各列の背後に、列指向でデータを保持する “shadow table” を持たせる。各要素は長大配列として、物理的に近傍の位置に配置

22. PostgreSQLの強化 (1/4) – Writable FDW ▌FDWの仕様上、Read-Onlyアクセスのみ (~v9.2) 専用関数で shadow table へとデータをロードする必要があった。 API仕様を拡張して、外部テーブルへのINSERT・UPDATE・DELETEを可能に DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 22 PostgreSQL Data Source クエリ実行計画 SELECT DELETE UPDATE INSERT FDW Driver この部分の仕様を拡張

23. PostgreSQLの強化 (2/4) – Background Worker ▌初回クエリが微妙にもっさり GPUコードのコンパイルに要する時間  ビルド結果をキャッシュする GPUデバイスの初期化に要する時間  常駐プロセスが一度だけ初期化する 副産物：複数プロセスの同時利用で “device busy” を返すドライバでも実装可能に ▌Background Worker 拡張モジュールが管理する常駐プロセスを登録可能とするAPI v9.4で動的登録も可能に。今後のパラレルクエリ実装の基盤となる機能 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 23 Postmasterプロセス PostgreSQL バックエンドプロセスビルトイン常駐プロセス拡張モジュール常駐プロセス fork(2) on connection fork(2) on startup 共有メモリ、IPC fork(2) on startup / demand 5432 Port

24. 設計転換 ▌はたして FDW は適切なフレームワークか？ 元々、外部のデータソースをテーブルとして見せるための枠組み [利点] •既にPostgreSQLで標準機能化済み [課題] •利用者、アプリケーションに対する透過性 •GPUを使わない方が実行性能が良いケースへの対応 •全件スキャン以外のワークロードへの対応 ▌CUDA か OpenCL か？ 先ずは幅広く使ってもらう事を優先し、OpenCLへ移行 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 24 CUDA OpenCL 利点 •細かな最適化が可能 •NVIDIA GPUの最新機能 •ドライバの実績・安定性 •マルチプラットフォームへの対応 •JITコンパイラが言語仕様に含まれる •CPU並列へも対応が可能課題 •AMD, Intel環境に対応できない •ドライバの実績・安定性

25. PostgreSQLの強化 (3/4) – Custom-Plan APIs Page. 25 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Table.A アクセス対象テーブル条件句 id > 200 候補パス① SeqScan cost=400 候補パス② TidScan unavailable 候補パス③ IndexScan cost=10 統計情報候補パス④ CustomScan (GpuScan) cost=40 ビルトインロジック Table.X 統計情報 Table.Y 統計情報結合対象テーブル候補パス① NestLoop cost=8000 候補パス② HashJoin cost=800 候補パス③ MergeJoin cost=1200 候補パス④ CustomScan (GpuHashJoin) cost=500 ビルトインロジック結合条件 x.id = y.id 候補パス③ IndexScan cost=10 Table.A WINNER! Table.X 統計情報 Table.Y 統計情報候補パス④ CustomScan (GpuHashJoin) cost=500 結合条件 x.id = y.id WINNER! 拡張モジュールが実装するSQL実行ロジックを、標準のものと同列に並べて取捨選択を行う。

26. PostgreSQLの強化 (4/4) – Custom-Plan APIs ▌Custom-Plan APIs のポイント 拡張モジュールの実装するScan/Joinのロジックであっても、標準実装のものと同列にコストベースで取捨選択 外部テーブルだけでなく、通常のテーブルに対しても独自実装の処理ロジックを適用可能。 ▌FDWベースの実装に比べたアドバンテージ 利用者、アプリケーションに対する透過性 Index-Scanが有効なケースでGpuScanを無理強いしない Joinワークロードへの対応 ▌PostgreSQL v9.5 で標準機能化 11/8(土) にマージされたばかり。 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 26

27. (参考) Custom Plan Interface, ready for v9.5 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 27 まず、コンセンサスである Scan部分のカスタムロジックを拡張モジュールで実装できるようインターフェースを定義。 ↓ 次にJoinのカスタムロジックを開発者コミュニティで議論

28. PostgreSQL PG-Strom Custom Plan APIs ベースの実装 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 28 Storage Storage Manager Shared Buffer Query Parser Query Optimizer Query Executor SQL問い合わせ構文解析実行計画作成クエリ実行 Custom-Plan APIs GpuScan GpuHashJoin GpuPreAgg DMA転送 (via PCI-E bus) GPU Program Manager PG-Strom OpenCL Server Message Queue T-Tree Columnar Cache GPU Code Generator キャッシュ構築 (行列変換) 処理結果返却 (列行変換)

29. なぜGPUと列指向データの相性が良いか DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 29 SOURCE: Maxwell: The Most Advanced CUDA GPU Ever Made Core Core Core Core Core Core Core Core Core Core SOURCE: How to Access Global Memory Efficiently in CUDA C/C++ Kernels coalesced memory access Global Memory (DRAM) Wide Memory Bandwidth (256-384bits) WARP: 命令ポインタを共有する GPUの命令処理単位。 32個単位である事が多い。

30. PostgreSQLのタプル形式 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 30 struct HeapTupleHeaderData { union { HeapTupleFields t_heap; DatumTupleFields t_datum; } t_choice; /* current TID of this or newer tuple */ ItemPointerData t_ctid; /* number of attributes + various flags */ uint16 t_infomask2; /* various flag bits, see below */ uint16 t_infomask; /* sizeof header incl. bitmap, padding */ uint8 t_hoff; /* ^ - 23 bytes - ^ */ /* bitmap of NULLs -- VARIABLE LENGTH */ bits8 t_bits[1]; /* MORE DATA FOLLOWS AT END OF STRUCT */ }; HeapTupleHeader NULL bitmap (if has null) OID of row (if exists) Padding 1st Column 2nd Column 4th Column Nth Column NULL値ならデータは入ってない途中に可変長データが入っていると、後ろのフィールドもそれに合わせてずれる。全フィールドが比NULLなら NULL Bitmapはない Row OIDは無い場合も多い

31. 列指向キャッシュの悪夢 (1/2) ▌列指向キャッシュと行列変換 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 31 postgres=# explain (analyze, costs off) select * from t0 natural join t1 natural join t2; QUERY PLAN ------------------------------------------------------------------------------ Custom (GpuHashJoin) (actual time=54.005..9635.134 rows=20000000 loops=1) hash clause 1: (t0.aid = t1.aid) hash clause 2: (t0.bid = t2.bid) number of requests: 144 total time to load: 584.67ms total time to materialize: 7245.14ms <-- 全体の70%!! average time in send-mq: 37us average time in recv-mq: 0us max time to build kernel: 1us DMA send: 5197.80MB/sec, len: 2166.30MB, time: 416.77ms, count: 470 DMA recv: 5139.62MB/sec, len: 287.99MB, time: 56.03ms, count: 144 kernel exec: total: 441.71ms, avg: 3067us, count: 144 -> Custom (GpuScan) on t0 (actual time=4.011..584.533 rows=20000000 loops=1) -> Custom (MultiHash) (actual time=31.102..31.102 rows=40000 loops=1) hash keys: aid -> Seq Scan on t1 (actual time=0.007..5.062 rows=40000 loops=1) -> Custom (MultiHash) (actual time=17.839..17.839 rows=40000 loops=1) hash keys: bid -> Seq Scan on t2 (actual time=0.019..6.794 rows=40000 loops=1) Execution time: 10525.754 ms

32. 列指向キャッシュの悪夢 (2/2) DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 32 テーブル (行指向データ) ⇩ 列指向キャッシュへの変換（最初の一回だけ） PG-Strom内部形式 (列指向データ) ⇩ PostgreSQLのデータ受渡し形式 (行指向データ) [Hash-Join処理] テーブル間で対応するレコードを探索する処理処理時間の内訳 You cannot see the wood for the trees GPU内のロジックを最適化するために、足回り (= PostgreSQLとのインターフェース部分) で無視できない処理コストが発生している。

33. GPUアクセラレーションのポイント (1/2) DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 33 •CPUは希少リソース。いかにCPUに仕事をさせないかがポイント。 •CPUに仕事をさせる場合、メモリ性能を発揮しやすいパターンを意識する。 Storage Shared Buffer T-Tree columnar cache 結果バッファ PostgreSQL 行イメージスロット CPUのタスクキャッシュ構築の際に、一度だけ行列変換極めて高い負荷 CPUのタスクキャッシュ構築の際に、一度だけ行列変換極めて高い負荷 PCI-Eのタスク列指向データなので、必要なデータだけを転送低い負荷 CPUのタスク処理結果をPostgreSQLへ返す際に、毎回、列行変換極めて高い負荷 GPUのタスク列データに対して演算処理を実行。GPUの特性に従って最適化されたコード。列指向データの利用時

34. GPUアクセラレーションのポイント (2/2) DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 34 •CPUは希少リソース。いかにCPUに仕事をさせないかがポイント。 •CPUに仕事をさせる場合、メモリ性能を発揮しやすいパターンを意識する。 Storage Shared Buffer 結果バッファ PostgreSQL 行イメージスロット CPUのタスク DMA転送前の可視性チェックのみ。軽い負荷 CPUのタスクキャッシュ構築の際に、一度だけ行列変換極めて高い負荷 PCI-Eのタスク行指向データなので、全てのデータを転送する少し高い負荷 CPUのタスク結果バッファへのポインタをセットするだけ。極めて軽い負荷 GPUのタスク行データに対して演算処理を実行。最適なデータ構造ではないが、コアの数で処理速度をカバー行指向データの利用時独自のキャッシュは持たない

35. PostgreSQLのshared_bufferと統合した結果 ▌列指向キャッシュと行列変換 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 35 postgres=# explain (analyze, costs off) select * from t0 natural join t1 natural join t2; QUERY PLAN ----------------------------------------------------------- Custom (GpuHashJoin) (actual time=111.085..4286.562 rows=20000000 loops=1) hash clause 1: (t0.aid = t1.aid) hash clause 2: (t0.bid = t2.bid) number of requests: 145 total time for inner load: 29.80ms total time for outer load: 812.50ms total time to materialize: 1527.95ms <-- 大幅に削減 average time in send-mq: 61us average time in recv-mq: 0us max time to build kernel: 1us DMA send: 5198.84MB/sec, len: 2811.40MB, time: 540.77ms, count: 619 DMA recv: 3769.44MB/sec, len: 2182.02MB, time: 578.87ms, count: 290 proj kernel exec: total: 264.47ms, avg: 1823us, count: 145 main kernel exec: total: 622.83ms, avg: 4295us, count: 145 -> Custom (GpuScan) on t0 (actual time=5.736..812.255 rows=20000000 loops=1) -> Custom (MultiHash) (actual time=29.766..29.767 rows=80000 loops=1) hash keys: aid -> Seq Scan on t1 (actual time=0.005..5.742 rows=40000 loops=1) -> Custom (MultiHash) (actual time=16.552..16.552 rows=40000 loops=1) hash keys: bid -> Seq Scan on t2 (actual time=0.022..7.330 rows=40000 loops=1) Execution time: 5161.017 ms <-- 応答性能は大幅改善やや、性能劣化

36. PG-Stromの現在と今後 (1/2) – PG-Stromなう ▌対応しているロジック GpuScan ... 条件句付き全件スキャンのGPU処理 GpuHashJoin ... Hash-JoinのGPU実装 GpuPreAgg ... GPUによる集約関数の前処理 ▌対応しているデータ型 整数型 (smallint, integer, bigint) 浮動小数点型 (real, float) 文字列型 (text, varchar(n), char(n)) NUMERIC型 (開発中; 昨日動くようになった) ▌対応している関数 各データ型の四則演算オペレータ 各データ型の大小比較オペレータ 浮動小数点型の数値計算関数 集約演算： MIN, MAX, SUM, AVG, 標準偏差, 分散, 共分散 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 36

37. PG-Stromの現在と今後 (2/2) – PG-Stromうぃる ▌対応するロジック Outer Join Sort ... その他？ ▌対応するデータ型？ ▌対応する関数？ LIKE句、正規表現？ 日付/時刻関数 PostGIS関数？？ 幾何関数？ ユーザ定義関数？ ▌足回りの強化 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 37 Shared Buffer block-0 block-N block-N/3 block-2N/3 領域分割と並列スキャン現在将来いかにオンメモリとはいえ、シングルCPUで GPUにデータを供給するのは厳しい

38. 想定利用シーン (1/3) – OLTP/OLAP統合 ▌OLTP/OLAPデータベースを分ける理由 複数のデータソースを統合する 参照系ワークロードへの最適化 ▌PG-Stromの適用により... 性能のカギとなるJoinやAggregateを並列処理、リアルタイム化 OLAPとETLが不要とする事で、システムコストを圧縮 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 38 ERP CRM SCM BI OLTP database OLAP database ETL OLAP Cubes Master / Fact Tables BI PG-Strom 性能のカギ •マスタ＆ファクトテーブルの結合 •グループ化＆集約演算

39. 想定利用シーン (2/3) – Webバックエンド ▌従来の課題 アクセス集中に備えてWebのバックエンドDBを分散。DBへの参照系負荷を抑える。 シングルマスタ・レプリケーション構成で、DBノード数が増加。運用コスト増に繋がる。 運用中にDBスキーマが変わる事も。適切なインデックスを設定できない事も。 ▌PG-Stromの適用により... 単体ノードの処理性能が向上する事で、必要なDBノード数を抑える事ができる。 インデックスの効きにくい問合せに対しても、コア数の”力技で” 対処する事ができる。 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 39 BEFORE AFTER 単体ノードの性能向上により、必要なノード数を削減する

40. 想定利用シーン (3/3) – 我々と一緒に考えませんか？ ▌どういった領域に適用可能だろうか？ ▌どういった用途で使えるだろうか？ ▌どういったワークロードに困っているだろうか？ PG-Stromプロジェクトはフィールドから学びたいと考えています DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 40

41. How to use (1/3) – インストールに必要なのは ▌OS: Linux (RHEL 6.x で動作確認) ▌PostgreSQL 9.5devel (with Custom-Plan Interface) ▌PG-Strom 拡張モジュール ▌OpenCL ドライバ (NVIDIAランタイムなど) DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 41 shared_preload_libraries = '$libdir/pg_strom‘ shared_buffers = <DBサイズと同程度> PG-Stromを使用するために最低限必要な設定 postgres=# SET pg_strom.enabled = on; SET 実行時に PG-Strom の有効/無効を切り替える

42. How to use (2/3) – ビルド、インストール、起動 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 42 [kaigai@saba ~]$ git clone https://github.com/pg-strom/devel.git pg_strom [kaigai@saba ~]$ cd pg_strom [kaigai@saba pg_strom]$ make && make install [kaigai@saba pg_strom]$ vi $PGDATA/postgresql.conf [kaigai@saba ~]$ pg_ctl start server starting [kaigai@saba ~]$ LOG: registering background worker "PG-Strom OpenCL Server" LOG: starting background worker process "PG-Strom OpenCL Server" LOG: database system was shut down at 2014-11-09 17:45:51 JST LOG: autovacuum launcher started LOG: database system is ready to accept connections LOG: PG-Strom: [0] OpenCL Platform: NVIDIA CUDA LOG: PG-Strom: (0:0) Device GeForce GTX 980 (1253MHz x 16units, 4095MB) LOG: PG-Strom: (0:1) Device GeForce GTX 750 Ti (1110MHz x 5units, 2047MB) LOG: PG-Strom: [1] OpenCL Platform: Intel(R) OpenCL LOG: PG-Strom: Platform "NVIDIA CUDA (OpenCL 1.1 CUDA 6.5.19)" was installed LOG: PG-Strom: Device "GeForce GTX 980" was installed LOG: PG-Strom: shmem 0x7f447f6b8000-0x7f46f06b7fff was mapped (len: 10000MB) LOG: PG-Strom: buffer 0x7f34592795c0-0x7f44592795bf was mapped (len: 65536MB) LOG: Starting PG-Strom OpenCL Server LOG: PG-Strom: 24 of server threads are up

43. How to use (3/3) – AWSで楽々デプロイ DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 43 AMI-Id: ami-51231b50 または、“strom” で検索 AWS GPUインスタンス仕様 (g2.2xlarge) CPU Xeon E5-2670 (8 xCPU) RAM 15GB GPU NVIDIA GRID K2 (1536core) Storage 60GB of SSD Price $0.898/hour、$646.56/mon (*) 2014年11月8日現在の東京リージョンオンデマンドインスタンス価格

44. PG-Stromの今後 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 44

45. イノベーションのジレンマ DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 45 SOURCE: The Innovator's Dilemma, Clayton M. Christensen Performance demanded at the high end of the market Performance demanded at the low end of the marker or in a new emerging segment Product Performance Time

46. コミュニティと共に進む DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 46

47. （発表後の補足） DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL Page. 47 check it out! https://github.com/pg-strom/devel

SlideShare for iOS

Views

Actions

Embeds 2

Report content

Transcript