SlideShare una empresa de Scribd logo
1 de 49
Descargar para leer sin conexión
GPGPUがPostgreSQLを加速する ~“超”メニーコアによる検索高速化~ 
NEC OSS推進センター 
The PG-Strom Project 
海外 浩平 <kaigai@ak.jp.nec.com> 
(Tw: @kkaigai)
自己紹介 
▌名前: 海外 浩平 
▌所属: 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
処理性能向上のアプローチ 
Page. 3 DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL 
スケールアウト 
スケールアップ 
ホモジニアス・スケールアップ 
ヘテロジニアス・スケールアップ 
+
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)
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支援によるコア間の同期機構
半導体技術のトレンド (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
半導体技術のトレンド (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
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 
データ
現代のメモリボトルネックの世界 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
PG-Stromのアプローチ 
▌PG-Stromとは 
PostgreSQL用の拡張モジュール 
SQL処理ワークロードの一部をGPUで並列実行し、高速化を実現。 
Full-Scan、Hash-Join、Aggregate の3種類のワークロードに対応 
(2014年11月時点のβ版での対応状況) 
▌コンセプト 
SQL構文からGPU用のネイティブ命令を動的に生成。JITコンパイル。 
CPU/GPU協調による非同期並列実行 
▌利点 
利用者からは完全に透過的に動作。 
•SQL構文や周辺ツール、ドライバを含めPostgreSQL向けのソフトウェア資産を利用可 
GPU+OSSの組み合わせにより、低コストでの性能改善が計れる。 
▌注意点 
ただし、現時点ではインメモリ・データストアが前提。 
DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL 
Page. 10
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
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
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実装
ベンチマーク (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
ベンチマーク (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
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月 β版を公開
着想 – 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
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並列処理が効くのでは?
実際に作ってみた – 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
 元々は外部データソースを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
当時の実装 
▌問題点 
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” を持たせる。 各要素は長大配列として、物理的に近傍の位置に配置
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 
この部分の 仕様を拡張
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
設計転換 
▌はたして 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環境に対応できない 
•ドライバの実績・安定性
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実行ロジックを、標 
準のものと同列に並べて 
取捨選択を行う。
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
(参考) Custom Plan Interface, ready for v9.5 
DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL 
Page. 27 
まず、コンセンサスである Scan部分のカスタムロジックを 拡張モジュールで実装できるよう インターフェースを定義。 ↓ 次にJoinのカスタムロジックを 開発者コミュニティで議論
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 
キャッシュ構築 (行列変換) 
処理結果返却 (列行変換)
なぜ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個単位である事が多い。
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は 無い場合も多い
列指向キャッシュの悪夢 (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
列指向キャッシュの悪夢 (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との インターフェース部分) で無視できない処理コストが発生している。
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の特性に従って 最適化されたコード。 
列指向データの利用時
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のタスク 行データに対して演算処理を実行。 最適なデータ構造ではないが、 コアの数で処理速度をカバー 
行指向データの利用時 
独自の キャッシュは 持たない
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 <-- 応答性能は大幅改善 
やや、性能劣化
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
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にデータを供給するのは厳しい
想定利用シーン (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 
性能のカギ 
•マスタ&ファクト テーブルの結合 
•グループ化& 集約演算
想定利用シーン (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 
単体ノードの 性能向上により、 必要なノード数を 削減する
想定利用シーン (3/3) – 我々と一緒に考えませんか? 
▌どういった領域に適用可能だろうか? 
▌どういった用途で使えるだろうか? 
▌どういったワークロードに困っているだろうか? 
PG-Stromプロジェクトはフィールドから学びたいと考えています 
DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL 
Page. 40
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 の有効/無効を切り替える
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
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日現在の東京リージョン オンデマンドインスタンス価格
PG-Stromの今後 
DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL 
Page. 44
イノベーションのジレンマ 
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
コミュニティと共に進む 
DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL 
Page. 46
(発表後の補足) 
DB Tech Showcase 2014 Tokyo; PG-Strom - GPGPU acceleration on PostgreSQL 
Page. 47 
check it out! https://github.com/pg-strom/devel
(JP) GPGPUがPostgreSQLを加速する
(JP) GPGPUがPostgreSQLを加速する

Más contenido relacionado

La actualidad más candente

PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイント
PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイントPostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイント
PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイントNTT DATA OSS Professional Services
 
MySQLとPostgreSQLの基本的な実行プラン比較
MySQLとPostgreSQLの基本的な実行プラン比較MySQLとPostgreSQLの基本的な実行プラン比較
MySQLとPostgreSQLの基本的な実行プラン比較Shinya Sugiyama
 
SQL大量発行処理をいかにして高速化するか
SQL大量発行処理をいかにして高速化するかSQL大量発行処理をいかにして高速化するか
SQL大量発行処理をいかにして高速化するかShogo Wakayama
 
Jdk9で変更になる(かも知れない)jvmオプションの標準設定
Jdk9で変更になる(かも知れない)jvmオプションの標準設定Jdk9で変更になる(かも知れない)jvmオプションの標準設定
Jdk9で変更になる(かも知れない)jvmオプションの標準設定Kazuyuki Nakamura
 
今秋リリース予定のPostgreSQL11を徹底解説
今秋リリース予定のPostgreSQL11を徹底解説今秋リリース予定のPostgreSQL11を徹底解説
今秋リリース予定のPostgreSQL11を徹底解説Masahiko Sawada
 
高速にコンテナを起動できるイメージフォーマット
高速にコンテナを起動できるイメージフォーマット高速にコンテナを起動できるイメージフォーマット
高速にコンテナを起動できるイメージフォーマットAkihiro Suda
 
いまさら聞けない!CUDA高速化入門
いまさら聞けない!CUDA高速化入門いまさら聞けない!CUDA高速化入門
いまさら聞けない!CUDA高速化入門Fixstars Corporation
 
大規模並列実験を支えるクラウドサービスと基盤技術
大規模並列実験を支えるクラウドサービスと基盤技術大規模並列実験を支えるクラウドサービスと基盤技術
大規模並列実験を支えるクラウドサービスと基盤技術RyuichiKanoh
 
Oracle Databaseを用いて学ぶ RDBMSの基本 (抜粋版) - JPOUG Oracle Database入学式 2016
Oracle Databaseを用いて学ぶRDBMSの基本 (抜粋版) - JPOUG Oracle Database入学式 2016 Oracle Databaseを用いて学ぶRDBMSの基本 (抜粋版) - JPOUG Oracle Database入学式 2016
Oracle Databaseを用いて学ぶ RDBMSの基本 (抜粋版) - JPOUG Oracle Database入学式 2016 Ryota Watabe
 
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意イミュータブルデータモデルの極意
イミュータブルデータモデルの極意Yoshitaka Kawashima
 
冬のLock free祭り safe
冬のLock free祭り safe冬のLock free祭り safe
冬のLock free祭り safeKumazaki Hiroki
 
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキーWhere狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキーyoku0825
 
トランザクションの設計と進化
トランザクションの設計と進化トランザクションの設計と進化
トランザクションの設計と進化Kumazaki Hiroki
 
PostgreSQL運用管理入門
PostgreSQL運用管理入門PostgreSQL運用管理入門
PostgreSQL運用管理入門Yoshiyuki Asaba
 
最近のストリーム処理事情振り返り
最近のストリーム処理事情振り返り最近のストリーム処理事情振り返り
最近のストリーム処理事情振り返りSotaro Kimura
 
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報Masahiko Sawada
 
WebAssemblyのWeb以外のことぜんぶ話す
WebAssemblyのWeb以外のことぜんぶ話すWebAssemblyのWeb以外のことぜんぶ話す
WebAssemblyのWeb以外のことぜんぶ話すTakaya Saeki
 
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)NTT DATA Technology & Innovation
 

La actualidad más candente (20)

PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイント
PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイントPostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイント
PostgreSQL10を導入!大規模データ分析事例からみるDWHとしてのPostgreSQL活用のポイント
 
MySQLとPostgreSQLの基本的な実行プラン比較
MySQLとPostgreSQLの基本的な実行プラン比較MySQLとPostgreSQLの基本的な実行プラン比較
MySQLとPostgreSQLの基本的な実行プラン比較
 
Cache勉強会
Cache勉強会Cache勉強会
Cache勉強会
 
SQL大量発行処理をいかにして高速化するか
SQL大量発行処理をいかにして高速化するかSQL大量発行処理をいかにして高速化するか
SQL大量発行処理をいかにして高速化するか
 
Jdk9で変更になる(かも知れない)jvmオプションの標準設定
Jdk9で変更になる(かも知れない)jvmオプションの標準設定Jdk9で変更になる(かも知れない)jvmオプションの標準設定
Jdk9で変更になる(かも知れない)jvmオプションの標準設定
 
今秋リリース予定のPostgreSQL11を徹底解説
今秋リリース予定のPostgreSQL11を徹底解説今秋リリース予定のPostgreSQL11を徹底解説
今秋リリース予定のPostgreSQL11を徹底解説
 
高速にコンテナを起動できるイメージフォーマット
高速にコンテナを起動できるイメージフォーマット高速にコンテナを起動できるイメージフォーマット
高速にコンテナを起動できるイメージフォーマット
 
いまさら聞けない!CUDA高速化入門
いまさら聞けない!CUDA高速化入門いまさら聞けない!CUDA高速化入門
いまさら聞けない!CUDA高速化入門
 
大規模並列実験を支えるクラウドサービスと基盤技術
大規模並列実験を支えるクラウドサービスと基盤技術大規模並列実験を支えるクラウドサービスと基盤技術
大規模並列実験を支えるクラウドサービスと基盤技術
 
Oracle Databaseを用いて学ぶ RDBMSの基本 (抜粋版) - JPOUG Oracle Database入学式 2016
Oracle Databaseを用いて学ぶRDBMSの基本 (抜粋版) - JPOUG Oracle Database入学式 2016 Oracle Databaseを用いて学ぶRDBMSの基本 (抜粋版) - JPOUG Oracle Database入学式 2016
Oracle Databaseを用いて学ぶ RDBMSの基本 (抜粋版) - JPOUG Oracle Database入学式 2016
 
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
 
冬のLock free祭り safe
冬のLock free祭り safe冬のLock free祭り safe
冬のLock free祭り safe
 
Where狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキーWhere狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキー
 
Google Cloud Dataflow を理解する - #bq_sushi
Google Cloud Dataflow を理解する - #bq_sushiGoogle Cloud Dataflow を理解する - #bq_sushi
Google Cloud Dataflow を理解する - #bq_sushi
 
トランザクションの設計と進化
トランザクションの設計と進化トランザクションの設計と進化
トランザクションの設計と進化
 
PostgreSQL運用管理入門
PostgreSQL運用管理入門PostgreSQL運用管理入門
PostgreSQL運用管理入門
 
最近のストリーム処理事情振り返り
最近のストリーム処理事情振り返り最近のストリーム処理事情振り返り
最近のストリーム処理事情振り返り
 
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
 
WebAssemblyのWeb以外のことぜんぶ話す
WebAssemblyのWeb以外のことぜんぶ話すWebAssemblyのWeb以外のことぜんぶ話す
WebAssemblyのWeb以外のことぜんぶ話す
 
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)
 

Similar a (JP) GPGPUがPostgreSQLを加速する

PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database AnalyticsPL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database AnalyticsKohei KaiGai
 
SQL+GPU+SSD=∞ (Japanese)
SQL+GPU+SSD=∞ (Japanese)SQL+GPU+SSD=∞ (Japanese)
SQL+GPU+SSD=∞ (Japanese)Kohei KaiGai
 
pgconfasia2016 lt ssd2gpu
pgconfasia2016 lt ssd2gpupgconfasia2016 lt ssd2gpu
pgconfasia2016 lt ssd2gpuKohei KaiGai
 
20221116_DBTS_PGStrom_History
20221116_DBTS_PGStrom_History20221116_DBTS_PGStrom_History
20221116_DBTS_PGStrom_HistoryKohei KaiGai
 
20191211_Apache_Arrow_Meetup_Tokyo
20191211_Apache_Arrow_Meetup_Tokyo20191211_Apache_Arrow_Meetup_Tokyo
20191211_Apache_Arrow_Meetup_TokyoKohei KaiGai
 
20210511_PGStrom_GpuCache
20210511_PGStrom_GpuCache20210511_PGStrom_GpuCache
20210511_PGStrom_GpuCacheKohei KaiGai
 
20171220_hbstudy80_pgstrom
20171220_hbstudy80_pgstrom20171220_hbstudy80_pgstrom
20171220_hbstudy80_pgstromKohei KaiGai
 
20180217 FPGA Extreme Computing #10
20180217 FPGA Extreme Computing #1020180217 FPGA Extreme Computing #10
20180217 FPGA Extreme Computing #10Kohei KaiGai
 
20170421 tensor flowusergroup
20170421 tensor flowusergroup20170421 tensor flowusergroup
20170421 tensor flowusergroupManaMurakami1
 
20181212 - PGconf.ASIA - LT
20181212 - PGconf.ASIA - LT20181212 - PGconf.ASIA - LT
20181212 - PGconf.ASIA - LTKohei KaiGai
 
20180920_DBTS_PGStrom_JP
20180920_DBTS_PGStrom_JP20180920_DBTS_PGStrom_JP
20180920_DBTS_PGStrom_JPKohei KaiGai
 
高速ネットワーク最新動向と具体例 (ENOG58 Meeting)
高速ネットワーク最新動向と具体例 (ENOG58 Meeting)高速ネットワーク最新動向と具体例 (ENOG58 Meeting)
高速ネットワーク最新動向と具体例 (ENOG58 Meeting)Naoto MATSUMOTO
 
20201113_PGconf_Japan_GPU_PostGIS
20201113_PGconf_Japan_GPU_PostGIS20201113_PGconf_Japan_GPU_PostGIS
20201113_PGconf_Japan_GPU_PostGISKohei KaiGai
 
GPU-FPGA協調プログラミングを実現するコンパイラの開発
GPU-FPGA協調プログラミングを実現するコンパイラの開発GPU-FPGA協調プログラミングを実現するコンパイラの開発
GPU-FPGA協調プログラミングを実現するコンパイラの開発Ryuuta Tsunashima
 
20190925_DBTS_PGStrom
20190925_DBTS_PGStrom20190925_DBTS_PGStrom
20190925_DBTS_PGStromKohei KaiGai
 
45分で理解する 最近のスパコン事情 斉藤之雄
45分で理解する 最近のスパコン事情 斉藤之雄45分で理解する 最近のスパコン事情 斉藤之雄
45分で理解する 最近のスパコン事情 斉藤之雄Yukio Saito
 
20210731_OSC_Kyoto_PGStrom3.0
20210731_OSC_Kyoto_PGStrom3.020210731_OSC_Kyoto_PGStrom3.0
20210731_OSC_Kyoto_PGStrom3.0Kohei KaiGai
 
200625material naruse
200625material naruse200625material naruse
200625material naruseRCCSRENKEI
 
20170329_BigData基盤研究会#7
20170329_BigData基盤研究会#720170329_BigData基盤研究会#7
20170329_BigData基盤研究会#7Kohei KaiGai
 

Similar a (JP) GPGPUがPostgreSQLを加速する (20)

PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database AnalyticsPL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
 
SQL+GPU+SSD=∞ (Japanese)
SQL+GPU+SSD=∞ (Japanese)SQL+GPU+SSD=∞ (Japanese)
SQL+GPU+SSD=∞ (Japanese)
 
pgconfasia2016 lt ssd2gpu
pgconfasia2016 lt ssd2gpupgconfasia2016 lt ssd2gpu
pgconfasia2016 lt ssd2gpu
 
20221116_DBTS_PGStrom_History
20221116_DBTS_PGStrom_History20221116_DBTS_PGStrom_History
20221116_DBTS_PGStrom_History
 
20191211_Apache_Arrow_Meetup_Tokyo
20191211_Apache_Arrow_Meetup_Tokyo20191211_Apache_Arrow_Meetup_Tokyo
20191211_Apache_Arrow_Meetup_Tokyo
 
20210511_PGStrom_GpuCache
20210511_PGStrom_GpuCache20210511_PGStrom_GpuCache
20210511_PGStrom_GpuCache
 
20171220_hbstudy80_pgstrom
20171220_hbstudy80_pgstrom20171220_hbstudy80_pgstrom
20171220_hbstudy80_pgstrom
 
20180217 FPGA Extreme Computing #10
20180217 FPGA Extreme Computing #1020180217 FPGA Extreme Computing #10
20180217 FPGA Extreme Computing #10
 
20170421 tensor flowusergroup
20170421 tensor flowusergroup20170421 tensor flowusergroup
20170421 tensor flowusergroup
 
20181212 - PGconf.ASIA - LT
20181212 - PGconf.ASIA - LT20181212 - PGconf.ASIA - LT
20181212 - PGconf.ASIA - LT
 
20180920_DBTS_PGStrom_JP
20180920_DBTS_PGStrom_JP20180920_DBTS_PGStrom_JP
20180920_DBTS_PGStrom_JP
 
高速ネットワーク最新動向と具体例 (ENOG58 Meeting)
高速ネットワーク最新動向と具体例 (ENOG58 Meeting)高速ネットワーク最新動向と具体例 (ENOG58 Meeting)
高速ネットワーク最新動向と具体例 (ENOG58 Meeting)
 
20201113_PGconf_Japan_GPU_PostGIS
20201113_PGconf_Japan_GPU_PostGIS20201113_PGconf_Japan_GPU_PostGIS
20201113_PGconf_Japan_GPU_PostGIS
 
GPU-FPGA協調プログラミングを実現するコンパイラの開発
GPU-FPGA協調プログラミングを実現するコンパイラの開発GPU-FPGA協調プログラミングを実現するコンパイラの開発
GPU-FPGA協調プログラミングを実現するコンパイラの開発
 
20190925_DBTS_PGStrom
20190925_DBTS_PGStrom20190925_DBTS_PGStrom
20190925_DBTS_PGStrom
 
45分で理解する 最近のスパコン事情 斉藤之雄
45分で理解する 最近のスパコン事情 斉藤之雄45分で理解する 最近のスパコン事情 斉藤之雄
45分で理解する 最近のスパコン事情 斉藤之雄
 
20210731_OSC_Kyoto_PGStrom3.0
20210731_OSC_Kyoto_PGStrom3.020210731_OSC_Kyoto_PGStrom3.0
20210731_OSC_Kyoto_PGStrom3.0
 
200625material naruse
200625material naruse200625material naruse
200625material naruse
 
20170329_BigData基盤研究会#7
20170329_BigData基盤研究会#720170329_BigData基盤研究会#7
20170329_BigData基盤研究会#7
 
ICD/CPSY 201412
ICD/CPSY 201412ICD/CPSY 201412
ICD/CPSY 201412
 

Más de Kohei KaiGai

20221111_JPUG_CustomScan_API
20221111_JPUG_CustomScan_API20221111_JPUG_CustomScan_API
20221111_JPUG_CustomScan_APIKohei KaiGai
 
20211112_jpugcon_gpu_and_arrow
20211112_jpugcon_gpu_and_arrow20211112_jpugcon_gpu_and_arrow
20211112_jpugcon_gpu_and_arrowKohei KaiGai
 
20210928_pgunconf_hll_count
20210928_pgunconf_hll_count20210928_pgunconf_hll_count
20210928_pgunconf_hll_countKohei KaiGai
 
20210301_PGconf_Online_GPU_PostGIS_GiST_Index
20210301_PGconf_Online_GPU_PostGIS_GiST_Index20210301_PGconf_Online_GPU_PostGIS_GiST_Index
20210301_PGconf_Online_GPU_PostGIS_GiST_IndexKohei KaiGai
 
20201128_OSC_Fukuoka_Online_GPUPostGIS
20201128_OSC_Fukuoka_Online_GPUPostGIS20201128_OSC_Fukuoka_Online_GPUPostGIS
20201128_OSC_Fukuoka_Online_GPUPostGISKohei KaiGai
 
20201006_PGconf_Online_Large_Data_Processing
20201006_PGconf_Online_Large_Data_Processing20201006_PGconf_Online_Large_Data_Processing
20201006_PGconf_Online_Large_Data_ProcessingKohei KaiGai
 
20200828_OSCKyoto_Online
20200828_OSCKyoto_Online20200828_OSCKyoto_Online
20200828_OSCKyoto_OnlineKohei KaiGai
 
20200806_PGStrom_PostGIS_GstoreFdw
20200806_PGStrom_PostGIS_GstoreFdw20200806_PGStrom_PostGIS_GstoreFdw
20200806_PGStrom_PostGIS_GstoreFdwKohei KaiGai
 
20200424_Writable_Arrow_Fdw
20200424_Writable_Arrow_Fdw20200424_Writable_Arrow_Fdw
20200424_Writable_Arrow_FdwKohei KaiGai
 
20191115-PGconf.Japan
20191115-PGconf.Japan20191115-PGconf.Japan
20191115-PGconf.JapanKohei KaiGai
 
20190926_Try_RHEL8_NVMEoF_Beta
20190926_Try_RHEL8_NVMEoF_Beta20190926_Try_RHEL8_NVMEoF_Beta
20190926_Try_RHEL8_NVMEoF_BetaKohei KaiGai
 
20190909_PGconf.ASIA_KaiGai
20190909_PGconf.ASIA_KaiGai20190909_PGconf.ASIA_KaiGai
20190909_PGconf.ASIA_KaiGaiKohei KaiGai
 
20190516_DLC10_PGStrom
20190516_DLC10_PGStrom20190516_DLC10_PGStrom
20190516_DLC10_PGStromKohei KaiGai
 
20190418_PGStrom_on_ArrowFdw
20190418_PGStrom_on_ArrowFdw20190418_PGStrom_on_ArrowFdw
20190418_PGStrom_on_ArrowFdwKohei KaiGai
 
20190314 PGStrom Arrow_Fdw
20190314 PGStrom Arrow_Fdw20190314 PGStrom Arrow_Fdw
20190314 PGStrom Arrow_FdwKohei KaiGai
 
20181212 - PGconfASIA - LT - English
20181212 - PGconfASIA - LT - English20181212 - PGconfASIA - LT - English
20181212 - PGconfASIA - LT - EnglishKohei KaiGai
 
20181211 - PGconf.ASIA - NVMESSD&GPU for BigData
20181211 - PGconf.ASIA - NVMESSD&GPU for BigData20181211 - PGconf.ASIA - NVMESSD&GPU for BigData
20181211 - PGconf.ASIA - NVMESSD&GPU for BigDataKohei KaiGai
 
20181210 - PGconf.ASIA Unconference
20181210 - PGconf.ASIA Unconference20181210 - PGconf.ASIA Unconference
20181210 - PGconf.ASIA UnconferenceKohei KaiGai
 
20181116 Massive Log Processing using I/O optimized PostgreSQL
20181116 Massive Log Processing using I/O optimized PostgreSQL20181116 Massive Log Processing using I/O optimized PostgreSQL
20181116 Massive Log Processing using I/O optimized PostgreSQLKohei KaiGai
 
20181016_pgconfeu_ssd2gpu_multi
20181016_pgconfeu_ssd2gpu_multi20181016_pgconfeu_ssd2gpu_multi
20181016_pgconfeu_ssd2gpu_multiKohei KaiGai
 

Más de Kohei KaiGai (20)

20221111_JPUG_CustomScan_API
20221111_JPUG_CustomScan_API20221111_JPUG_CustomScan_API
20221111_JPUG_CustomScan_API
 
20211112_jpugcon_gpu_and_arrow
20211112_jpugcon_gpu_and_arrow20211112_jpugcon_gpu_and_arrow
20211112_jpugcon_gpu_and_arrow
 
20210928_pgunconf_hll_count
20210928_pgunconf_hll_count20210928_pgunconf_hll_count
20210928_pgunconf_hll_count
 
20210301_PGconf_Online_GPU_PostGIS_GiST_Index
20210301_PGconf_Online_GPU_PostGIS_GiST_Index20210301_PGconf_Online_GPU_PostGIS_GiST_Index
20210301_PGconf_Online_GPU_PostGIS_GiST_Index
 
20201128_OSC_Fukuoka_Online_GPUPostGIS
20201128_OSC_Fukuoka_Online_GPUPostGIS20201128_OSC_Fukuoka_Online_GPUPostGIS
20201128_OSC_Fukuoka_Online_GPUPostGIS
 
20201006_PGconf_Online_Large_Data_Processing
20201006_PGconf_Online_Large_Data_Processing20201006_PGconf_Online_Large_Data_Processing
20201006_PGconf_Online_Large_Data_Processing
 
20200828_OSCKyoto_Online
20200828_OSCKyoto_Online20200828_OSCKyoto_Online
20200828_OSCKyoto_Online
 
20200806_PGStrom_PostGIS_GstoreFdw
20200806_PGStrom_PostGIS_GstoreFdw20200806_PGStrom_PostGIS_GstoreFdw
20200806_PGStrom_PostGIS_GstoreFdw
 
20200424_Writable_Arrow_Fdw
20200424_Writable_Arrow_Fdw20200424_Writable_Arrow_Fdw
20200424_Writable_Arrow_Fdw
 
20191115-PGconf.Japan
20191115-PGconf.Japan20191115-PGconf.Japan
20191115-PGconf.Japan
 
20190926_Try_RHEL8_NVMEoF_Beta
20190926_Try_RHEL8_NVMEoF_Beta20190926_Try_RHEL8_NVMEoF_Beta
20190926_Try_RHEL8_NVMEoF_Beta
 
20190909_PGconf.ASIA_KaiGai
20190909_PGconf.ASIA_KaiGai20190909_PGconf.ASIA_KaiGai
20190909_PGconf.ASIA_KaiGai
 
20190516_DLC10_PGStrom
20190516_DLC10_PGStrom20190516_DLC10_PGStrom
20190516_DLC10_PGStrom
 
20190418_PGStrom_on_ArrowFdw
20190418_PGStrom_on_ArrowFdw20190418_PGStrom_on_ArrowFdw
20190418_PGStrom_on_ArrowFdw
 
20190314 PGStrom Arrow_Fdw
20190314 PGStrom Arrow_Fdw20190314 PGStrom Arrow_Fdw
20190314 PGStrom Arrow_Fdw
 
20181212 - PGconfASIA - LT - English
20181212 - PGconfASIA - LT - English20181212 - PGconfASIA - LT - English
20181212 - PGconfASIA - LT - English
 
20181211 - PGconf.ASIA - NVMESSD&GPU for BigData
20181211 - PGconf.ASIA - NVMESSD&GPU for BigData20181211 - PGconf.ASIA - NVMESSD&GPU for BigData
20181211 - PGconf.ASIA - NVMESSD&GPU for BigData
 
20181210 - PGconf.ASIA Unconference
20181210 - PGconf.ASIA Unconference20181210 - PGconf.ASIA Unconference
20181210 - PGconf.ASIA Unconference
 
20181116 Massive Log Processing using I/O optimized PostgreSQL
20181116 Massive Log Processing using I/O optimized PostgreSQL20181116 Massive Log Processing using I/O optimized PostgreSQL
20181116 Massive Log Processing using I/O optimized PostgreSQL
 
20181016_pgconfeu_ssd2gpu_multi
20181016_pgconfeu_ssd2gpu_multi20181016_pgconfeu_ssd2gpu_multi
20181016_pgconfeu_ssd2gpu_multi
 

Último

2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~arts yokohama
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見Shumpei Kishi
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor arts yokohama
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdfAyachika Kitazaki
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfMatsushita Laboratory
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法ssuser370dd7
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-LoopへTetsuya Nihonmatsu
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)ssuser539845
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦Sadao Tokuyama
 

Último (12)

2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
2024 02 Nihon-Tanken ~Towards a More Inclusive Japan~
 
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
持続可能なDrupal Meetupのコツ - Drupal Meetup Tokyoの知見
 
2024 01 Virtual_Counselor
2024 01 Virtual_Counselor 2024 01 Virtual_Counselor
2024 01 Virtual_Counselor
 
What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?What is the world where you can make your own semiconductors?
What is the world where you can make your own semiconductors?
 
20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf20240326_IoTLT_vol109_kitazaki_v1___.pdf
20240326_IoTLT_vol109_kitazaki_v1___.pdf
 
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdfTaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
TaketoFujikawa_台本中の動作表現に基づくアニメーション原画システムの提案_SIGEC71.pdf
 
2024 04 minnanoito
2024 04 minnanoito2024 04 minnanoito
2024 04 minnanoito
 
2024 03 CTEA
2024 03 CTEA2024 03 CTEA
2024 03 CTEA
 
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
情報処理学会86回全国大会_Generic OAMをDeep Learning技術によって実現するための課題と解決方法
 
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
「今からでも間に合う」GPTsによる 活用LT会 - 人とAIが協調するHumani-in-the-Loopへ
 
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
IFIP IP3での資格制度を対象とする国際認定(IPSJ86全国大会シンポジウム)
 
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
ARスタートアップOnePlanetの Apple Vision Proへの情熱と挑戦
 

(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 の3種類のワークロードに対応 (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