Weitere ähnliche Inhalte Ähnlich wie 20180920_DBTS_PGStrom_JP (20) Mehr von Kohei KaiGai (15) Kürzlich hochgeladen (10) 20180920_DBTS_PGStrom_JP2. 本日のテーマ:とあるベンチマーク結果について
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 20182
ベンチマーク条件
シングルノード環境でのPostgreSQL v11beta3とPG-Strom v2.1develによる結果。
計1055GBのデータに対して13種類のStar Schema Benchmark クエリを実行。
0
2,000
4,000
6,000
8,000
10,000
12,000
14,000
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 for PostgreSQL 11beta3 + PG-Strom v2.1devel
PG-Strom v2.1devel
max 13.5GB/sのクエリ処理速度をシングルノードで実現
3. HeteroDB社について
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 20183
会社概要
商号 ヘテロDB株式会社
創業 2017年7月4日
社員数 2名(海外浩平、柏木岳彦)
拠点 品川区西大井1-1-2-201
事業内容 高速データベース製品の販売
GPU&DB領域の技術コンサルティング
ヘテロジニアスコンピューティング技術を
データベース領域に適用し、
誰もが使いやすく、安価で高速なデータ解析基盤を提供する。
代表者プロフィール
海外 浩平(KaiGai Kohei)
OSS開発者コミュニティにおいて、PostgreSQLやLinux kernelの
開発に10年以上従事。主にセキュリティ・FDW等の分野でアッ
プストリームへの貢献。
2007年 IPA未踏ソフト事業において“天才プログラマー”認定
2017年 GPU Technology ConferenceのTop-5 Posters Finalistに
4. RDBに求められる諸機能
可用性/クラスタリング
バックアップ/運用管理
トランザクション
BI・可視化
PostgreSQLのものをAs-Isで利用
中核技術 – PG-Strom
PG-Strom: GPUの持つ数百~数千コアと広帯域メモリを利用して、
SQLワークロードを高速化するPostgreSQL向け拡張モジュール
GPU
大量データの集計・解析
機械学習・統計解析
PG-Strom
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 20184
大量のデータを高速に
ストレージから読み出す
6. GPUとはどんなプロセッサなのか?(2/3) – 縮約計算の例
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 20186
●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;
集約関数の計算で用いる仕組み
10. 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列
複数の処理アルゴリズムを競わせ、“コスト値”で評価
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201810
12. SQLからGPUコードを自動生成(WHERE句の例)
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201812
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
13. 実行計画を確認する
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201813
postgres=# EXPLAIN ANALYZE
SELECT cat,count(*),sum(ax) FROM tbl NATURAL JOIN t1 WHERE cid % 100 < 50 GROUP BY cat;
QUERY PLAN
---------------------------------------------------------------------------------------------------
GroupAggregate (cost=203498.81..203501.80 rows=26 width=20)
(actual time=1511.622..1511.632 rows=26 loops=1)
Group Key: tbl.cat
-> Sort (cost=203498.81..203499.26 rows=182 width=20)
(actual time=1511.612..1511.613 rows=26 loops=1)
Sort Key: tbl.cat
Sort Method: quicksort Memory: 27kB
-> Custom Scan (GpuPreAgg) (cost=203489.25..203491.98 rows=182 width=20)
(actual time=1511.554..1511.562 rows=26 loops=1)
Reduction: Local
Combined GpuJoin: enabled
-> Custom Scan (GpuJoin) on tbl (cost=13455.86..220069.26 rows=1797115 width=12)
(never executed)
Outer Scan: tbl (cost=12729.55..264113.41 rows=6665208 width=8)
(actual time=50.726..1101.414 rows=19995540 loops=1)
Outer Scan Filter: ((cid % 100) < 50)
Rows Removed by Outer Scan Filter: 10047462
Depth 1: GpuHashJoin (plan nrows: 6665208...1797115,
actual nrows: 9948078...2473997)
HashKeys: tbl.aid
JoinQuals: (tbl.aid = t1.aid)
KDS-Hash (size plan: 11.54MB, exec: 7125.12KB)
-> Seq Scan on t1 (cost=0.00..2031.00 rows=100000 width=12)
(actual time=0.016..15.407 rows=100000 loops=1)
Planning Time: 0.721 ms
Execution Time: 1595.815 ms
(19 rows)
どういう事か?
14. GpuScan + GpuJoin + GpuPreAgg 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%’
実行結果
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201814
GpuScan
GpuJoin
Agg
+
GpuPreAgg
SeqScan
HashJoin
Agg
15. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (2/3)
GpuScan
kernel
GpuJoin
kernel
GpuPreAgg
kernel
DMA
Buffer
GPU
CPU
Storage
単純にロジックを置き換えるだけでは、CPU<->GPU間で
データ転送のピンポンが発生してしまう。
DMA
Buffer
DMA
Buffer
実行結果
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201815
DMA
Buffer
Agg
(PostgreSQL)
16. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (3/3)
GpuScan
kernel
GpuJoin
kernel
GpuPreAgg
kernel
DMA
Buffer
GPU
CPU
Storage
GPU上でデータ交換を行い、無用なDMAを発行しないようにする。
GPU
Buffer
GPU
Buffer 実行結果
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201816
DMA
Buffer
Agg
(PostgreSQL)
SCAN + JOIN + GROUP BYを実行するGPUカーネル
data size
= large
data size
= small
通常、GPUから書き戻されるデータサイズは、
GPUへ転送するデータサイズよりもずっと小さい。
21. ベンチマークによる性能計測 – シングルノード編
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201821
2172.3 2159.6 2158.9 2086.0 2127.2 2104.3
1920.3
2023.4 2101.1 2126.9
1900.0 1960.3
2072.1
6149.4 6279.3 6282.5
5985.6 6055.3 6152.5
5479.3
6051.2 6061.5 6074.2
5813.7 5871.8 5800.1
0
1000
2000
3000
4000
5000
6000
7000
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
QueryProcessingThroughput[MB/sec]
Star Schema Benchmark on NVMe-SSD + md-raid0
PgSQL9.6(SSDx3) PGStrom2.0(SSDx3) HW理論限界値
H/Wスペックの限界に近いSQL処理性能を発揮できている
典型的なバッチ・レポーティング処理を模した Star Schema Benchmark にてスループット計測
CPU: Intel Xeon E5-2650v4, RAM: 128GB, GPU: NVIDIA Tesla P40, SSD: Intel 750 (400GB; SeqRead 2.2GB/s)x3
SSBMのデータサイズは353GBで、確実にI/Oがボトルネックとなるタイプの処理
22. 要素技術 GPUDirect RDMA (1/2)
▌CPUを介さず、GPU他のPCIeデバイス間のP2Pデータ転送を行う機能
元々は、マルチノード環境でInfinibandを介したGPU間のデータ転送効率化技術
Linux kernelドライバを作成する事で、他の PCIe デバイスにも対応可能
Copyright (c) NVIDIA corporation, 2015
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201822
23. 要素技術 GPUDirect RDMA (2/2)
物理アドレス空間
PCIe BAR1領域
GPU
デバイス
メモリ
RAM
NVMe-SSD Infiniband
HBA
PCIe デバイス
GPUDirect RDMA
GPUデバイスメモリを
物理アドレス空間に
マップする機能
『GPUデバイスメモリの物理アドレス』が
存在すれば、PCIeデバイスとのDMAで、
Source/Destinationアドレスとして指定でき
る。
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201823
0xf0000000
0xe0000000
DMA要求
SRC: 1200th sector
LEN: 40 sectors
DST: 0xe0200000
24. SSD-to-GPUダイレクトSQL – ソフトウェアスタック
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201824
Tesla GPU
NVIDIA
CUDA
Toolkit
Filesystem
(ext4, xfs)
nvme driver (inbox)
nvme_strom
kernel
module
NVMe SSD drives
commodity x86_64 hardware
NVIDIA GPUDirect RDMA
NVIDIA
kernel
driver
PostgreSQL
pg_strom
extension
read(2) ioctl(2)
Hardware
Layer
Operating
System
Software
Layer
Database
Software
Layer
Application Software
SQL Interface
I/O path based on
normal filesystem
I/O path based on
SSD-to-GPU Direct SQL Execution
■ ユーザアプリケーション
■ 他社提供のソフトウェア
■ 弊社開発のソフトウェア
■ ハードウェア
v2.0
26. アプローチ① – より高速なNVME-SSDを使ってみる(1/2)
Intel DC P4600 (2.0TB, HHHL)
SeqRead: 3200MB/s, SeqWrite: 1575MB/s
RandRead: 610k IOPS, RandWrite: 196k IOPS
Interface: PCIe 3.0 (x4)
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201826
28. アプローチ② – より新しいCPUを使ってみる(1/2)
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201828
Supermicro 1019GP-TT
CPU: Xeon Gold 6126T (2.6GHz, 12C)
RAM: 192GB (32GB DDR4-2666 x6)
GPU: NVIDIA Tesla P40 (3840C, 24GB) x1
SSD: Intel SSD DC P4600 (2.0TB, HHHL) x3
HDD: 2.0TB (SATA, 72krpm) x6
N/W: 10Gb ethernet x2ports
30. ハードウェア構成に関する考慮事項
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201830
① 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の配下に接続されている必要がある。
CPUよりはPCIeスイッチ経由の方が望ましい。
どういったハードウェアであれば、
PCIeスイッチの構成が取れるか?
32. 実用的な解)I/O拡張ボックスの利用
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201832
SSD~GPU間のデータ転送をCPUから切り離し、PCIeバス負荷を軽減する
NEC ExpEther(40gb, 4slot版)
slot-0
slot-1
slot-2
slot-3
PCIe
スイッチ
slot-0
slot-1
slot-2
slot-3
PCIe
スイッチ
GPU-0
GPU-1
SSD-0
SSD-1
SSD-2
SSD-3
ホスト
RAM
HBA0
HBA1
CPU
GPUでSQL処理を実行した後の
小さなデータ(= I/O負荷少ない)
34. I/O拡張ボックスによるシステム構成
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201834
PCIe I/O Expansion Box
Host System
(x86_64 server)
NVMe SSD
PostgreSQL Tables
PostgreSQL
Data Blocks
Internal
PCIe Switch
SSD-to-GPU P2P DMA
(Large data size)
GPU
WHERE-clause
JOIN
GROUP BY
PCIe over
Ethernet
Pre-processed
small data
Boxあたり
数GB/sの
SQL実行性能
Boxあたり
数GB/sの
SQL実行性能
Boxあたり
数GB/sの
SQL実行性能
NIC / HBA
シングルノードのPostgreSQLなので、
DB運用・アプリ開発が容易
性能・容量の段階的増強
PostgreSQL上ではパーティション化された子テーブルとして管理
v2.1
35. ハードウェアを意識したパーティション構成(1/2)
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201835
lineorder
lineorder_p0
lineorder_p1
lineorder_p2
reminder=0
reminder=1
reminder=2
customer date
supplier parts
tablespace: nvme0
tablespace: nvme1
tablespace: nvme2
パーティション子テーブルとテーブルスペース・I/O拡張ボックスを対応付け
v2.1
36. ハードウェアを意識したパーティション構成(2/2)
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201836
lineorder
lineorder_p0
lineorder_p1
lineorder_p2
reminder=0
reminder=1
reminder=2
customer date
supplier parts
tablespace: nvme0
tablespace: nvme1
tablespace: nvme2
PostgreSQL v11新機能:Hash Partitioningによるデータ分散
key
INSERT ハッシュ化
hash = f(key)
hash % 3 = 2
hash % 3 = 0
元データ
1053GB
部分データ
351GB
部分データ
351GB
部分データ
351GB
v2.1
37. Partition-wise GpuJoin/GpuPreAgg(1/3)
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201837
lineorder
lineorder_p0
lineorder_p1
lineorder_p2
reminder=0
reminder=1
reminder=2
customer date
supplier parts
tablespace: nvme0
tablespace: nvme1
tablespace: nvme2
PostgreSQL v11新機能:各パーティション子テーブルのスキャンを並列実行
Scan
Scan
Scan
Gather
Join
Agg
クエリ結果
Scan
レコード数が多いと
結合処理が大変
v2.1
38. Partition-wise GpuJoin/GpuPreAgg(2/3)
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201838
lineorder
lineorder_p0
lineorder_p1
lineorder_p2
reminder=0
reminder=1
reminder=2
customer date
supplier parts
tablespace: nvme0
tablespace: nvme1
tablespace: nvme2
JOIN / GROUP BYまで終わってから、処理結果を統合したい
Join
Gather
Agg
クエリ結果
Scan
Scan
PreAgg
Join
Scan
PreAgg
Join
Scan
PreAgg
v2.1
39. Partition-wise GpuJoin/GpuPreAgg(3/3)
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201839
ssbm =# 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
-> Gather
Workers Planned: 9
-> Parallel Append
-> Parallel Custom Scan (GpuPreAgg)
Reduction: NoGroup
Combined GpuJoin: enabled
GPU Preference: GPU2 (Tesla P40)
-> Parallel Custom Scan (GpuJoin) on lineorder_p2
Outer Scan: lineorder_p2
Outer Scan Filter: ((lo_discount >= '1'::numeric) AND (lo_discount <= '3'::numeric)
AND (lo_quantity < '25'::numeric))
Depth 1: GpuHashJoin (nrows 102760469...45490403)
HashKeys: lineorder_p2.lo_orderdate
JoinQuals: (lineorder_p2.lo_orderdate = date1.d_datekey)
KDS-Hash (size: 66.03KB)
GPU Preference: GPU2 (Tesla P40)
NVMe-Strom: enabled
-> Seq Scan on date1
Filter: (d_year = 1993)
-> Parallel Custom Scan (GpuPreAgg)
Reduction: NoGroup
Combined GpuJoin: enabled
GPU Preference: GPU1 (Tesla P40)
:
I/O拡張ボックス2で実行できる部分
v2.1
40. SSD~GPU間の距離(1/2)
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201840
lineorder
lineorder_p0
lineorder_p1
lineorder_p2
reminder=0
reminder=1
reminder=2
customer date
supplier parts
tablespace: nvme0
tablespace: nvme1
tablespace: nvme2
あるSSD上のテーブルをスキャンする時は、同一筐体内のGPUを使うべき
Good
Not Good
v2.1
41. SSD~GPU間の距離(2/2)
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201841
$ pg_ctl restart
:
LOG: - PCIe[0000:80]
LOG: - PCIe(0000:80:02.0)
LOG: - PCIe(0000:83:00.0)
LOG: - PCIe(0000:84:00.0)
LOG: - PCIe(0000:85:00.0) nvme0 (INTEL SSDPEDKE020T7)
LOG: - PCIe(0000:84:01.0)
LOG: - PCIe(0000:86:00.0) GPU0 (Tesla P40)
LOG: - PCIe(0000:84:02.0)
LOG: - PCIe(0000:87:00.0) nvme1 (INTEL SSDPEDKE020T7)
LOG: - PCIe(0000:80:03.0)
LOG: - PCIe(0000:c0:00.0)
LOG: - PCIe(0000:c1:00.0)
LOG: - PCIe(0000:c2:00.0) nvme2 (INTEL SSDPEDKE020T7)
LOG: - PCIe(0000:c1:01.0)
LOG: - PCIe(0000:c3:00.0) GPU1 (Tesla P40)
LOG: - PCIe(0000:c1:02.0)
LOG: - PCIe(0000:c4:00.0) nvme3 (INTEL SSDPEDKE020T7)
LOG: - PCIe(0000:80:03.2)
LOG: - PCIe(0000:e0:00.0)
LOG: - PCIe(0000:e1:00.0)
LOG: - PCIe(0000:e2:00.0) nvme4 (INTEL SSDPEDKE020T7)
LOG: - PCIe(0000:e1:01.0)
LOG: - PCIe(0000:e3:00.0) GPU2 (Tesla P40)
LOG: - PCIe(0000:e1:02.0)
LOG: - PCIe(0000:e4:00.0) nvme5 (INTEL SSDPEDKE020T7)
LOG: GPU<->SSD Distance Matrix
LOG: GPU0 GPU1 GPU2
LOG: nvme0 ( 3) 7 7
LOG: nvme5 7 7 ( 3)
LOG: nvme4 7 7 ( 3)
LOG: nvme2 7 ( 3) 7
LOG: nvme1 ( 3) 7 7
LOG: nvme3 7 ( 3) 7
PCIeデバイス間の距離に基づいて、
最適なGPUを自動的に選択する
v2.1
42. ベンチマーク(1/3)– システム構成
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201842
x 1
x 3
x 6
x 3
NEC Express5800/R120g-2m
CPU: Intel Xeon E5-2603 v4 (6C, 1.7GHz)
RAM: 64GB
OS: Red Hat Enterprise Linux 7
(kernel: 3.10.0-862.9.1.el7.x86_64)
CUDA-9.2.148 + driver 396.44
DB: PostgreSQL 11beta3 + PG-Strom v2.1devel
NEC ExpEther (40Gb; 4slots版)
I/F: PCIe 3.0 x8 (x16 physical) ... 4slots
with internal PCIe switch
N/W: 40Gb-ethernet
Intel DC P4600 (2.0TB; HHHL)
SeqRead: 3200MB/s, SeqWrite: 1575MB/s
RandRead: 610k IOPS, RandWrite: 196k IOPS
I/F: PCIe 3.0 x4
NVIDIA Tesla P40
# of cores: 3840 (1.3GHz)
Device RAM: 24GB (347GB/s, GDDR5)
CC: 6.1 (Pascal, GP104)
I/F: PCIe 3.0 x16
SPECIAL THANKS FOR
v2.1
43. ベンチマーク(2/3) – 測定結果
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201843
I/O拡張ボックス毎に351GB、計1055GBのデータベースを構築し、13種類のSSBMクエリを実行
SQL実行を伴わない SSDHost への Raw-I/O データ転送は 9GB/s 弱が限界。
つまり、Raw-I/Oのストレージ読出しよりも、SQLを高速に実行てきている。
13,401 13,534 13,536 13,330
12,696
12,965
12,533
11,498
12,312 12,419 12,414 12,622 12,594
2,388 2,477 2,493 2,502 2,739 2,831
1,865
2,268 2,442 2,418
1,789 1,848
2,202
0
2,000
4,000
6,000
8,000
10,000
12,000
14,000
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 for PgSQL v11beta3 / PG-Strom v2.1devel on NEC ExpEther x3
PostgreSQL v11beta3 PG-Strom v2.1devel Raw-I/O限界値
I/O拡張ボックス3台構成で、max 13.5GB/s のクエリ処理速度を実現!
v2.1
44. ベンチマーク(3/3) – 測定結果
GPUとNVMEでPostgreSQLの限界に挑む - DB Tech Showcase Tokyo 201844
0
2000
4000
6000
8000
10000
12000
14000
16000
nvme0n1 nvme1n1 nvme2n1 nvme3n1 nvme4n1 nvme5n1
各I/O拡張ボックスに均等にI/O負荷が分散しており、更なるスケールが期待できる
SQL実行中のRaw-I/O性能は、I/O拡張ボックスあたり5000~5100MB/s、NVME-SSDあたり 2600MB/s 程度。
I/O拡張ボックス間で負荷が偏っていないため、機材を増設した時の性能スケールが期待できる。
8枚搭載時の予想性能は 4.5GB/s x8 = 36GB/s前後で、DWH専用機に匹敵する性能をPostgreSQLで実現可能。
v2.1
46. 想定利用シーン – ログデータ処理・解析
GPU Technology Conference Japan 2018 - HeteroDB,Inc46
増え続けるログデータの管理、集計から解析・機械学習まで対応したデータ管理基盤
Manufacturing Logistics Mobile Home electronics
GPU + NVME-SSD
なぜPG-Stromを適用するのか?
処理ユニットの拡張により、シングルノードで~数十TBのデータにも対応。
蓄積した生ログデータのまま、H/W限界に近い速度で集計する事が可能。
使い慣れたPostgreSQLのSQL構文、周辺アプリケーションを適用可能。
47. まとめ
GPU Technology Conference Japan 2018 - HeteroDB,Inc47
PG-Strom
GPUを用いてSQLを高速化するPostgreSQL向け拡張モジュール。H/Wのポテンシャルを
最大限に引き出す事で、TB級以上の大量データを集計・解析するためのソフトウェア
ユニーク技術:SSD-to-GPUダイレクトSQL
NVME-SSD上のデータブロックをP2P DMAによりGPUへ直接転送。ホストシステムへ
データをロードする前にSQL処理をGPUで実行。データ量を減らす事で、結果として
I/Oの処理性能を改善する。
I/O拡張ボックスを利用したマルチGPU/SSD構成
PCIeバスのRoot-complexであるCPUの負荷集中を避けるため、PCIeスイッチを内蔵する
I/O拡張ボックスにより、ストレージに近い場所でP2P DMAのパケット交換を行う。
CPUの負荷軽減だけでなく、DB容量・処理性能の要請に応じた段階的増強が可能。
3台構成で処理性能 13.5GB/s までは実証。それ以上はハードウェア次第。
適用領域
M2Mを含め、大量のログ情報を集積・集計するデータベース。
シングルノードのPostgreSQLという運用のシンプルさと、
使い慣れたSQLやアプリケーションといったスキルセットの継続性が特長。
小規模な Hadoop クラスタや、エントリークラスのDWH専用機がターゲット。