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.

20180217 FPGA Extreme Computing #10

3,730 views

Published on

第10回 FPGAエクストリーム・コンピューティング勉強会 資料

Published in: Software
  • Be the first to comment

20180217 FPGA Extreme Computing #10

  1. 1. SSD/GPUがPostgreSQLを加速する。 ~ハードウェア限界性能への挑戦~ HeteroDB,Inc チーフアーキテクト 兼 代表取締役社長 海外 浩平 <kaigai@heterodb.com>
  2. 2. HeteroDB社について FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)2 ▌会社概要  商号 ヘテロDB株式会社  創業 2017年7月4日  社員数 2名(海外浩平、柏木岳彦)  事業内容 データ解析アプライアンス製品販売 データベース技術コンサルティングサービス  拠点 品川区西大井1-1-2-206 (西大井創業支援センター内) ▌代表者プロフィール  海外 浩平 (KaiGai Kohei)  OSS開発者コミュニティにおいて、PostgreSQLやLinux kernelの 開発に10年以上従事。セキュリティ強化や外部データ連携等の 貢献があり、PostgreSQLのMajor Contributorとして知られている。  2007年 IPA未踏ソフト事業において “天才プログラマー” 認定  2012年~ GPUによるPostgreSQL高速化モジュールの開発を開始  2017年 NECを退職し、柏木と共に HeteroDB 社を創業
  3. 3. 【期間限定】自己紹介 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)3 カーリングやってます。
  4. 4. 最近の話題:まさかの日経デビュー FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)4
  5. 5. 我々のミッション + GPUを用いたSQL処理の高速化製品の提供 GPU PG-Strom FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)5
  6. 6. データ解析基盤としての用途  バッチ/レポーティング  ビジネスインテリジェンス  異常検知/ログ解析  統計解析/機械学習 etc... RDBMSとしての本質的な機能  SQLパース/クエリ最適化  トランザクション  バックアップ/可用性  レプリケーション  スケールアウト  周辺ツールとの接続 etc... PG-Stromとは? (1/2) 一部処理のオフロード PG-Strom: GPUの持つ数千並列コアと広帯域メモリを活用して SQLワークロードを高速化するPostgreSQL向け拡張モジュール 自前で何もかも揃えるのではなく、 PostgreSQL本体機能・周辺機能を 必要に応じてチョイスする。 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)6
  7. 7. PostgreSQLの共通インフラ PG-Stromとは? (2/2) FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)7 SQL Parser Query Optimizer Query Executor Storage PG-Strom CustomScan Interface Database Applications Storage Manager Transaction Manager Parallel Workers 【I/O中心ワークロードの高速化】  SSD-to-GPUダイレクトSQL実行  インメモリ列指向キャッシュ  JOIN+GROUP BY Combined kernel 【基本機能】 • SQL to GPUプログラムジェネレータ • GPUコード実行時コンパイラ • GPUカーネルの非同期並列実行 【計算中心ワークロードの高速化】  PL/CUDA ユーザ定義関数  gstore_fdw – onGPUデータストア  In-DB 機械学習ライブラリ v2.0 v2.0
  8. 8. PostgreSQL/PG-Stromは どのようにクエリを実行するか
  9. 9. PostgreSQLの内部構造 SQL Parser Query Optimizer Query Executor Storage Manager Transaction Manager IPC (Lock, Latch, shmem) SQLクエリ パース木 クエリ実行計画 クエリ 実行結果  SQL構文を分解し、取り扱いやすい 内部データ形式(パース木)に変換  文法エラーの検出  統計情報を元にコスト値を算出  最も合理的と予想される実行計画を 作成する。  クエリ実行計画に基づいて、 ScanやJoin、Sortなどを実行する。  PostgreSQL内部のインフラを使用 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)9
  10. 10. PostgreSQLはどのように実行計画を作るか (1/2) Scan t0 Scan t1 Scan t2 Join t0,t1 Join (t0,t1),t2 GROUP BY cat ORDER BY score LIMIT 100 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)10
  11. 11. 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列 複数の処理アルゴリズムを競わせ、“コスト値”で評価 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)11
  12. 12. 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リソースの解放 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)12
  13. 13. PG-Strom基本機能(1/2) – SQLからGPUコードを自動生成 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)13 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 Compiler (nvrtc) Just-in-time Compile Parallel Execution v1.0
  14. 14. PG-Strom基本機能(2/2) – 非同期・並列実行 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)14 非同期DMA転送 GPUメモリ GPU搭載の数千コアによる 並列実行 処理済みのブロックは開放 GPUへのデータ転送と、GPUでのSQL処理をパイプライン化する事で PCIeバスのデータ転送速度の “遅さ” を隠ぺい。  同時に、GPU RAMサイズ以上のデータを効率的に処理する事が可能に。 約64MBのブロック毎に転送 平均10万~30万行を含む GPU上のバッファに余裕がある限り、 先行ブロックの処理完了を待たず、 次々にデータを送り込む。 v1.0
  15. 15. 実際にユーザ様の課題をヒアリングしてみると・・・。 I/O (ストレージ) 計算 (CPU) 『大量データの処理で困ってるんです・・・』  実際にはCPU以上にI/O問題である事もしばしば FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)15
  16. 16. 果たして I/O のボトルネックを PG-Strom で解消できるのか? FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)16
  17. 17. SSD-to-GPUダイレクトSQL実行 ~GPUの役割を再定義する~
  18. 18. SSD-to-GPUダイレクトSQL実行とは FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)18 PCIe Bus NVMe SSD GPU SSD-to-GPU P2P DMA (NVMe-Stromドライバ) WHERE句 JOIN GROUP BY Large PostgreSQL Tables PostgreSQL データブロック SSD-to-GPUダイレクトSQL SSDから転送したレコードを、 GPUの数千コアを用いて SQLワークロードを実行。 CPUがロード/処理すべきデータ 量を削減し、I/Oを高速化。 従来のデータフロー 本来は不要なレコードであっても、 一度CPU/RAMへロードしなければ 要・不要を判断できないため、 データサイズは大きくなりがち。 SELECT cat, count(*), avg(X) FROM t0 JOIN t1 ON t0.id = t1.id WHERE YMD >= 20120701 GROUP BY cat; SQL最適化ステージ SQL実行ステージ SQL-to-GPU プログラム ジェネレータ GPUコード 実行時 コンパイル SQLからGPUプログラムを 自動的に生成し、実行時 コンパイルを行う ストレージからデータをロードする“前に” GPUでデータ量を減らす。 GPUコード生成 SQLから自動的にGPU コードを生成するため、 利用者からは透過的に GPUを使用するように 見える。 GPUでのSQL実行 PostgreSQLのデータ ブロックを、直接 SSDからGPUへ転送。 SQLワークロードを GPU上で並列実行する 事で、不要なデータを ふるい落とす。 CPUでのSQL実行 GPUで前処理済みの データを処理するため、 本来のデータ量よりも 遥かに小さな負荷を 処理するだけで済む。 v2.0
  19. 19. 要素技術① GPUDirect RDMA (1/2) ▌CPUを介さず、GPU他のPCIeデバイス間のP2Pデータ転送を行う機能  元々は、マルチノード環境でInfinibandを介したGPU間のデータ転送効率化技術  Linux kernelドライバを作成する事で、他の PCIe デバイスにも対応可能 Copyright (c) NVIDIA corporation, 2015 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)19
  20. 20. 要素技術① GPUDirect RDMA (2/2) 物理アドレス空間 PCIe BAR1領域 GPU デバイス メモリ RAM NVMe-SSD Infiniband HBA PCIe デバイス GPUDirect RDMA GPUデバイスメモリを 物理アドレス空間に マップする機能 『GPUデバイスメモリの物理アドレス』が 存在すれば、PCIeデバイスとのDMAで、 Source/Destinationアドレスとして指定できる。 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)20 0xf0000000 0xe0000000 DMA要求 SRC: 1200th sector LEN: 40 sectors DST: 0xe0200000
  21. 21. 要素技術② NVMe-SSD FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)21 Intel SSD 750 Series Intel SSD DC P4600 Samsung PM1725 HGST Ultrastar SN260 Seagate Nytro 5910 Interface PCIe 3.0 x4 PCIe 3.0 x4 PCIe 3.0 x8 PCIe 3.0 x8 PCIe 3.0 x16 Capacity 400GB, 800GB, 1.2TB 2.0TB, 4.0TB 3.2TB, 6.4TB 1.6TB, 3.2TB, 6.4TB 7.7TB Form Factor HHHL HHHL HHHL HHHL FHHL Max SeqRead 2.5GB/s 3.2GB/s 6.0GB/s 6.1GB/s 8.0GB/s Max SeqWrite 1.2GB/s 1.9GB/s 2.0GB/s 2.2GB/s 4.7GB/s Rand Read 460K IOPS 617K IOPS 1000K IOPS 1200K IOPS 975K IOPS Rand Write 290K IOPS 225K IOPS 120K IOPS 200K IOPS 130K 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規格に対応した製品が各社からリリース
  22. 22. ベンチマーク (1/3) – SSBMベンチマーク環境 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)22 ■ クエリ例 SELECT sum(lo_revenue), d_year, p_brand1 FROM lineorder, date1, part, supplier WHERE lo_orderdate = d_datekey AND lo_partkey = p_partkey AND lo_suppkey = s_suppkey AND p_category = 'MFGR#12‘ AND s_region = 'AMERICA‘ GROUP BY d_year, p_brand1 ORDER BY d_year, p_brand1; customer 1200万件 (1.6GB) date1 2500件 (400KB) part 180万件 (206MB) supplier 400万件 (528MB) lineorder 24億件 (351GB) 典型的な Star Schema に JOIN, GROUP BY を含む集計クエリを実行 v2.0 読出し: 2.2GB/s Intel SSD 750 3840コア搭載 NVIDIA Tesla P40 測定環境 Chassis Supermicro 5018GR-T CPU Xeon E5-2650v4 (2.2GHz, 12C) x1 RAM 128GB (16GB DDR4-2133 x 8) GPU NVIDIA Tesla P40 (3840C, 24GB) x1 SSD Intel SSD 750 (HHHL; 400GB) x3 OS Red Hat Enterprise Linux 7.4 CUDA 9.0 + Latest driver DB PostgreSQL v9.6 + PG-Strom 2.0devel
  23. 23. ベンチマーク (2/3) – SSBMによるスループット計測 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)23 ▌典型的なバッチ・レポーティング処理を模した Star Schema Benchmark にて計測  PostgreSQLの処理速度は 2.1GB/s 程度で頭打ち(SSDを3枚束ねた場合)  SSD-to-GPUダイレクトSQL実行を用いるPG-Stromの場合、ハードウェア限界に近い 6.2GB/s 近くまで処理性能を引き出せている。  従来はDWH専用機や小規模クラスタを用いていた水準の能力を1台のマシンで。 SSD x2枚構成の 理論限界値 [4.4GB/s] SSD x3枚構成の 理論限界値 [6.6GB/s] v2.0
  24. 24. 〈参考〉GTC2017でSSD-to-GPU機能の発表がTop-5に選出 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)24 世界中から集まったGPU関連R&Dの ポスター発表全138件のうち、 最も評価の高い5件の一つとして選出。 (来場者投票では惜しくも次点…) GPU Technology Conference 2017 8th~ 11th May, San Jose
  25. 25. 〈補足〉ハードウェア構成に関する考慮事項 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)25 ▌課題 ① CPUのP2P DMAルーティング性能 ② マルチGPU環境への適用 ① PCIeスイッチを介して SSDとGPUが接続の場合 OK ② CPUがPCIeバスを管理し、 SSDにGPU直接接続の場合 Workable ③ SSDとGPUが互いに異なる CPUに接続の場合 Not Supported CPU CPU PLX SSD GPU PCIeスイッチ CPU CPU SSD GPU CPU CPU SSD GPU QPI SSDとGPUのペアは、同一CPUまたはPLXの配下に接続されている必要がある
  26. 26. BroadwellとSkylakeでP2P DMA性能に差はあるか。 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)26 NVMe-SSD Intel DC P4600 (2.0TB) x3 (md-raid0構成) NVIDIA Tesla V100 (5120C, 16GB) CPU Intel Xeon Gold 6126T (12C, 2.6GHz) 測定用に新しいサーバを買っちゃった!
  27. 27. ベンチマーク (3/3) – Skylake + Volta GPUによる計測 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)27 ▌Raw-I/O性能で8.5GB/s、SQL応答時間ベースで7.5GB/sのスループット  Broadwellの7.2GB/sという限界値は突破してくれた ▌疑問)標準PostgreSQLの性能値がやたら落ちているのでは? 0 1000 2000 3000 4000 5000 6000 7000 8000 Q1_1 Q1_2 Q1_3 Q2_1 Q2_2 Q2_3 Q3_1 Q3_2 Q3_3 Q3_4 Q4_1 Q4_2 Q4_3 QueryExecutionThroughput[MB/s] Star Schema Benchmark (on SkyLake + Volta) PgSQL v10 PG-Strom v2.0
  28. 28. 余談)Spectre/Meltdown対策パッチの影響?? FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)28 0 200 400 600 800 1000 1200 1400 1600 1800 Q1_1 Q1_2 Q1_3 Q2_1 Q2_2 Q2_3 Q3_1 Q3_2 Q3_3 Q3_4 Q4_1 Q4_2 Q4_3 QueryExecutionThroughput[MB/s] Star Schema Benchmark / with PostgreSQL 10 kernel-3.10.0-693.el7.x86_64 (対策前) kernel-3.10.0-693.11.6.el7.x86_64 (対策済) ▌全般的に10-15%程度のデグレードがあるが、 2.2GB/s  1.4GB/sを説明できるほど顕著な差ではない。 ▌現時点ではまだ納得のいく答えが得られていない。Any Ideas?
  29. 29. マルチGPU環境への対応に向けて (1/2) FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)29 ▌~PostgreSQL v10までの課題  ある一時点においては、常に特定の1テーブルだけがスキャンの対象  SSD-to-GPUダイレクトSQL実行を使うには、SSDに近傍のGPUを選択しなければならない。  複数GPU搭載でも、スキャン中のテーブルを保存するSSDに近傍のGPUだけがアクティブ となり、リソース有効活用の面で課題があった。 PostgreSQL v10までは、パーティション子テーブルの並列スキャンに非対応 t1 t2 t3 t4 Append ~PostgreSQL v10 t1 t2 t3 t4 Append PostgreSQL v11以降 ※個々の子テーブルの スキャンが並列化 される事はある パーティション配下の子テーブル 全てを並列にスキャン
  30. 30. マルチGPU環境への対応に向けて (2/2) FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)30  ワーカーの並列化に伴い、GPU1/GPU2を同時に利用する事が可能に  マルチGPU環境においても、計算機資源を有効に活用できることに。 Append ワーカーの起動時に対象SSDの近傍GPUを選択し、複数GPUを同時利用可能に t1 t2 t4t3 GPU1 GPU2 BgWorker BgWorker BgWorker BgWorker CPU並列処理用の ワーカープロセス テーブル t1 を保存する SSDと同一のCPUに接続 されているGPU1を選択 PCIe接続トポロジーに 基づく自動チューニング
  31. 31. ハードウェア限界を越える ~インテリジェントストレージ構想~
  32. 32. 更なる性能向上を目指すには FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)32 ▌方針① SSDから読み出すデータ量を減らす ▌方針② CPUにP2P DMAを仲介させない NVMe SSD GPU CPU PCIeバス P2P DMA Packet ルーティング性能の 限界 NVMe-SSD読出し 速度での律速 実はGPUには 処理能力に 余裕がある
  33. 33. OLTPの世界 OLAPの世界 インテリジェント・ストレージ構想(1/3) – SSD上の行⇒列変換 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)33 SSD上でRow-to-Column変換を行い、Rowで書いてColumnで読む R/C 変換 ロジック 列データ 解析系データ 読出し (列形式) 業務データ 書込み (行データ) データ形式変換 FPGA等による H/W実装 SQLクエリ処理 GPU本来の計算能力を 引き出す列データ形式 集計済み、 JOIN済み データ 列抽出において 必要なデータだけ 取出し
  34. 34. インテリジェント・ストレージ構想(2/3) – SSD上の行⇒列変換 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)34 カスタムロジックを搭載可能な NVMe-SSD 製品が 容易に入手可能になりつつある。 Nallatech社 250Sシリーズ NGD Systems社 Catalina 2 NVMe PCIe SSD SSD上のロジックは単純で汎用性の高いデータ形式変換に特化 集積度の高いGPUでは、処理内容が都度変化するSQLを“超”並列実行 PostgreSQLデータブロック カスタムロジック PageHeader ItemPointers Record-01Record-02 Record-03Record-04Record-05 Record-06Record-07 Record-08Record-09 列A 列D 列F
  35. 35. 《補足》なぜGPUには列指向のデータが向いているか FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)35 ▌行データ形式 – 不連続なデータアクセス (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の能力をフルに引き出すには、適切なデータ形式の選択が必要
  36. 36. SCAN + JOIN + GROUP BY Combined Kernel (1/3) 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%’ 実行結果 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)36 GpuScan GpuJoin Agg + GpuPreAgg v2.0 PostgreSQLは集計クエリを何ステップかに分解して実行する。 データ受け渡し データ受け渡し
  37. 37. SCAN + JOIN + GROUP BY Combined Kernel (2/3) 集約演算まで一気にGPU側で行ってしまう事で、 ロードすべきデータ量を極端に削減する事ができる。 GpuScan kernel GpuJoin kernel GpuPreAgg kernel Agg (PostgreSQL) GPU CPU Storage 実行 結果 GpuScan + GpuJoin + GpuPreAgg Combined Kernel data size = large data size = small FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)37 v2.0 Data Blocks
  38. 38. SCAN + JOIN + GROUP BY Combined Kernel (3/3) FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)38 10GBのデータをスキャンして、 最終的にCPU側へ書き戻されたのは 1.2kB のみ。 v2.0
  39. 39. 〈参考〉PCIe拡張I/Oボックス製品 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)39 世の中には PCIe バスを引き延ばして外部I/O拡張Boxに接続する製品がある。 • 直接GPUを装着するのに比べて 省スペース。 • (製品によっては)I/O拡張Boxの 内部でP2P DMAを完結できる。
  40. 40. トランザクション制御 (シングルノード) インテリジェント・ストレージ構想(3/3) – エッジ側SQL実行 外部PCIe拡張ユニットを用いてSSD/GPUペアを拡張し、 ハードウェア限界を超えたスループットを実現する。 アップリンク・データフロー PCIe拡張Box内部でのSQL前処理により、 相対的にI/Oサイズは小さくなる。 もはやホストシステム自身の バス幅は律速要因ではなくなる。 エッジ・データフロー 最大限のスループットで SSDからGPUへデータを 読み出し、SQL前処理で データ量を削減するadopter adopter adopter トランザクション制御の世界 大量データ処理の世界 必要に応じて ユニットの 増設も可能 PostgreSQLから見ると、単に大量のGPUとSSDを 搭載しただけのシングルノード構成。 複雑な分散トランザクションを使用する必要が ないため、運用をシンプル化できる。 PCIe拡張ユニット内で完結するP2P DMAのトラフィックがアップリンク側に 漏れなければ、スペック及びGPUの処理能力からみて、一台あたり10GB/sの 処理性能は十分に実現可能。 データサイズの増加に伴い、PCIe拡張ユニットを増設する事で対応できる。 FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)40 PCIe Switch PCIe Switch PCIe Switch
  41. 41. まとめ FPGAエクストリーム・コンピューティング勉強会#10 (2018-02-18)41 ▌PG-Stromとは?  GPUを使ってSQL集計・解析ワークロードを高速化する拡張モジュール  GPUプログラムの自動生成、非同期・並列実行 ▌GPUでI/Oが早くなるワケないじゃん!?  P2P DMAを使ってSSD上のデータブロックを直接GPUに転送 データをロードすれば、SQL処理の実行は元々やっている事 SCAN/JOIN/GROUP BYを前処理する事で、データ量を大幅に削減  I/OネックのStar Schema Benchmarkで、処理スループット 7.5GB/s を達成 少し前のDWH専用機に匹敵する性能を1Uラックサーバで実現 ▌ハードウェアの限界を越える  ロジック付きSSD上で、行形式⇒列形式へ変換しデータ量を削減。  PCIe 拡張I/O Boxを使用して、本体に負荷をかけず ”ノード内分散処理” いずれのケースでも、ユーザ/アプリ視点からは単純な シングルノードのPostgreSQLに見える。分散トランザクション等不要。

×