Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]

16,813 views

Published on

DB Tech Showcase Tokyo/2017での発表資料です。
PG-Stromの『SSD-to-GPUダイレクトGPU実行機能』にフォーカスした内容です。

Published in: Engineering
  • Hi there! Essay Help For Students | Discount 10% for your first order! - Check our website! https://vk.cc/80SakO
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]

  1. 1. GPUとSSDがPostgreSQLを加速する ~クエリ処理スループット10GB/sへの挑戦~ HeteroDB,Inc チーフアーキテクト 兼 代表取締役社長 海外 浩平 <kaigai@heterodb.com>
  2. 2. HeteroDB社について ▌会社プロフィール  商号: ヘテロDB株式会社  所在地: 東京都品川区西大井1ー1ー2  設立: 2017年7月4日(火)  事業内容: GPU/SSDによる高速SQLデータベース製品の開発・販売 GPU等の活用を含むSQLチューニングサービス  主要株主: 設立メンバーによる100%保有 ▌設立メンバー 海外 浩平(チーフアーキテクト 兼 代表取締役社長) OSS開発者コミュニティにおいて、Linux kernelやPostgreSQLデータベースの開発に10年以上従事。 PostgreSQLのSELinux対応やFDW機能拡張などコア機能強化に貢献しており、PostgreSQLのMajor Contributor として知られている。 2012年、 GPUによるPostgreSQLの高速化機構であるPG-Stromの開発に着手。以降、ヘテロジニアスコン ピューティング技術を用いたSQL処理の並列化・高速化技術の開発に注力し、現在に至る。 2007年 IPA未踏ソフトウェア創造事業において「天才プログラマ・スーパークリエータ」受賞、2014年 日本OSS推進フォーラムより「OSS貢献者賞」受賞 柏木 岳彦(チーフセールスエンジニア 兼 取締役副社長) NEC中央研究所において、スケールアウトインメモリデータベース、GPGPUをアクセラレータとするイン メモリカラムストアデータベースの研究に従事。また、NEC在職中は海外と共にPG-Stromプロジェクトの 一員としてユーザ開拓にあたる。 2015年にパラレルネットワーク合同会社を設立。ネットワーク製品・サービスの企画開発を行うと共に、 ヘテロDB社ではマーケティング、ユーザ開拓を担当。 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-2
  3. 3. コア技術 – PG-Strom DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-3 ▌特長  GPUの計算能力を活かして、 SQLワークロードをオフロード。 数千並列処理による高速化。  SQLからGPUプログラムを 自動生成し実行時コンパイル。 透過的な高速化を実現。  オープンソースソフトウェア。 ▌機能  WHERE句、JOIN、GROUP BYの GPU並列処理に対応  ユーザ定義CUDA関数(PL/CUDA) ▌用途  バッチ処理、集計・レポート  In-database統計解析・機械学習 Query Optimizer Query Executor PG-Strom Extension Storage Manager SQL Parser Application Storage PG-Strom: GPUを用いたPostgreSQL高速化拡張モジュール 共通のSQLクエリ 共通のデータ形式
  4. 4. GPUの特徴 数千コアの処理能力と数百GB/sのメモリ帯域を ワンチップに実装した並列演算プロセッサ CPU 小回りが利くが輸送力は小さな 乗用車のようなプロセッサ GPU 乗り降りは少し手間だが、大量輸送が 可能な高速鉄道のようなプロセッサ モデル Intel Xeon E5-2699v4 NVIDIA Tesla P40 トランジスタ数 7.2billion 12billion コア数 22 (functional) 3840 (simple) 理論性能 (FP32) 1.2 TFLOPS (with AVX2) 12TFLOPS メモリ容量 max 1.5TB (DDR4) 24GB (GDDR5) メモリ帯域 76.8GB/s 347GB/s TDP 145W 250W DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-4
  5. 5. GPU活用による計算 – 縮約アルゴリズムの例 ●item[0] step.1 step.2 step.4step.3 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支援によるコア間の同期機構 SELECT count(X), sum(Y), avg(Z) FROM my_table; 集約関数の計算で用いる仕組み DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-5
  6. 6. 画像データ処理はSQL処理に似ている? 画像データ = int/float[]型配列 転置 ID X Y Z SELECT * FROM my_table WHERE X BETWEEN 40 AND 60 並列処理 GPUの得意分野:同一の演算を大量のデータに対して適用する DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-6
  7. 7. PG-Stromが解決しようとする問題 RAM データ (small)  プリミティブなPG-Strom ✓ ヘビーSQL(JOIN、GROUP BY) ✓ データサイズはRAMに載る程度 2015年 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-7
  8. 8. PG-Stromが解決しようとする問題 RAM データ (small) データ (large) より計算集約的な ワークロードへ よりI/O集約的な ワークロードへ  PL/CUDA ✓ In-database統計解析・機械学習 ✓ 創薬、アノマリー検知  SSD-to-GPU ダイレクトSQL実行 ✓ H/W限界までI/Oを高速化 ✓ 大規模バッチ処理、レポーティング  プリミティブなPG-Strom ✓ ヘビーSQL(JOIN、GROUP BY) ✓ データサイズはRAMに載る程度 2017年 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-8
  9. 9. DB tech showcase での登壇は二回目です DBTS2014: GPGPUがPostgreSQLを加速する DBTS2017: GPUと SSD がPostgreSQLを加速する DB tech showcase 2014 適用領域の拡大とともに、新たなデバイスを活用する事に DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-9
  10. 10. PG-Stromのアーキテクチャ
  11. 11. PostgreSQLの内部構造 SQL Parser Query Optimizer Query Executor Storage Manager Transaction Manager IPC (Lock, Latch, shmem) SQLクエリ パース木 クエリ実行計画 クエリ 実行結果  SQL構文を分解し、取り扱いやすい 内部データ形式(パース木)に変換  文法エラーの検出  統計情報を元にコスト値を算出  最も合理的と予想される実行計画を 作成する。  クエリ実行計画に基づいて、 ScanやJoin、Sortなどを実行する。  PostgreSQL内部のインフラを使用 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-11
  12. 12. PostgreSQLはどのように実行計画を作るか (1/2) Scan t0 Scan t1 Scan t2 Join t0,t1 Join (t0,t1),t2 GROUP BY cat ORDER BY score LIMIT 100 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-12
  13. 13. PostgreSQLはどのように実行計画を作るか (2/2) Scan t0 Scan t1 Join t0,t1 統計情報) nrows: 120万行 width: 80 インデックス:なし 候補パス HashJoin cost=4000 候補パス MergeJoin cost=12000 候補パス NestLoop cost=99999 候補パス Parallel Hash Join cost=3000 候補パス GpuJoin cost=2500 WINNER! PostgreSQLビルトインの実行パス拡張モジュールによる提案 (PostgreSQL v9.5以降) (PostgreSQL v9.6以降) GpuJoin t0,t1 統計情報) nrows: 4000行 width: 120 インデックス:id列 複数の処理アルゴリズムを競わせ、“コスト値”で評価 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-13
  14. 14. CustomScanによる介入 同じ結果を返しさえすれば、手段は問わない。 CustomScan (GpuJoin) (*BeginCustomScan)(...) (*ExecCustomScan)(...) (*EndCustomScan)(...) : SeqScan on t0 SeqScan on t1 GroupAgg key: cat ExecInitGpuJoin(...)  GPUコンテキストの初期化  自動生成したGPUプログラムの 実行時コンパイル開始 ExecGpuJoin(...)  配下のt0,t1からデータを読み出し、 DMAバッファにセット  GPUへ非同期タスクをキック  実行が完了した非同期タスクを 取り出し、結果をGroupAggへ渡す。 ExecEndGpuJoin(...)  非同期タスクの終了待ち(あれば)  GPUリソースの解放 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-14
  15. 15. SQLからGPUコードを自動生成(WHERE句の例) DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-15 QUERY: SELECT cat, count(*), avg(x) FROM t0 WHERE x between y and y + 20.0 GROUP BY cat; : STATIC_FUNCTION(bool) gpupreagg_qual_eval(kern_context *kcxt, kern_data_store *kds, size_t kds_index) { pg_float8_t KPARAM_1 = pg_float8_param(kcxt,1); pg_float8_t KVAR_3 = pg_float8_vref(kds,kcxt,2,kds_index); pg_float8_t KVAR_4 = pg_float8_vref(kds,kcxt,3,kds_index); return EVAL((pgfn_float8ge(kcxt, KVAR_3, KVAR_4) && pgfn_float8le(kcxt, KVAR_3, pgfn_float8pl(kcxt, KVAR_4, KPARAM_1)))); } : 例) 条件句中の数値演算式を CUDA命令列にオンデマンドで変換 Reference to input data SQL expression in CUDA source code Run-time コンパイラ Parallel Execution
  16. 16. 簡単なマイクロベンチマーク DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-16 ▌Test Query: SELECT cat, count(*), avg(x) FROM t0 NATURAL JOIN t1 [NATURAL JOIN t2 ...] GROUP BY cat; ✓ t0 contains 100M rows, t1...t8 contains 100K rows (like a star schema) 8.48 13.23 18.28 23.42 28.88 34.50 40.77 47.16 5.00 5.46 5.91 6.45 7.17 8.07 9.22 10.21 0.0 5.0 10.0 15.0 20.0 25.0 30.0 35.0 40.0 45.0 50.0 2 3 4 5 6 7 8 9 QueryResponseTime[sec] Number of tables joined PG-Strom microbenchmark with JOIN/GROUP BY PostgreSQL v9.6 PG-Strom 2.0devel CPU: Xeon E5-2650v4 GPU: Tesla P40 RAM: 128GB OS: CentOS 7.3 DB: PostgreSQL 9.6.2 + PG-Strom 2.0devel
  17. 17. PG-Stromが解決しようとする問題 RAM データ (small) データ (large) より計算集約的な ワークロードへ よりI/O集約的な ワークロードへ どのようにして この領域へ踏み出すか? DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-17
  18. 18. ~GPUの役割を再定義する~ SSD-to-GPU Direct SQL Execution
  19. 19. SSD-to-GPUダイレクトSQL実行 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-19 Large PostgreSQL Tables PCIe Bus NVMe SSD GPUSSD-to-GPU P2P DMA (NVMe-Stromドライバ) WHERE句 JOIN GROUP BYPostgreSQL データブロック SQLに従ってレコードを 前処理する事で、 CPUがロード/処理すべき データ量を削減する。 従来のデータフロー (I/Oサイズ ... 大) SSDから直接GPUにデータを転送し、GPUでSQLワークロードを処理。 CPU/RAMへのロード前にデータを減らし、見かけ上I/O負荷を削減。
  20. 20. 要素技術① GPUDirect RDMA (1/2) ▌CPUを介さず、GPU他のPCIeデバイス間のP2Pデータ転送を行う機能  元々は、マルチノード環境でInfinibandを介したGPU間のデータ転送効率化技術  Linux kernelドライバを作成する事で、他の PCIe デバイスにも対応可能 Copyright (c) NVIDIA corporation, 2015 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-20
  21. 21. 要素技術① GPUDirect RDMA (2/2) 物理アドレス空間 PCIe BAR1領域 GPU デバイス メモリ RAM NVMe-SSD Infiniband HBA PCIe デバイス GPUDirect RDMA GPUデバイスメモリを 物理アドレス空間に マップする機能 『GPUデバイスメモリの物理アドレス』が 存在すれば、PCIeデバイスとのDMAで、 Source/Destinationアドレスとして指定でき る。 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-21 0xf0000000 0xe0000000 DMA要求 SRC: 1200th sector LEN: 40 sectors DST: 0xe0200000
  22. 22. 要素技術② NVMe-SSD DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-22 Intel SSD 750 Series Intel SSD P3608 Samsung PM1725 HGST Ultrastar SN260 Seagate Nytro XP7200 Interface PCIe 3.0 x4 PCIe 3.0 x8 PCIe 3.0 x8 PCIe 3.0 x8 PCIe 3.0 x16 Capacity 400GB, 800GB, 1.2TB 1.6TB, 3.2TB, 4.0TB 3.2TB, 6.4TB 1.6TB, 3.2TB, 6.4TB 3.8TB, 7.7TB Form Factor HHHL HHHL HHHL HHHL FHHL Max SeqRead 2.5GB/s 5.0GB/s 6.0GB/s 6.1GB/s 10.0GB/s Max SeqWrite 1.2GB/s 3.0GB/s 2.0GB/s 2.2GB/s 3.6GB/s Rand Read 460K IOPS 850K IOPS 1000K IOPS 1200K IOPS 940K IOPS Rand Write 290K IOPS 50K IOPS 120K IOPS 200K IOPS 160K IOPS Warranty 5years 5years 5years 5years 5 years MTBF 1.2M hours 1.0M hours 2.0M hours 2.0M hours 2.0M hours Target consumer enterprise / data-center 高速SSDの本命として、NVMe規格に対応した製品が各社からリリース
  23. 23. ベンチマーク環境 (1/2)  Server: Supermicro 5018GR-T  CPU: Intel Xeon 2650v4 x1  RAM: 128GB (16GB ECC DDR4-2166 x8)  GPU: NVIDIA Tesla P40  SSD: HGST SN260 (7.68TB)  HDD: SATA 1TB + 3TB x2  OS: CentOS 7.3 CUDA 8.0 + nvidia driver 375.51 NVMe-Strom driver  DB: PostgreSQL 9.6.4 PG-Strom v2.0devel  Data: Star Schema Benchmark (SF=401, 351GB) HGST社製 Ultrastar SN260 NVIDIA社製 Tesla P40 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-23
  24. 24. ベンチマーク環境 (2/2) – キーデバイス DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-24 model HGST Ultrastar SN260 Interface PCIe 3.0 x8 (NVMe 1.2) Capacity 7.68TB Form Factor HHHL Sequential Read 6,170MB/s Sequential Write 2,200MB/s Random Read 1200K IOPS Random Write 75K IOPS model NVIDIA Tesla P40 GPU Architecture NVIDIA Pascal Interface PCIe 3.0 x16 Form Factor FHFL, Dual-Slot # of CUDA cores 3840 Performance (FP32) 12 TFLOPS GPU Memory 24GB (GDDR5) GPU Memory Band 346GB/s TDP 250W SPECIAL THANKS FOR: SPECIAL THANKS FOR:
  25. 25. ベンチマーク結果 (1/2)  351GBのlineorderテーブルに対し、下記のクエリQ1~Q4をそれぞれ実行。 (351 * 1024)/(クエリ応答時間)を処理スループットとして定義。 Q1... SELECT count(*) FROM lineorder; Q2... SELECT count(*),sum(lo_revenue),sum(lo_supplycost) FROM lineorder; Q3... SELECT count(*) FROM lineorder GROUP BY lo_orderpriority; Q4... SELECT count(*),sum(lo_revenue),sum(lo_supplycost) FROM lineorder GROUP BY lo_shipmode; ※ PostgreSQL v9.6のCPU並列度は24を指定、PG-Strom v2.0develのCPU並列度は4を指定。 889.05 859.31 875.69 842.04 5988.0 5989.9 5988.8 5979.6 0 1000 2000 3000 4000 5000 6000 Q1 Q2 Q3 Q4 QueryExecutionThroughput[MB/s] PostgreSQL v9.6 + SN260 PG-Strom v2.0 + SN260 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-25
  26. 26. ベンチマーク結果 (2/2)  物理メモリ 128GB のマシンで351GBのテーブルを全件スキャンしている事から、 ワークロードの律速要因はストレージ。  PG-Stromの場合、SSDのカタログスペックに近い読出し速度を達成できている。  PostgreSQLの場合、I/Oに伴うオーバーヘッドが大きい。 0 1000 2000 3000 4000 5000 6000 7000 0 100 200 300 400 StorageReadThroughput[MB/s] Elapsed Time for Query Execution [sec] Time Series Results (Q4) with iostat PG-Strom v2.0devel + SN260 PostgreSQL v9.6 + SN260 [kaigai@saba ~]$ iostat -cdm 1 : Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn sda 6.00 0.19 0.00 0 0 sdb 0.00 0.00 0.00 0 0 sdc 0.00 0.00 0.00 0 0 nvme0n1 24059.00 5928.41 0.00 5928 0 : DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-26
  27. 27. ハードウェア構成に関する考慮事項 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-27 ① PCIeスイッチを介して SSDとGPUが接続の場合 OK ② CPUがPCIeバスを管理し、 SSDにGPU直接接続の場合 Workable ③ SSDとGPUが互いに異なる CPUに接続の場合 Not Supported CPU CPU PLX SSD GPU PCIeスイッチ この接続トポロジは HeteroDB 環境で検証済 み。 転送レート~9.5GB/sまでは記録した実績あ り。 (CPUはXeon E5-2650 v4) 非常に遅い。数十~数百MB/s程度の 転送レートしか出ないので、避けな ければならない。 CPU CPU SSD GPU CPU CPU SSD GPU QPI Pros: 対応HWが入手しやすい Cons: 最大スループットが PLXよりも低い Pros: 最大限のスループットを 発揮できる(らしい) Cons: 対応HWが限られる。 Pros: なし Cons: 遅い or 動かない
  28. 28. PostgreSQLのI/O性能に関する考察 ① 小さなブロックサイズによる大量のシステムコール呼び出し ② ブロックレイヤ/ファイルシステムでの複数回のバッファコピー PostgreSQL (Shared Buffer) ファイルシステム (Page Cache) ブロックデバイス (DMA Buffer) NVMe-SSD read(2) DMA要求 DMA完了 memcpy to Page Cache memcpy to Shared Buffer 集計処理集計処理 request to block read NVMe-SSDにより デバイスの遅延は 劇的に改善 バッファ間コピー システムコール 呼び出し DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-28
  29. 29. NVMe-Strom ソフトウェアスタック DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-29 pg-strom NVMe-Strom driver VFS (ext4/xfs) Page Cache NVMe SSD Driver nvidia driver GPU device memory PostgreSQL cuMemAlloc() /proc/nvme-strom read(2) User Space Kernel Space
  30. 30. NVMe-Strom ソフトウェアスタック DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-30 pg-strom NVMe-Strom driver VFS (ext4/xfs) Page Cache NVMe SSD Driver nvidia driver GPU device memory GPU device memory PostgreSQL cuMemAlloc() /proc/nvme-strom ioctl(2) read(2) User Space Kernel Space
  31. 31. NVMe-Strom ソフトウェアスタック DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-31 pg-strom NVMe-Strom driver VFS (ext4/xfs) Page Cache NVMe SSD Driver nvidia driver GPU device memory GPU device memory PostgreSQL DMA request File offset? SSD-to-GPU Peer-to-Peer DMA cuMemAlloc() /proc/nvme-strom ioctl(2) read(2) User Space Kernel Space Exists? Block Number
  32. 32. 【補足】 ディスクキャッシュと一貫性を保つための工夫 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-32  課題 ①対象ブロックがOSキャッシュに保持されている場合、ストレージブロックの内容は 最新でない可能性がある。 ②8KB単位のコマ切れDMA(RAMGPU)は非常に性能が悪い  対策 キャッシュされているブロック(=8KB単位)を一度ユーザ空間のバッファに書き戻し、 その後 CUDA API を用いて、一度に RAMGPU 転送を行う。 ✓ 処理ペナルティ的には read(2) + cuMemcpyHtoDAsync() と同等 ✓ GPUメモリ上でのブロック並び順が変わるが、処理の妥当性に影響はない。 BLK-100: uncached BLK-101: cached BLK-102: uncached BLK-103: uncached BLK-104: cached BLK-105: cached BLK-106: uncached BLK-107: uncached BLK-108: cached BLK-109: uncached BLCKSZ (=8KB) Transfer Size Per Request BLCKSZ * NChunks BLK-108: cached BLK-105: cached BLK-104: cached BLK-101: cached BLK-100: uncached BLK-102: uncached BLK-103: uncached BLK-106: uncached BLK-107: uncached BLK-109: uncached BLK-108: cached BLK-105: cached BLK-104: cached BLK-101: cached unused SSD-to-GPU P2P DMA File Userspace DMA Buffer (RAM) Device Memory (GPU) CUDA API (userspace) cuMemcpyHtoDAsync
  33. 33. クエリ処理スループット10GB/sへの挑戦
  34. 34. なぜシングルノード 10GB/s を目指すのか? DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-34 そこに山があるからではない。
  35. 35. なぜシングルノード 10GB/s を目指すのか? 一世代前のDWH専用機 処理性能:8.6GB/s お値段:数千万円~ システム更新時期 さて、後継システムは? 小規模なHadoopクラスタ 運用:複数台サーバの 管理はそれなりに面倒 シングルノードかつ SQLで同等性能が可能なら?  集計・解析系はGPU/SSDにより強化 前世代のDWH専用機に匹敵する処理能力  1/10の製品価格  DBMSとしての基本機能は、長年にわたる 実績を有する PostgreSQL そのもの。  バックアップ、レプリケーション、 各種ドライバ、周辺ツール類 HeteroServer 120GS (2018年3月リリース予定) DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-35
  36. 36. (与太話) GTC2017 – SSD-to-GPU機能がTop-5ポスターに選出 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-36 世界中から集まったGPU関連R&Dの ポスター発表全138件のうち、 最も評価の高い5件の一つとして選出。 (来場者投票では惜しくも次点…) GPU Technology Conference 2017 8th~ 11th May, San Jose 5月時点では、SSD x3枚構成 理論値6.6GB/sに対して 実測性能は4.5GB/s。なぜか?
  37. 37. プロファイラを使って詳しく見てみる。 Dynamic Parallelismを使って起動した GPUサブカーネルの消費時間が 異常に少ない(= 10%程度) DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-37
  38. 38. プロファイラを使って詳しく見てみる。 GPUサブカーネルの同期のために、 本来のSQL処理を行うGPUカーネルの 多重度が非常に低くなっていた。 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-38
  39. 39. GPU内の同期ポイント削減の効果 GPU使用率に余裕が出てきた。  再びストレージ律速に。10GB/sは十分耐えられそう。 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-39
  40. 40. 10GB/sのクエリ処理スループットを実現するために ▌GPUカーネル 同期ポイントの削減  GpuScan, GpuPreAgg は既に対応完了  GpuJoin の対応作業が進行中 ▌GPUタスクスケジューラの改善  Dynamic Parallelismの不使用と、Unified Memoryの利用により、 GPU関連処理を(別プロセスの)GPUサーバで実行せずに済む。 ▌GpuScan + GpuJoin + GpuPreAgg Combined Kernel  典型的な集計処理を実行する際にCPUを介在させない。  スキャンが完了した時点で、既にJOIN/GROUP BYが完了している。 ▌md-raid0 (ストライピング) の最適化  複数枚のNVMe-SSDを束ねる事で、 GPUへ10GB/sのバンド幅でデータを供給する。 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-40
  41. 41. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (1/5) Aggregation GROUP BY JOIN SCAN SELECT cat, count(*), avg(x) FROM t0 JOIN t1 ON t0.id = t1.id WHERE y like ‘%abc%’ GROUP BY cat; count(*), avg(x) GROUP BY cat t0 JOIN t1 ON t0.id = t1.id WHERE y like ‘%abc%’ 実行結果 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-41 GpuScan GpuJoin Agg + GpuPreAgg
  42. 42. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (2/5) GpuScan kernel GpuJoin kernel GpuPreAgg kernel DMA Buffer Agg (PostgreSQL) GPU CPU Storage 単純にロジックを置き換えるだけでは、CPU<->GPU間の データ転送のピンポンが発生してしまう。 DMA Buffer DMA Buffer 実行 結果 DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-42
  43. 43. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (3/5) 構造の単純なWHERE句評価は、既にJOINと同じタイミングで 実行するようになっている。 GpuScan kernel GpuJoin kernel GpuPreAgg kernel DMA Buffer Agg (PostgreSQL) GPU CPU Storage DMA Buffer 実行 結果 GpuScan + GpuJoin DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-43
  44. 44. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (4/5) 集約演算まで一気にGPU側で行ってしまう事で、 ロードすべきデータ量を極端に削減する事ができる。 GpuScan kernel GpuJoin kernel GpuPreAgg kernel DMA Buffer Agg (PostgreSQL) GPU CPU Storage 実行 結果 GpuScan + GpuJoin + GpuPreAgg Combined Kernel data size = large data size = small DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-44
  45. 45. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (5/5) DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-45 10GBのデータをスキャンして、 最終的にCPU側へ書き戻されたのは 1.2kB のみ。
  46. 46. PG-Strom v2.0 へ向けて Dec-2017, PG-Strom v2.0 beta Mar-2018, PG-Strom v2.0 GA HeteroServer 120GS 新機能の開発  SSD-to-GPUダイレクトSQL実行周辺機能強化  GPUタスクスケジューラ改良  On-GPUデータストア(Foreign Table)  列指向キャッシュ  In-database統計解析・機械学習ライブラリ  テスト・品質安定化  パッケージング  ドキュメンテーション 先進ユーザの開拓 Open Source Activity Business Activity DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-46
  47. 47. ~ハードウェア限界を超えて~ インテリジェント・ストレージ構想
  48. 48. OLTPの世界 OLAPの世界 インテリジェント・ストレージ構想 (1/2) DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-48 SSD上でRow-to-Column変換により、Rowで書いてColumnで読む R/C 変換 ロジック 列データ 解析系データ 読出し (列形式) 業務データ 書込み (行データ) データ形式変換 FPGA等による H/W実装 SQLクエリ処理 GPU本来の計算能力を 引き出す列データ形式 集計済み、 JOIN済み データ 列抽出において 必要なデータだけ 取出し
  49. 49. なぜGPUには列志向のデータが向いているか DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-49 ▌行データ形式 – 不連続なデータアクセス (random memory access)  メモリトランザクションの回数が増え、データバスの使用率が低下 ▌列データ形式 – 隣接領域に対するデータアクセス (coalesced memory access)  最小限のメモリトランザクション回数、データバスの使用率を最大化 32bit Memory transaction width: 256bit 32bit 32bit32bit 32bit 32bit 32bit 32bit 32bit 32bit 32bit 32bit 32bit 32bit Memory transaction width: 256bit 256bit幅のメモリトランザクション 中、 32bit x 8 = 256bitが有効なデータ (バス使用率 100.0%) 256bit幅のメモリトランザクション中、 32bit x 1 = 32bitのみ有効なデータ (バス使用率 12.5%) GPUコア GPUコア GPUの能力をフルに引き出すには、適切なデータ形式の選択が必要
  50. 50. インテリジェント・ストレージ構想 (2/2) DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-50 Large PostgreSQL Tables PCIe Bus “SQL-aware” NVMe SSD GPU SSD-to-GPU P2P DMA WHERE句 JOIN GROUP BYPostgreSQL データブロック 行データ列データ変換 必要なデータのみを抽出する事で、 PCIeバスの帯域以上の実効データ転送 GPUでの“超”並列SQL実行 入力データのフォーマットを列形式と する事で、最大限のGPU性能を発揮 行データとして書込み トランザクション性能に 影響を与えず、リアル タイム集計・分析を可能に
  51. 51. THANK YOU! contacts e-mail: kaigai@heterodb.com tw: @kkaigai

×