GPUがPostgreSQLを加速する～PG-Strom 10年の歩みと、その次の未来へ～

2022/11/16のDB Tech Showcaseでの発表資料です。

Transcript

1. GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ HeteroDB,Inc Chief Architect & CEO KaiGai Kohei <kaigai@heterodb.com>
2. 自己紹介／会社紹介 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 2 会社概要  商号 ヘテロDB株式会社  創業 2017年7月4日  拠点 品川区北品川5-5-15 大崎ブライトコア4F  事業内容 高速データ処理製品の開発・販売 GPU＆DB領域の技術コンサルティング ヘテロジニアスコンピューティング技術をデータベース領域に適用し、 誰もが使いやすく、シンプルで高速な大量データ分析基盤を提供する。 代表者プロフィール  海外 浩平（KaiGai Kohei）  OSS開発者コミュニティにおいて、PostgreSQLやLinux kernelの 開発に15年以上従事。主にセキュリティ・FDW等の分野で PostgreSQLのメインライン機能の強化に貢献。  IPA未踏ソフト事業において“天才プログラマー”認定 (2006)  GPU Technology Conference Japan 2017でInception Awardを受賞
4. GPU-DBの10年を振り返る（1/2） NVIDIA TESLA C2070 (2009) CUDA Cores: 448 (Fermi) DRAM: 6GB (GDDR5) PCI-E 2.0 x16, FP32: 1.03TFlops NVIDIA TESLA K20X (2012) CUDA Cores: 2,688 (Kepler) DRAM: 6GB (GDDR5) PCI-E 3.0 x16, FP32: 3.95TFlops NVIDIA TESLA P100 (2016) CUDA Cores: 3,584 (Pascal) DRAM: 16GB (HBM2) PCI-E 3.0 x16, FP32: 9.56TFlops NVIDIA TESLA V100 (2017) CUDA Cores: 5,120 (Volta) DRAM: 32GB (HBM2) PCI-E 3.0 x16, FP32: 14.0TFlops NVIDIA A100 (2020) CUDA Cores: 6,912 (Ampare) DRAM: 80GB (HBM2) PCI-E 4.0 x16, FP32: 19.5TFlops GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 4
5. GPU-DBの10年を振り返る（2/2） （2017～） PG-Strom （2012～） （2014～） （旧MAP-D; 2013～） （2016～） （2014～） （2015～） （2016～） ➢ 2010年頃 「ビッグデータ」が盛り上がる。Hadoopなど大人気。 ➢ GPUの性能・信頼性が向上を続け、DBMSへの組み込みも現実味。 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 5
6. GPUの発展と共に、 PG-Stromの進化を振り返る GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 6
7. GPUとはどんなプロセッサか？（1/2） 多数のコアと広帯域メモリによる強力な並列演算性能を有する。 CPU Cache CUDA Core CUDA Core CUDA Core CUDA Core CUDA Core CUDA Core CUDA Core CUDA Core 広帯域メモリ GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 7 Intel Xeon Platinum 8380 # of cores: 40 clock: 2.30GHz 3.40GHz (boost) L1 cache: 64kB / core L2 cache: 1MB / core L3 cache: 60MB / proc DRAM: DDR4-3200 x 8 (max 204.8GB/s) NVIDIA A100 [80GB; PCI-E] # of CUDA cores: 6,912 [32bit] (108 SM) clock: 1.065 GHz 1.410 GHz (boost) L1 cache: 192kB / SM (*) L2 cache: 40MB / proc DRAM: HBM2e [80GB] (max 1,935GB/s)
8. GPUとはどんなプロセッサか？（2/2） GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 8 スレッド同士での同期やデータ交換を低コストで実行できる • item[0] step.1 step.2 step.4 step.3 GPUを用いた Σ i=0...N-1 item[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] log2 N ステップで items[]の総和を計算 HW支援によるコア間の同期機構 SELECT count(X), sum(Y), avg(Z) FROM my_table; 集約関数の計算で用いる仕組み
9. PostgreSQLにGPUを試そうとしたきっかけ ▌PGconf 2011 (Ottawa) で聴講したあるセッション・・・  Parallel Image Searching Using PostgreSQL and PgOpenCL Running PostgreSQL Stored Procedures on a GPU ✓ https://www.pgcon.org/2011/schedule/events/352.en.html  画像処理用のストアドプロシジャを、GPU用のプログラミング環境 OpenCL で作成するための拡張モジュールについて。 A列 B列 C列 D列 E列 幅の小さいデータでも、 大量の行を並べれば 長大なBLOBと同じく GPU並列処理が効くのでは？ May-2011 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 9
10. 実際に作ってみた（1/2） FDWを使用して、テーブル構造の裏側に 簡易的な列ストアを作成した。 ※ 当時はFDWが唯一のエグゼキュータを 拡張するための方法。 CPUでテーブルをスキャンし、同時に、 並行してGPUで条件句を処理するという 構造を持っていた。 ※ 当時は並列クエリ実行が無かった Jan-2012 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 10
11. 実際に作ってみた（2/2） WHERE条件句から CUDA C のコードを 自動生成してJITコンパイルを行う。 ※ EXPLAINすると CUDA C の生のソース コードが表示される。かなりシュール。 Jan-2012 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 11
12. PostgreSQL v9.3における機能強化 Sep-2013 ← Background worker process 通常のPostgreSQLテーブルを、裏で列ストアに変換し ようと提案した機能。 ↓ Writable foreign tables 元々はPG-Strom用のFDWテーブルにINSERTや UPDATEを使ってデータをロードするため提案。 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 12
13. 「お仕事」として PG-Strom の開発に取り組む Dec-2013 『社内新事業公募』における審査 （※ イメージ） GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 13
14. 2014年のGPUを振り返る ▌優先すべき課題 ① クラッシュしない ② 正しい計算結果を返す ③ クラッシュしない ④ デバッグしやすい構造 ⑤ クラッシュしない ⑥ 高いパフォーマンス NVIDIA TESLA K20X ✓ 第３世代 Kepler アーキテクチャ ✓ 2,688個のCUDAコアと、6GiBのGDDR5 DRAMを搭載 ✓ PCI-E 3.0 x16レーンでホストシステムと接続 ✓ ECCメモリ搭載。エンタープライズ用途での利用も意識したモデル。 まずは DBMS 側の 品質を上げる！ 2014 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 14
15. 「趣味」から「実用」に向けたアーキテクチャの変更  OpenCL ➔ CUDAへの移行 ➢ マルチプラットフォーム（NVIDIA, AMD, Intel）➔ 再現できないトラブル報告が多数寄せられる（死 ➢ CUDA 7.0以降はNVRTCが提供される ➔ CUDAでもランタイムコンパイルが可能に  各バックエンドプロセス内でGPUを制御する方式に移行 ➢ CUDA Contextの生成に要する時間は許容可能なレベル（OpenCLの場合は数秒を要していた） ➢ エラーが発生したときのクラッシュダンプの採取しやすさ 新しいアーキテクチャ （CUDAベース） PostgreSQL Backend CUDA Context PG-Strom host/GPU code PostgreSQL Backend CUDA Context PG-Strom host/GPU code PostgreSQL Backend CUDA Context PG-Strom host/GPU code Postmaster Process fork(2) PostgreSQL Backend 従来のアーキテクチャ （OpenCLベース） PG-Strom host code PostgreSQL Backend Background Worker PG-Strom GPU Service Postmaster Process fork(2) PG-Strom host code Local connection to GPU Service Device Context 2014 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 15
16. PostgreSQL v9.5における機能強化 May-2015 Parser Optimizer Executor execBegin Exec execEnd CustomScan API PostgreSQL本体へのパッチを必要せず、純粋に 拡張モジュールのみでGPU実行を実装できるように。 SQL 実行結果 パース木 実行計画 add_scan_path add_join_path BeginCustomScan ExecCustomScan EndCustomScan 拡張モジュールによる実装 CustomScan API GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 16
17. 難儀な問題：GPUメモリの使用量予測 full table scan GpuScan GpuJoin 64MB SCAN系処理なら、必ず「入力データ量 ≧ 出力データ量」 JOIN系処理なら「入力データ量＜出力データ量」があり得る。 ➔ バッファの必要量をDB統計情報から予測するなど kernel source buffer kernel source buffer kernel result buffer kernel result buffer GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 17
18. Pascal世代GPUの登場 NVIDIA TESLA P100 ✓ 第５世代 Pascal アーキテクチャ ✓ 3,584個のCUDAコアと、16GiBのHBM2 DRAMを搭載 ✓ PCI-E 3.0 x16レーンでホストシステムと接続 ✓ FP64のアトミック演算に対応 ✓ GPUでのデマンドページングとメモリオーバーコミットに対応 Apr-2016 どういうことか？ ✓ GPUメモリの論理アドレス空間上で雑に malloc() しておけば、実際に使った分だけGPUメモリを 割り当てる。 ✓ GPUメモリが足りなければ、ホストメモリと スワッピングを行う。 ➔ 複雑＆不正確な結果バッファのサイズ推定と リトライから解放される事に。 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 18
19. Pascal世代GPUによるメモリ管理の簡略化 ▌第４世代 Maxwell 以前 JOINやGroup Byなど『事前に行数の最大値を 予測する』ことが難しいワークロードに対しても、 過不足なくメモリを割り当てる事が必要。 ➔ DBの統計情報を使ったりしていたが、 基本的に無理ゲーであった。 ▌第５世代 Pascal 以降 ある程度ざっくりと大きなメモリを割り当てても、 実際に使用した分だけしか物理メモリを消費しな いため、メモリ使用量の予測そのものが不要に。 ➔ バグの原因となる複雑なロジックそのものの 解消と、品質の改善に大きく寄与。 せっかく割り当てたメモリを 全然使っていなかった。 ➔ 同時に他のタスクを 動かせたはずなのに！ これだけあれば十分だと予測した けれども、実際には不足。 ➔ リトライでパフォーマンスが 低下してしまう…。 GPU物理メモリ GPU論理アドレス空間 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 19
20. SSD-to-GPU Direct SQLの着想と開発（1/3） 冬-2015 GPUコア GPU Device Memory CPU Host Memory ストレージ （HDD/SSD） CPU 720GB/s 16GB/s 0.5GB/s 60GB/s NVME-SSD 一台あたり 3GB/s （当時の）PG-Stromを含む、 GPU-DBはデータがオンメモリ前提 ストレージに落ちたら「負け」 一方この頃、NVME-SSD製品が登場 安価な高速SSDがブレイクの兆し。 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 20
21. SSD-to-GPU Direct SQLの着想と開発（2/3） 冬-2015 NVIDIA GPUDirect RDMA nvme.ko ドライバ nvme_strom.ko ドライバ ホストメモリ デバイスメモリ 物理アドレス空間 NVME-READ From: Block 1234 Qty: 32 Dest: 0x34567000 NVME-READ From: Block 2345 Qty: 32 Dest: 0x45678000 NVME コマンド NVME コマンド GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 21
22. SSD-to-GPU Direct SQLの着想と開発（3/3） ✓ GPU-Direct SQL（当時は SSD-to-GPU Direct SQL）により、メモリサイズを越えた 大量データ（数TB～）を処理する事が可能に。 ✓ この特徴が、PG-Stromが他のGPU-DB製品とは異なった進化をするきっかけに。 ✓ この頃は、猫も杓子も “Deep Learning!” “Deep Learning!” Aug-2016 実験用に購入した Intel SSD 750 (400GB) の 理論帯域まで出ている (!) GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 22
23. GTC-2017にて May-2017 NVIDIA TESLA V100 ✓ 第6世代 Volta アーキテクチャ ✓ 5,120個のCUDAコアと、最大32GiBのHBM2 DRAMを搭載 ✓ PCI-E 3.0 x16レーンでホストシステムと接続 ✓ Tensorコアを搭載した初めてのモデル （深層学習用の専用計算回路） ✓ 各スレッドがProgram Counterを持つ事になり、分岐処理を持つ ソフトウェアの実行がより高速に。 GPU Technology Conference 2017で発表した SSD-to-GPU Direct SQLのポスターは、全138件の中から Top-5 Finalistとして選出され、来場者投票で惜しくも次点に。 PCI-Eバスが更に高速化し、GPUの処理能力ですらも 飽和に近付くAmpare以降の世代で効いてくる特徴 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 23
24. HeteroDB社の設立 ▌製品コンセプトを再定義する  PostgreSQLを使い慣れた人はたくさんいる。  GPU-DB「だけど」計算ワークロードよりも I/O中心のバッチ系処理に強い。  IoT/M2Mなど、日々積み重なるものの、 更新処理がほとんどないデータが増加  ログデータの分析・検索用途に適した 「データ処理製品」として定義づけ。 Jul-2017 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 24
25. ① Apache Arrowへの対応（1/3） ETL OLTP OLAP 伝統的なOLTP&OLAPシステム － データはDBシステムの内側で生成される Data Creation IoT/M2M時代 － データはDBシステムの外側で生成される Log processing BI Tools BI Tools Gateway Server Data Creation Data Creation Many Devices GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 25 DBシステムへのデータのインポートが、集計処理以上に時間のかかる処理に！ Data Import Import! 2019
26. ① Apache Arrowへの対応（2/3） GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 26 ▌Arrow形式の特徴  列指向で分析用途向けに設計されたデータ形式  アプリケーションによらず、共通のデータ交換形式として利用可能  整数、実数、日付時刻、文字列など基本的なデータ型を定義  更新・削除は無理だが、追記に強い（➔ ログデータに向いた形式） NVIDIA GPU PostgreSQL / PG-Strom 2019
27. ① Apache Arrowへの対応（3/3） GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 27 ▌なぜApache Arrow形式がログデータ処理に適しているのか？  被参照列のみ読み出すため、I/O量が少なくて済む  GPUメモリバスの特性から、プロセッサ実行効率が高い  Read-onlyデータなので、実行時のMVCC検査を行う必要がない SSD-to-GPU Direct SQL機構を使って、被参照列だけを転送する。 PCIe Bus NVMe SSD GPU SSD-to-GPU P2P DMA WHERE-clause JOIN GROUP BY クエリの被参照列のみ、 ダイレクトデータ転送 Apache Arrow形式を解釈し、 データを取り出せるよう GPUコード側での対応。 小規模の処理結果だけを PostgreSQLデータ形式で返す Results metadata 2019
28. ② データ処理速度 10GB/s への挑戦（1/2） 複数SSD（md-raid0）への対応と、品質・安定性の改良 Supermicro 1019GP-TT CPU: Xeon Gold 6126T (2.6GHz, 12C) RAM: 192GB (32GB DDR4-2666 x6) GPU: NVIDIA Tesla P40 (3840C, 24GB) x1 SSD: Intel SSD DC P4600 (2.0TB, HHHL) x3 HDD: 2.0TB (SATA, 72krpm) x6 N/W: 10Gb ethernet x2ports 2018 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 28
29. PostgreSQL パーティション ② データ処理速度 10GB/s への挑戦（2/2） オプティマイザで頑張り、SSD-GPUから漏出するデータを減らす lineorder lineorder_p0 lineorder_p1 lineorder_p2 customer date supplier parts Scan Scan Scan Agg 実行結果 Scan Join Gather レコード数が多いと 結合処理が大変 2018 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 29
30. PostgreSQL パーティション ② データ処理速度 10GB/s への挑戦（2/2） オプティマイザで頑張り、SSD-GPUから漏出するデータを減らす lineorder lineorder_p0 lineorder_p1 lineorder_p2 customer date supplier parts Scan Scan Scan Gather Agg 実行結果 Scan Join PreAgg Join PreAgg Join PreAgg GROUP BYまでGPUで済ませると、 ほとんどのデータはホスト側に 戻ってこない。 2018 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 30
31. ～100TB程度の ログデータを シングルノードで 処理可能に ４ユニットの並列動作で、 100～120GB/sの 実効データ処理能力 列データ構造により ユニット毎25～30GB/sの 実効データ転送性能 秒速で10億レコードを処理する（1/2） QPI SSD-to-GPU Direct SQL、列志向ストア、PCIeバス最適化の全てを投入 CPU2 CPU1 RAM RAM PCIe-SW PCIe-SW NVME0 NVME1 NVME2 NVME3 NVME4 NVME5 NVME6 NVME7 NVME8 NVME9 NVME10 NVME11 NVME12 NVME13 NVME14 NVME15 GPU0 GPU1 GPU2 GPU3 HBA0 HBA1 HBA2 HBA3 GPU+4xSSDユニット あたり8.0～10GB/sの 物理データ転送性能 31 PCIe-SW PCIe-SW JBOF unit-0 JBOF unit-1 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ Oct-2019
32. 秒速で10億レコードを処理する（2/2） Oct-2019 Supermicro 4029GP-TRT CPU: Xeon Gold 6226 (2.7GHz, 12C) x2 RAM: 192GB (16GB DDR4-2666) x12 GPU: NVIDIA Tesla V100 (5120C, 16GB) x4 SSD: Intel SSD DC P4510 (1.0TB, U.2) x16 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 32
33. ユーザ様事例 ▌背景 地方公共団体というユーザ様の性格上、 イントラネットで発生したセキュリティ事故 に関しては、Webやメール等のログを分析し、 その原因や影響範囲を特定して早期に報告を 行う必要があった。 ▌従来の課題 従来は、PostgreSQLのクラスタにシステム ログを分散して保存していた。 しかし、それでもTBを越えるログの検索に 40分以上を要する事が多々あり、事実上、 ログによる原因究明は機能せず。 ▌PG-Stromの適用による解決 新システムでは、SSD-to-GPU Direct SQLと BRINインデックスによる絞り込みを併用し、 平均して6GB/sのログ検索速度を実現。 検索クエリは30秒で応答を返すようになった。 この水準の性能を達成したことにより、 現場のエンジニアが使い慣れたPostgreSQLを 用いて、原因究明のためのトライ＆エラーを 繰り返すことが可能となった。 Dec-2019 システム ログ 従来システム： PostgreSQLのクラスターで構成 システム ログ 新システム： GPUとNVME-SSDを搭載した 2Uサーバに、PG-Stromを インストールして構成 某地方自治体様：ログ検索用システム GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 33
34. GTC-2020 (online) にて GPU Technology Conference 2020 基調講演より NVIDIA A100 ✓ 第8世代 Ampere アーキテクチャ ✓ 6,912個のCUDAコアと、最大80GiBのHBM2 DRAMを搭載 ✓ L2キャッシュサイズの拡大（V100の 6MB → 40MB） ✓ PCI-E 4.0 x16レーンでホストシステムと接続 長らく続いた PCI-E 3.0 世代からの切り替え。 GPU 1台あたり処理能力の目安は 20GB/s 強となり、 来たる PCI-E 5.0 世代では 40～50GB/s が見込まれる。 NVIDIA GPUDirect Storage May-2020 従来の自社製ドライバ（nvme_strom.ko）とほぼ 同等機能を有するソフトウェアスタックが、 NVIDIAよりCUDA Toolkitの標準機能のひとつとして 公式にリリースされると発表。 ➔ HeteroDB も事前評価に参加し、水面下で対応 作業を進めていた。 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 34
35. 次世代のPG-Stromで取り組むべきテーマ  PCI-E 4.0 / 5.0 の帯域幅に対応できる実装  同時接続数の増加に対応できるアーキテクチャ  省電力・低CO2排出（DPU対応） GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 35
36. GPU利用効率の改善（1/2） 非対称な処理を挟むとGPUのパフォーマンスは大きく劣化する • • • • • • • • • • LaneId: 0 1 2 3 4 27 28 29 30 31 Warp: unit of execution in GPU (32 simultaneous threads) 検索条件句の評価 F F F T F F F T F F 結果バッファの スロットを確保 被参照列を読み出し、 結果バッファへ追記 htup = LoadTupleFromSource(base_index+LaneId); rv = ExecEvalWhereClause(htup, whereClause); mask = __ballot_sync(__activemask(), rv); if (LaneId == 0) { count = __popc(mask); base = AllocateDestinationBuffer(count); } base = __shfl_sync(__activemask(), base, 0); if (rv) { mask &= ((1U << LaneId) - 1); dst_index = base + __popc(mask); ExecProjectionAndWriteBuffer(dst_index, htup, ProjectionList); } GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 36 2022
37. GPU利用効率の改善（2/2） PCI-E 3.0時代(12GB/s)はGPUの処理能力に余裕があったが、 PCI-E 5.0(50GB/s)になるとGPU側にもかなりの最適化が必要 Shared Counter 32レコードを 同時に読み出し WHERE条件句を 評価 ローカルバッファに 評価したレコードの ポインタを記録 ローカルバッファ内の レコード数 ≧ 32 F T ローカルバッファから 32レコードを 同時に読み出し 結果バッファに 32レコード分の 領域を確保 被参照列のみから成る レコードを、結果 バッファに書き出す 比較的複雑な処理は、常に32スレッドを飽和させるように設計変更！ GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 37 2022
38. PostgreSQL Backend リソース管理の改善 CUDA Contextの生成ごとに消費されるワーキングメモリの節約 従来のアーキテクチャ 新しいアーキテクチャ GPU PostgreSQL Backend CUDA Context PG-Strom PostgreSQL Backend CUDA Context PG-Strom PostgreSQL Backend CUDA Context PG-Strom Postmaster Process working memory working memory working memory fork(2) GPU PG-Strom PostgreSQL Backend Background Worker CUDA Context GPU Service (multi- threads) Postmaster Process working memory fork(2) PG-Strom Local connection to GPU Service ✓ コード品質やでバック手法に対する知見が十分で なかった時期、デバッグを容易にするメリット。 ✓ メモリコピーのコストをやや過大に見積もり。 ✓ CUDA Context初期化時間、およびワーキング メモリ（数百MB～1GB）の節約。 ✓ CUDA Contextスイッチの削減とGPU使用率改善 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 38 2022
39. DPUへの対応（1/2） GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 39 PCI-Eバス SSD➔GPU データ転送量：大 データ転送量：小 GPU➔CPU SQLを 実行 Smart-SSD データ転送量：小 Smart-SSD ➔ CPU PCI-Eバス NAND Flash （記憶素子） DPU GPU データ転送量：大 NAND Flash ➔ DPU NVME-SSD Smart-SSDの内部 現行技術：GPU-Direct SQL 新技術：Smart-SSD / Smart-NIC 版 PG-Strom Smart-NIC Smart-NIC ➔ CPU DPU 高速N/Wポート RDMA対応 100Gb/200Gb N/W NVME/GPUの能力をフルに 引き出したとしても、ここ がボトルネックになってし まう。 2023
40. DPUへの対応（2/2）～ 直感的なアーキテクチャの理解 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 40 ✓ 現在入手可能で最も強力なプロセッサで ある GPU を使用し、全力でNVME-SSDから データを流し込んで処理する方式。 ✓ GPUの計算能力に利点はあるが、PCI-E 4.0 では20.0GB/s程度、PCI-E 5.0でも40.0GB/s 程度で律速してしまい、それ以上データ を投入できなくなる。 （GPUが遊んでしまう問題） ✓ 今後、2023年以降に Smart-NIC/-SSD製品の 市場投入が本格的に進む。 ✓ GPUやCPUのようにパワフルではないが、 DPUはデータに近いところでSQLワーク ロードを処理できるため、転送すべき データ量自体を減らす事ができる。 ✓ 低消費電力で、サーバあたりの搭載数を 増やす事ができる。 GPU-Direct SQL （動力集中方式） Smart-SSD / Smart-NIC （動力分散方式） 2023
41. PG-Strom 10年の歩みと、その次の未来を振り返る。  はじまりは『あ、面白そう』から。  最適な設計は、その年代に利用可能なテクノロジに左右される。 ✓ 2014年に『デバッグ難しい』と投げ出したアーキテクチャも、 2022年にはソフトウェアスタックが安定し、再びメリットが勝ることに。 ✓ 2016年にPascal世代で memory overcommit が使えるようになった事で、 Maxwell以前に悩んでいたメモリ管理から解放される事となった。  PG-Stromの方向性を決定づけた GPU-Direct SQL 機構 ✓ GPU-DBとしては珍しい「I/Oワークロード」に注力するという方向性 ✓ PCI-E 4.0世代で 20GB/s、PCI-E 5.0世代では 40GB/s のデータ処理能力を ✓ 2021年からはNVIDIAもGPUDirect Storageという形で公式サポート  より“データに近い場所”を追求～Smart-NIC/-SSD対応 ✓ GPUほど強力ではないが、省電力かつ搭載台数を増やしやすい ✓ 2023年以降、各社からリリースされる製品への対応を準備中。 GPUがPostgreSQLを加速する ～PG-Strom 10年の歩みと、その次の未来へ～ 41
42. オモシロ技術を、カタチにする。