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.

20170310_InDatabaseAnalytics_#1

6,350 views

Published on

SSD/GPUがPostgreSQLを加速する
~ハードウェア性能を限界まで引き出すPG-Stromの挑戦~

Published in: Technology
  • Login to see the comments

20170310_InDatabaseAnalytics_#1

  1. 1. GPU/SSDがPostgreSQLを加速する ~ハードウェア性能を限界まで引き出すPG-Stromの挑戦~ The PG-Strom Development Team 海外 浩平 <kaigai@kaigai.gr.jp> / @kkaigai
  2. 2. The PG-Strom Project DBMS as literal.... ▌データベース (Database) ▌データベース管理システム (DBMS: Database Management System)  DBMSこそが最もデータに近いソフトウェア! concept: データに近い場所で計算する In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する3
  3. 3. The PG-Strom Project In-database Analyticsの利点  データベース管理システムの計算能力は 不十分で、高度なアルゴリズムの処理には、 データのエクスポートが必要であった。  データ量が多いと転送時間が無視できない。  データを手元で二重管理する事になる。  前処理/後処理でのデータ加工が難しい。 (スクリプトなどの開発が必要)  本来の作業目的である、仮説検証に 割ける時間が浪費されてしまう。  アクセラレータによってデータベース管理 システムの計算能力を増強する事で、 『データのある場所で』 高度なアルゴリズムを 実行する事が可能になる。  DBからは解析結果だけを出力すれば良い。  データは常にDBで一元管理されている。  SQLのフレキシブルなデータ操作命令により、 前処理/後処理ともDB内部で完結できる。  仮説検証とTRY&ERRORを効率化。 データの エクスポート Knowledge Knowledge 解析結果の出力 統計解析 アプリケーション データ処理 データ管理 データ管理 + データ処理 In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する Out-database Analytics In-database Analytics 4
  4. 4. The PG-Strom Project In-database Analyticsの課題 Algorithm 統計解析処理を行うための アルゴリズム、パッケージ Processor JOINやGROUP BY、Sortなど 計算中心のSQLワークロード Storage 巨大テーブルのScan (特にRAMサイズを越えるケース) Management データ収集、 データ形式、 意味のある データなのか? In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する5
  5. 5. The PG-Strom ProjectIn-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する6 SQLアクセラレータとしてのGPU
  6. 6. The PG-Strom Project PG-Strom SQLアクセラレータとしてのGPU Application GPU JOINや GROUP BYなど オフロード SQLから GPU命令を 自動生成 PG-Strom: GPUの持つ数百~数千コアと広帯域メモリを利用して、 SQLワークロードを高速化するPostgreSQL向け拡張モジュール SQLクエリ PostgreSQL データ構造 GPU CPU モデル NVIDIA Tesla P100 Intel Xeon E5-2699v4 世代 Pascal Broadwell 発表 Q2-2016 Q1-2016 トランジスタ数 15billion 7.2billion コア数 3584 (simple) 22 (functional) 動作クロック 1.126GHz ~1.303GHz 2.20GHz ~3.60GHz 理論性能値 (FP32) 9.3 TFLOPS 1.2 TFLOPS (with AVX2) RAMサイズ 16GB (HBM2) max1.5TB (DDR4) メモリ帯域 732GB/s 76.8GB/s 消費電力 250W 145W In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する7
  7. 7. The PG-Strom Project 中核機能 (1/2) – SQLからGPUバイナリを動的生成 In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する8 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
  8. 8. The PG-Strom Project 中核機能 (2/2) – 透過的なGPUアクセラレーション ▌コンセプト  共通のSQL構文  SQL構文や関数・演算子などは 全くPostgreSQLと同一で、 アプリケーションの改修が不要  共通のデータ構造  PostgreSQLのデータ構造をそのまま 用いており、データ移行や変換は不要  PostgreSQLのレコードは、必ずしも GPUにとってベストなデータ形式では ない。利便性とのトレードオフ。 ▌Custom-Scan Interface  拡張モジュールが、クエリ実行計画の 一部を独自実装するための 共通インターフェース。  PG-Stromを実装するため、 開発者コミュニティで標準化された。 Query Optimizer Query Executor PG-Strom Extension Storage Manager SQL Parser Application Storage 共通のSQL構文 共通のデータ形式 Custom-Scan Interface In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する9
  9. 9. The PG-Strom Project GPUによるSQL実行高速化の一例 In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する10 ▌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 (similar to star schema) 40.44 62.79 79.82 100.50 119.51 144.55 201.12 248.95 9.96 9.93 9.96 9.99 10.02 10.03 9.98 10.00 0 50 100 150 200 250 300 2 3 4 5 6 7 8 9 QueryResponseTime[sec] Number of joined tables PG-Strom microbenchmark with JOIN/GROUP BY PostgreSQL v9.5 PG-Strom v1.0 CPU: Xeon E5-2670v3 GPU: GTX1080 RAM: 384GB OS: CentOS 7.2 DB: PostgreSQL 9.5 + PG-Strom v1.0
  10. 10. The PG-Strom Project しかし、I/Oは鬼門だった。 Magnetic Drives RAM CPU GPU 16GB/s (PCIeバス) 72GB/s (メモリバス) ~1GB/s (SAS disks) ~3500コア~20コア I/Oマターになった瞬間、 こっちの差はどうでもよくなる。 In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する11
  11. 11. The PG-Strom Project ワークアラウンド – 全てのデータをオンメモリに Magnetic Drives RAM CPU GPU 16GB/s (PCIeバス) 72GB/s (メモリバス) pg_prewarm (事前のロード) ~3500コア~20コア 全てのデータをオンメモリ化し、 RAM  CPU/GPUに閉じた 処理にする。 データサイズの上限を RAMサイズが決める。 “Small Big-Data” Solution :-) In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する12
  12. 12. The PG-Strom Project SSD-to-GPU P2P DMAへ In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する13
  13. 13. The PG-Strom Project 要素技術① NVMe-SSD (1/2)  標準化されたコマンドセット  広帯域(数GB/s)  低遅延(数十万IOPS)  マルチコアCPU向けI/Oサブシステム PCIe SSD コントローラ NAND Flash NVMeコマンド データブロック In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する14
  14. 14. The PG-Strom Project 要素技術① NVMe-SSD (2/2) In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する15 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規格に対応した製品が各社からリリースされている
  15. 15. The PG-Strom Project 要素技術② GPUDirect RDMA (1/2) ▌CPU/RAMを仲介する事なく、GPU他のデバイス間でデータ転送を行う機能  元々は、マルチノード環境でInfinibandを介したGPU間のデータ転送効率化技術  Linux kernel moduleを作成する事で、他のPCIeデバイスにも対応可能 Copyright (c) NVIDIA corporation, 2015 In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する16
  16. 16. The PG-Strom Project 要素技術② GPUDirect RDMA (2/2) 物理アドレス空間 PCIe BAR1領域GPU RAM RAM NVMe-SSD Infiniband HBA PCIe デバイス GPUDirect RDMA GPUデバイスメモリを 物理アドレス空間にマップする機能 “GPUデバイスメモリの物理アドレス”が あれば、PCIeデバイスとのDMAで Source/Destinationアドレスとして 指定できる。 In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する17
  17. 17. The PG-Strom Project NVMe-SSD + GPUDirect RDMA + PG-Strom = Intelligent Storage In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する18  GPU上でのSQLワークロードの処理機構(PG-Strom)と、 SSDからGPUへのダイレクトデータ転送機構(NVMe-Strom)を組み合わせ。  CPUが処理すべきデータ量を削減し、結果としてI/Oワークロードの処理スループットを引き上げる。 NVMe-SSDからGPUへPCIeバスを介してデータブロックを直接転送。 CPU/RAMへのロード前に不要データを削減し、I/Oスループットを引き上げる。 Large PostgreSQL Tables PCIe Bus NVMe SSD GPUSSD-to-GPU P2P DMA (NVMe-Stromドライバ) WHERE句 JOIN GROUP BY PostgreSQLデータブロック ロードすべき データ量の削減 SSDとGPUの組合せによって、 あたかもストレージがSQLを理解し、 予め不要なデータを削除している かのように振る舞う。
  18. 18. The PG-Strom Project NVMe-Strom ソフトウェアスタック In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する19 pg-strom NVMe-Strom VFS Page Cache NVMe SSD Driver nvidia driver GPU device memory GPU device memory PostgreSQL file offset DMA request block number SSD-to-GPU Peer-to-Peer DMA cuMemAlloc() /proc/nvme-strom ioctl(2) read(2) User Space Kernel Space
  19. 19. The PG-Strom Project ディスクキャッシュとの一貫性 In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する20  課題 ①対象ブロックがOSキャッシュに保持されている場合、ストレージブロックの内容は 最新でない可能性がある。 ②8KB単位のコマ切れDMAは非常に性能が悪い  対策 キャッシュされているブロック(=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
  20. 20. The PG-Strom Project ベンチマーク (1/3) – 測定環境 In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する21 CPU2CPU1 SSD x2 Tesla K80 GPU Tesla K20 GPU (未使用) ▌サーバスペック/SW構成  Model: DELL PowerEdge R730  CPU: Xeon E5-2670v3 (12C, 2.3GHz) x2  RAM: 384GB (うち128GBのみ使用)  HDD: SAS 300GB x8 (RAID5)  OS: CentOS7.2 (3.10.0-327.el7)  SW: CUDA 7.5.17 NVIDIA driver 352.99 PostgreSQL 9.6.1 PG-Strom v2.0devel ▌GPUスペック  NVIDIA Tesla K80  2x 2496 CUDA cores (560MHz)  2x 12GB GDDR5 RAM (240GB/s) ▌SSDスペック  Intel SSD 750 (400GB) x2  Interface: PCIe 3.0 x4 (NVMe 1.2)  Max SeqRead: 2.2GB/s
  21. 21. The PG-Strom Project ベンチマーク (2/3) – Star Schema Benchmark In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する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) Scan (WHERE句)、JOIN、GROUP BYから成る典型的な 集計クエリを実行。 lineorderテーブルのサイズが 物理RAMサイズを越えるため、 ワークロードはI/O中心になる。
  22. 22. The PG-Strom Project ベンチマーク (3/3) – データ集計SQL/処理スループット 0 500 1000 1500 2000 2500 3000 3500 4000 4500 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 クエリ処理スループット[MB/s] PostgreSQL SSDx1 PostgreSQL SSDx2 PG-Strom SSDx1 PG-Strom SSDx2  DBサイズ353GBに対し、WHERE句、JOIN、集約/GROUP BY処理を実行。I/Oが支配的なワークロード。  SSD2枚のケース:PostgreSQLは1.6GB/s程度で頭打ちだが、PG-Stromは現状でも3.8GB/sの処理能力を達成。 SSDドライバやSQL実装の改善で、処理スループットの理論限界値 (SSD2枚で 4.4GB/s)を目指す。  HW) CPU: Xeon E5-2670v3, GPU: NVIDIA Tesla K80, RAM: 128GB, SSD: Intel SSD 750(400GB) x2  SW) OS: CentOS7, CUDA7.5, PostgreSQL 9.6.1, PG-Strom 2.0devel SSD x1枚構成の 理論限界値 [2.2GB/s] SSD x2枚構成の 理論限界値 [4.4GB/s] 調査中 In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する23
  23. 23. The PG-Strom Project 従来機能の拡張 (1/3) – GpuJoin In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する24 Inner relation Outer relation Inner relation Outer relation Hash table Hash table Next Step Next Step CPU側は 結果行を参照 するだけ。 CPUによる ハッシュ表探索 CPUによる 結果行生成 GPUによる 結果行生成 GPUによる 並列Hash表探索 HashJoin by CPU GpuHashJoin SSD-to-GPU P2P DMAを 適用 UPDATE
  24. 24. The PG-Strom Project GpuPreAgg 従来機能の拡張 (2/3) – GpuPreAgg In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する25 Aggregation by CPU Aggregation with GPU Relation Relation Aggregation Aggregation 1st Step: Parallel Hash Reduction 2nd Step: Atomic Merge 100万行 の読出し CPUで100 万行を処 理 より少な い行数 GpuPreAgg: CPUで処理すべき行数を削減 中間結果 SSD-to-GPU P2P DMAを適用 UPDATE
  25. 25. The PG-Strom Project 従来機能の拡張 (3/3) – EXPLAINで確認 nvme=# EXPLAIN SELECT sum(lo_extendedprice*lo_discount) as revenue FROM lineorder,date1 WHERE lo_orderdate = d_datekey AND d_year = 1993 AND lo_discount BETWEEN 1 AND 3 AND lo_quantity < 25; QUERY PLAN ---------------------------------------------------------------------------------------------------- Aggregate (cost=32629401.85..32629401.86 rows=1 width=32) -> Custom Scan (GpuPreAgg) (cost=32629397.25..32629400.31 rows=204 width=32) Reduction: NoGroup GPU Projection: pgstrom.psum((lo_extendedprice * lo_discount)) Features: outer-bulk-exec, output-slot-format -> Custom Scan (GpuJoin) on lineorder (cost=6569.11..32597251.98 rows=45032443 width=10) GPU Projection: lineorder.lo_extendedprice, lineorder.lo_discount Outer Scan: lineorder (cost=6715.83..35072613.81 rows=315350477 width=14) Outer Scan Filter: ((lo_discount >= '1'::numeric) AND (lo_discount <= '3'::numeric) AND (lo_quantity < '25'::numeric)) Depth 1: GpuHashJoin (nrows 315350477...45032443) HashKeys: lineorder.lo_orderdate JoinQuals: (lineorder.lo_orderdate = date1.d_datekey) KDS-Hash (size: 0B, nbatched: 1) Features: output-row-format, nvme-strom -> Seq Scan on date1 (cost=0.00..78.95 rows=365 width=4) Filter: (d_year = 1993) (16 rows) In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する26 UPDATE
  26. 26. The PG-Strom Project PG-Strom v2.0 開発状況 In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する27 •GPUデバイスメモリのホストマッピングと、SSD-to-GPU P2P DMA要求の発行 ① NVMe-Strom: 基本機能の実証 •PostgreSQL v9.6のCPU並列 (Partial Scan) 対応 •GpuScanへのNVMe-Stromモードの追加 ② PG-Strom: GpuScan + NVMe-Stromの統合 •PostgreSQL v9.6の新オプティマイザへの対応 •GpuJoin/GpuPreAggの直接スキャンモードでのNVMe-Stromの使用 ③ PG-Strom: JOIN/GROUP BY対応 •ソフトウェアRAID-0区画に対するストライピングREAD機能のサポート ④ NVMe-Strom: MD RAID-0対応 •テスト、テスト、デバッグ、改善、、、 ⑤ 品質改善・安定化 / Quality improvement and stabilization ⑥ PG-Strom v2.0!! (2017/2Q~3Q) 現在のステータス
  27. 27. The PG-Strom Project 【関連機能】 BRINインデックス対応 In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する28 ▌BRIN ... Block Range Index  一定範囲のブロック(8KB x 128個)における、対象列の最大値/最小値を記録するインデックス  検索条件にマッチしない事が明らかなブロックを読み飛ばす事ができる。  インデックスサイズが小さく、時系列データの格納に適したインデックス。  RAM/SSD~GPU間のデータ転送量を削減する事ができる。 時系列データ データの発生した時刻順にレコードがINSERTされるため、 タイムスタンプが近いレコードは、物理的に近しい位置に 格納されるという特徴を持つ。 BRIN インデックス 条件句: WHERE ymd BETWEEN ‘2016-01-01’ AND ‘2016-12-31’ False True True True False min: ‘2015-01-01’ max: ‘2015-09-30’ min: ‘2015-10-01’ max: ‘2016-03-15’ min: ‘2016-03-15’ max: ‘2016-07-31’ min: ‘2016-08-01’ max: ‘2017-02-01’ min: ‘2017-02-01’ max: ‘2017-05-15’ 必要最小限のデータだけをGPUに転送 タイムスタンプ+αの条件句を並列に評価する。 v2.0
  28. 28. The PG-Strom Project 【関連機能】 CPU+GPUハイブリッド並列 In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する29 ▌PostgreSQL v9.6以降で対応したパラレルクエリの応用  各ワーカープロセスがそれぞれにGPUを使用する。 ▌GPUへのデータ供給レートの向上と、結果的にマルチGPUへの対応も可能に。 Parallel SeqScan GpuPreAgg Gather Background Worker Parallel SeqScan GpuPreAgg Parallel SeqScan GpuPreAgg Finalize Aggregate テーブル 中間集計 中間集計 中間集計 最終結果 GPUによるGROUP BY、 集約演算の実行 ~1億行 ~100行 v2.0
  29. 29. The PG-Strom Project 目指すべきソリューション (1/3) In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する34 PCIe x8 接続SSD x2 NVIDIA Tesla P40 CPU RAM DMI SSD-1 SSD-2 GPU 1Uラックサーバあたり max 10GB/sec のデータ処理能力を目指す PCI-E ハードウェアブロック図 ソフトウェアスタック Red Hat Enterprise Linux 7.3, CentOS 7.3, Ubuntu 16.04 NVMe-Strom CUDA 8.0 PostgreSQL v9.6 PG-Strom 2.0 ユーザアプリケーション 標準SQLインターフェース
  30. 30. The PG-Strom Project 目指すべきソリューション (2/3) In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する35 PCIe x16 接続SSD x5 NVIDIA Tesla P40 x5 ハードウェアブロック図 DMI GPU-1 PCI-SW PCI-SW QPIx2 GPU-2 GPU-4 GPU-5 SSD-1 SSD-2 SSD-3 SSD-4 SSD-5 GPU-3 RAM RAM CPU 1 CPU 2 PCIe x16 x2 slot PCIe 96lane PCIe 96lane DWH専用機とも対抗可能なデータ処理能力?
  31. 31. The PG-Strom Project 目指すべきソリューション (3/3) In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する36 PCIe x8 接続SSD x2 NVIDIA Tesla P40 PostgreSQLのスケールアウト型ソリューションとの組合せ?
  32. 32. The PG-Strom Project まとめ ▌In-database Analytics (技術的な) 課題  アルゴリズム  プロセッサ  ストレージ  本日のトピック ▌NVMe-Stom  コンセプト: GPUでのSQL処理とGPUDirect RDMA機能の組合せにより、 ストレージブロックをCPU/RAMへロードするより前にデータ量を削減する。 CPUが捌かねばならないデータ量/レコード数を減らす。  プロトタイプ性能値: NVMe-SSD (SeqRead 2.2GB/s) x2台のmd-raid0構成で、 既にクエリ処理スループット3.8GB/sまで達成。 当面の目標は、単体ノード10GB/s級スループットの実現  対応ワークロード: WHERE句、JOIN、集約関数/GROUP BY In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する37
  33. 33. The PG-Strom Project Resources ▌Repository  https://github.com/pg-strom/devel  https://github.com/pg-strom/nvme-strom ▌Documentation  http://strom.kaigai.gr.jp/manual.html ▌Ask me  Tw: @kkaigai  E-mail: kaigai@kaigai.gr.jp In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する38
  34. 34. Questions?

×