20181211 - PGconf.ASIA - NVMESSD&GPU for BigData

ビッグデータ処理のためのGPUとNVME-SSD活用
～クエリ処理速度10GB/sへの挑戦～
HeteroDB,Inc
Chief Architect & CEO
海外浩平 <kaigai@heterodb.com>

テーマ：どのようにしてこのベンチマーク結果を実現したのか
ビッグデータ処理のためのGPUとNVME-SSD活用 - PGconf.ASIA 20182
ベンチマーク条件
 シングルノード環境でのPostgreSQL v11beta3とPG-Strom v2.1develによる結果。
 1.05TBのデータベースに対して13種類のStar Schema Benchmark クエリを実行。
➔全件スキャンを含む集計系クエリを80秒弱で実行 ≒ 13.5GB/s
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のクエリ処理速度をシングルノードで実現

HeteroDB社について
会社概要
 商号ヘテロDB株式会社
 創業 2017年7月4日
 拠点品川区西大井1-1-2-201
 事業内容高速データベース製品の販売
GPU＆DB領域の技術コンサルティング
ヘテロジニアスコンピューティング技術を
データベース領域に適用し、
誰もが使いやすく、安価で高速なデータ解析基盤を提供する。
代表者プロフィール
 海外浩平（KaiGai Kohei）
 OSS開発者コミュニティにおいて、PostgreSQLやLinux kernelの
開発に10年以上従事。主にセキュリティ・FDW等の分野でアッ
プストリームへの貢献。
 2007年 IPA未踏ソフト事業において“天才プログラマー”認定
 2017年 GPU Technology ConferenceのTop-5 Posters Finalistに

RDBに求められる諸機能
✓ 可用性／クラスタリング
✓ バックアップ／運用管理
✓ トランザクション
✓ ＢＩ・可視化
➔ PostgreSQLのものをAs-Isで利用
中核技術 – PG-Strom
PG-Strom: GPUの持つ数百～数千コアと広帯域メモリを利用して、
SQLワークロードを高速化するPostgreSQL向け拡張モジュール
GPU
大量データの集計・解析
機械学習・統計解析
PG-Strom
大量のデータを高速に
ストレージから読み出す

GPUとはどんなプロセッサなのか？
主にHPC分野で実績があり、機械学習用途で爆発的に普及
NVIDIA Tesla V100
スーパーコンピュータ
（東京工業大学 TSUBAME3.0）ＣＧ（Computer Graphics）機械学習
“計算アクセラレータ”のGPUで、どうやってI/Oを高速化するのか？
シミュレーション

PostgreSQLはどうGPUを活用するのか？
～PG-Stromのアーキテクチャ～

PostgreSQL  PG-Strom間の相互作用
SQL Parser
Query
Optimizer
Query
Executor
Storage Manager
Database Files
GPU Path
constructor
GPU Code
generator
GPU JIT
compiler
(NVRTC)
GpuScan
GpuJoin
GpuPreAgg
PL/CUDA
nvme-strom Gstore_fdw
CustomScanインターフェース
(PgSQL v9.5~)
PG-Strom

PostgreSQLはどのように実行計画を作るか
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列
複数の処理アルゴリズムを競わせ、“コスト値”で評価

CustomScanによる介入
同じ結果を返しさえすれば、手段は問わない。
CustomScan (GpuJoin)
(*BeginCustomScan)(...)
(*ExecCustomScan)(...)
(*EndCustomScan)(...)
:
SeqScan
on t0
SeqScan
on t1
GroupAgg
key: cat
ExecInitGpuJoin(...)
 GPUコンテキストの初期化
 自動生成したGPUプログラムの
実行時コンパイル開始
ExecGpuJoin(...)
 配下のt0,t1からデータを読み出し、
DMAバッファにセット
 GPUへ非同期タスクをキック
 実行が完了した非同期タスクを
取り出し、結果をGroupAggへ渡す。
ExecEndGpuJoin(...)
 非同期タスクの終了待ち（あれば）
 GPUリソースの解放

SQLからGPUコードを自動生成（WHERE句の例）
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

実行計画を確認する
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)
Sort Key: tbl.cat
Sort Method: quicksort Memory: 27kB
-> Custom Scan (GpuPreAgg) (cost=203489.25..203491.98 rows=182 width=20)
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)
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)
Planning Time: 0.721 ms
Execution Time: 1595.815 ms
(19 rows)
どういう事か？

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%’
実行結果
GpuScan
GpuJoin
Agg
+
GpuPreAgg
SeqScan
HashJoin
Agg

GpuScan
kernel
GpuJoin
kernel
GpuPreAgg
kernel
DMA
Buffer
GPU
CPU
Storage
単純にロジックを置き換えるだけでは、CPU<->GPU間で
データ転送のピンポンが発生してしまう。
DMA
Buffer
DMA
Buffer
実行結果
DMA
Buffer
Agg
(PostgreSQL)

GpuScan
kernel
GpuJoin
kernel
GpuPreAgg
kernel
DMA
Buffer
GPU
CPU
Storage
GPU上でデータ交換を行い、無用なDMAを発行しないようにする。
GPU
Buffer
GPU
Buffer 実行結果
DMA
Buffer
Agg
(PostgreSQL)
SCAN + JOIN + GROUP BYを実行するGPUカーネル
data size
= large
data size
= small
通常、GPUから書き戻されるデータサイズは、
GPUへ転送するデータサイズよりもずっと小さい。

実行計画を確認する（再掲）
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)
Group Key: tbl.cat
-> Sort (cost=203498.81..203499.26 rows=182 width=20)
Sort Key: tbl.cat
Sort Method: quicksort Memory: 27kB
-> Custom Scan (GpuPreAgg) (cost=203489.25..203491.98 rows=182 width=20)
Reduction: Local
-> 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)
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)
Planning Time: 0.721 ms
Execution Time: 1595.815 ms
(19 rows)
Combined GPU kernel で処理する部分

GPUの役割を再定義する
～どのようにI/Oを高速化するのか～

一般的な x86_64 サーバの構成
GPUSSD
CPU
RAM
HDD
N/W

大量データを処理する時のデータの流れ
CPU RAM
SSD GPU
PCIe
PostgreSQL
データブロック
通常のデータフロー
本来は不要なレコードであっても、
一度CPU/RAMへロードしなければ
要・不要を判断できないため、
データサイズは大きくなりがち。
一度CPU/RAMへロードしなければ、
“ゴミデータ” であってもその要否を判断できない。

中核機能：SSD-to-GPUダイレクトSQL
CPU RAM
SSD GPU
PCIe
PostgreSQL
NVIDIA GPUDirect RDMA
CPU/RAMを介することなく、
Peer-to-PeerのDMAを用いて
SSD上のデータブロックを直接
GPUに転送する機能。
WHERE句
JOIN
GROUP BY
GPUでSQLを処理し、
データ量を削減する
データ量：小
v2.0

要素技術 GPUDirect RDMA (1/2)
▌CPUを介さず、GPU他のPCIeデバイス間のP2Pデータ転送を行う機能
 元々は、マルチノード環境でInfinibandを介したGPU間のデータ転送効率化技術
 Linux kernelドライバを作成する事で、他の PCIe デバイスにも対応可能
Copyright (c) NVIDIA corporation, 2015

要素技術 GPUDirect RDMA (2/2)
物理アドレス空間
PCIe BAR1領域
GPU
デバイス
メモリ
RAM
NVMe-SSD Infiniband
HBA
PCIe デバイス
GPUDirect RDMA
GPUデバイスメモリを
物理アドレス空間に
マップする機能
『GPUデバイスメモリの物理アドレス』が
存在すれば、PCIeデバイスとのDMAで、
Source/Destinationアドレスとして指定できる。
0xf0000000
0xe0000000
DMA要求
SRC: 1200th sector
LEN: 40 sectors
DST: 0xe0200000

ベンチマーク結果（シングルノード）
NVME and GPU accelerates PostgreSQL beyond the limitation -PGconf.EU 2018-22
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) H/W Spec (3xSSD)
SSD-to-GPU Direct SQLでハードウェアの限界に近いSQL処理速度を実現
 DBサイズ 353GB (sf: 401) の Star Schema Benchmark を用いてクエリ処理時間を計測
 CPU: Intel Xeon E5-2650v4, RAM: 128GB, GPU: NVIDIA Tesla P40, SSD: Intel 750 (400GB; SeqRead 2.2GB/s)x3
 NVME-SSDの理論限界は 2.2GB/s x 3 = 6.6GB/s。SQL処理スループットもそれに近い 6.2GB/s まで出ている。

SSD-to-GPU Direct SQL - ソフトウェアスタック
Filesystem
(ext4, xfs)
nvme_strom
kernel module
NVMe SSD
NVIDIA Tesla GPU
PostgreSQL
pg_strom
extension
read(2) ioctl(2)
Hardware
Layer
Operating
System
Software
Layer
Database
Software
Layer
blk-mq
nvme pcie nvme rdma
Network HBA
ファイルオフセット ➔
NVME-SSDのセクタ番号変換
NVMEoF Target
(JBOF)
NVMe
Request
■ その他のソフトウェア
コンポーネント
■ PG-Stromプロジェクトの
開発したソフトウェア
■ ハードウェア
NVME over Fabric
nvme_strom v2.0 で
NVME-over-Fabric (RDMA) に対応

uninitialized
File
BLK-100: unknown
BLK-101: unknown
BLK-102: unknown
BLK-103: unknown
BLK-104: unknown
BLK-105: unknown
BLK-106: unknown
BLK-107: unknown
BLK-108: unknown
BLK-109: unknown
（参考）PostgreSQL / Linux kernelディスクバッファとの一貫性
BLK-100: uncached
BLK-101: cached by PG
BLK-102: uncached
BLK-103: uncached
BLK-104: cached by OS
BLK-106: uncached
BLK-107: uncached
BLK-109: uncached
BLCKSZ
(=8KB)
Transfer Size
Per Request
BLCKSZ *
NChunks
BLK-100: uncached
BLK-102: uncached
BLK-103: uncached
BLK-106: uncached
BLK-107: uncached
BLK-109: uncached
unused
SSD-to-GPU
P2P DMA
Userspace DMA
Buffer (RAM)
Device Memory
(GPU)
CUDA API
(userspace)
cuMemcpyHtoDAsync
① PG-Strom がPostgreSQLの shared buffer をチェックする
✓ 対象ブロックが既にPostgreSQLによって shared buffer にロードされていた場合
✓ 対象ブロックがall-visibleでない可能性がある場合（visibility-mapによる検査）
② NVME-StromがOSの page cache をチェックする
✓ 対象ブロックが既にLinux kernelによって page cache 上にロードされていた場合
✓ 但し、fast-SSD modeであり当該 page cache が dirty である場合を除く
③ その他のブロックに対しSSD-to-GPU P2P DMAを実行

適用例：ログ集積・解析システム
GPU+NVME-SSD搭載
データベースサーバ
SQLによる検索
セキュリティ事故
被害状況把握
影響範囲特定
責任者への報告
• 高速なトライ＆エラー
• 使い慣れたインターフェース
• 行データのままで高速な検索
従来システム40分の
クエリを30秒で実行
Aug 12 18:01:01 saba systemd: Started
Session 21060 of user root.

Run faster, beyond the limitation

アプローチ① – より高速な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)

アプローチ① – より高速なNVME-SSDを使ってみる（2/2）
Broadwell-EP世代のCPUでは、P2P DMAのルーティング性能7.1GB/sで頭打ち

アプローチ② – より新しいCPUを使ってみる（1/2）
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

アプローチ② – より新しいCPUを使ってみる（2/2）
Skylake-SP世代のCPUで、P2P DMAのルーティング性能8.5GB/sまで改善
GPU
SSD-1
SSD-2
SSD-3
md-raid0
Xeon
Gold
6126T
routing
by CPU

ハードウェア構成に関する考慮事項（1/3）
① 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スイッチ経由の方が望ましい。
https://docs.nvidia.com/cuda/gpudirect-rdma/index.html#supported-systems

PCIe-switchがI/Oをバイパスする事でCPUの負荷を軽減できる。
CPU CPU
PLX
SSD GPU
PLX
SSD GPU
PLX
SSD GPU
PLX
SSD GPU
SCAN SCAN SCAN SCAN
JOIN JOIN JOIN JOIN
GROUP BY GROUP BY GROUP BY GROUP BY
非常に少ないボリュームのデータ
GATHER GATHER

PCIeスイッチ付ハードウェア（1/2）- HPC向けサーバ
Supermicro SYS-4029TRT2
x96 lane
PCIe switch
x96 lane
PCIe switch
CPU2 CPU1
QPI
Gen3
x16
Gen3 x16
for each slot
Gen3 x16
for each slot
Gen3
x16
マルチノードMPI向けに最適化されたハードウェアが売られている

PCIeスイッチ付ハードウェア（2/2）- I/O拡張ボックス
NEC ExpEther 40G (4slots)
4 slots of
PCIe Gen3 x8
PCIe
Swich
40Gb
Ethernet ネットワーク
スイッチ
CPU
NIC
追加のI/O boxes
必要性能・容量に応じてハードウェアを柔軟に増設できる

Most of the SQL workloads are executed inside of the I/O box
CPU CPU
PLX
SSD GPU
PLX
SSD GPU
PLX
SSD GPU
PLX
SSD GPU
SCAN SCAN SCAN SCAN
JOIN JOIN JOIN JOIN
GROUP BY GROUP BY GROUP BY GROUP BY
GATHER GATHER
I/O BoxI/O BoxI/O BoxI/O Box

I/O拡張ボックスによる
ストレージパスの最適化

I/O拡張ボックスによるシステム構成
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

ハードウェアを意識したパーティション構成
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

Partition-wise GpuJoin/GpuPreAgg（1/3）
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

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

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
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)
NVMe-Strom: enabled
-> Seq Scan on date1
Filter: (d_year = 1993)
-> Parallel Custom Scan (GpuPreAgg)
Reduction: NoGroup
:
I/O拡張ボックス2で実行できる部分
v2.1

SSD～GPU間の距離（1/2）
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

SSD～GPU間の距離（2/2）
$ 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

ベンチマーク（1/3）– システム構成
HeteroDB Products Brief (1H-2019 edition)44
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
lineorder_a
(351GB)
lineorder_b
(351GB)
lineorder_c
(351GB)
NEC ExpEther (40Gb; 4slots版)
I/F: PCIe 3.0 x8 (x16幅) x4スロット
+ internal PCIe switch
N/W: 40Gb-ethernet
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
Intel DC P4600 (2.0TB; HHHL)
SeqRead: 3200MB/s
SeqWrite: 1575MB/s
RandRead: 610k IOPS
RandWrite: 196k IOPS
I/F: PCIe 3.0 x4
v2.1
SPECIAL THANKS FOR

ベンチマーク（2/3） – 測定結果
 I/O拡張ボックス毎に351GB、計1055GBのデータベースを構築し、13種類のSSBMクエリを実行
 SQL実行を伴わない SSD→Host への Raw-I/O データ転送は 9GB/s 弱が限界。
つまり、Raw-I/Oのストレージ読出しよりも、SQLを高速に実行てきている。
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
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
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

ベンチマーク（3/3） – 測定結果
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

13.5GB/s
3x I/O拡張ボックス
30GB/s（予想）
8x I/O拡張ボックス
シングルノードのPostgreSQLで、DWH専用機や小規模クラスタ並み処理性能

想定利用シーン – M2Mログデータ処理・解析
増え続けるログデータの管理、集計から解析・機械学習まで対応したデータ管理基盤
Manufacturing Logistics Mobile Home electronics
GPU + NVME-SSD
なぜPG-Stromを適用するのか？
 処理ユニットの拡張により、シングルノードで～数十TBのデータにも対応。
 蓄積した生ログデータのまま、H/W限界に近い速度で集計する事が可能。
 使い慣れたPostgreSQLのSQL構文、周辺アプリケーションを適用可能。

今後の方向性

今後の方向性
CPU RAM
SSD GPU
PCIe
PostgreSQL
WHERE句
JOIN
GROUP BY
データ量：小
Apache
Arrow
ファイル
その①
より大容量のストレージ・
データサイズに対応する。
その②
SSD～GPU間の
データ転送効率を高める。
その③
GPU上でのクエリ処理効率を高くする

NVME-over-Fabric (RDMA) 対応
ready
ホストシステム
SSD
SSD
SSD
HBA
CPU
100Gb
ネットワーク
JBOF
✓ サーバ筐体に搭載可能な限界を越えてNVME-SSDを搭載可能
✓ データサイズの増加に合わせてストレージ容量を拡張可能
GPU/DB-node
Storage-node
SSD-to-GPU Direct SQL
over 100Gb Ethernet
with RDMA protocol
SSD
SSD
SSD
SSD
SSD
SSD
SSD
SSD
SSD
HBA
JBOF
SSD
SSD
SSD
SSD
SSD
SSD
HBA
51
PCIe
Switch
8.0TB x 32
= 256TB

列形式データファイルの直接マッピング (1/2)
▌大量のログデータをDBへ取り込む際の課題
 PostgreSQL内部データ形式への変換と、トランザクション制御の負荷が高く時間を要する
 そもそもログデータに行単位の可視性チェック（MVCC）は不要
➔特定の外部データ形式（Apache Arrowなど）をGPUが理解し、処理できるようにする事で、
センサ／ログデータの高速な解析と、SQLによる柔軟なデータ操作の両立が可能。
外部テーブル（Foreign Table）－ PostgreSQL管理外のデータソースを、
あたかもテーブルであるかのように取り扱うための機能
Table
外部テーブル
postgres_fdw
外部テーブル
file_fdw
外部テーブル
Gstore_fdw
外部テーブル
Arrow_fdw
外部RDBMSサーバ
CSVファイル
GPUデバイスメモリ
Arrowファイル
WIP

列形式データファイルの直接マッピング (2/2)
PostgreSQLデータブロック（行形式）に加えて、GPU側のSQL実装を
Arrow形式に対応させる事で、不要なI/Oとデータ形式変換を避ける
Foreign Scan
GpuJoin
GpuPreAgg
Agg
Arrowファイル
ストレージI/O
SSD→CPU
CPU → GPU
GPU → GPU
GPU → CPU
データ形式変換
（CPU）
負荷の大半は
この部分に集中
GpuJoin on
Arrow Files
GpuPreAgg
Agg
Arrowファイル
ストレージI/O
SSD→GPU
GPU → GPU
GPU → CPU
Point-1
列指向形式なので、
転送すべきデータ量が
少なくて済む
Point-2
列指向形式なので、
GPUのメモリアクセス
性能を引き出しやすい
従来の動作 Arrow 形式への対応強化
WIP

《補足》なぜGPUには列指向のデータが向いているか？
▌行データ形式 – 不連続なデータアクセス (random memory access)
➔ メモリトランザクションの回数が増え、データバスの使用率が低下
▌列データ形式 – 隣接領域に対するデータアクセス (coalesced memory access)
➔ 最小限のメモリトランザクション回数、データバスの使用率を最大化
32bit
Memory transaction width: 256bit
32bit 32bit32bit 32bit 32bit
32bit 32bit 32bit 32bit 32bit 32bit 32bit 32bit
Memory transaction width: 256bit
256bit幅のメモリトランザクション中、
32bit x 8 = 256bitが有効なデータ
（バス使用率 100.0%）
256bit幅のメモリトランザクション中、
32bit x 1 = 32bitのみ有効なデータ
（バス使用率 12.5%）
GPUコア
GPUコア

《将来像》GPU/SSDの潜在能力を引き出し、サーバ集約を実現
従来、数十台のサーバで分散処理を行っていたワークロードを、
NVME-SSDとGPUという最新ハードウェアの力で2～3Uサイズに圧縮
従来型サーバの処理能力を
１台あたり600MB/sとすると、
4GPU構成での期待性能値30GB/sは、
従来型サーバ50台分の処理能力に
相当する。

まとめ
 PG-Strom
GPUを用いてSQLを高速化するPostgreSQL向け拡張モジュール。H/Wのポテンシャルを
最大限に引き出す事で、TB級以上の大量データを集計・解析するためのソフトウェア
 ユニーク技術：SSD-to-GPUダイレクトSQL
NVME-SSD上のデータブロックをP2P DMAによりGPUへ直接転送。ホストシステムへ
データをロードする前にSQL処理をGPUで実行し、データ量を減らす。
その結果、I/OボトルネックのSQL処理性能を改善する。
 I/O拡張ボックスを利用したマルチGPU/SSD構成
PCIeバスを制御するCPUの負荷集中を避けるため、PCIeスイッチ内蔵のI/O拡張ボックスを
用いて、ストレージに近い場所でP2P DMAのPCIeパケットを交換する。
CPUの負荷軽減だけでなく、DB容量・処理性能の要請に応じた段階的増強が可能。
3台構成で処理性能 13.5GB/s までは実証。それ以上はハードウェア次第。
 適用領域
M2M／IoTといった、大量のログ情報を集積・処理するデータベースシステム。
シングルノードのPostgreSQLという運用のシンプルさと、
使い慣れたSQLやアプリケーションといったスキルセットの継続性が特長。
 今後の方向性
より大規模なストレージ … NVME-over-Fabric対応
より効率的なデータ読出し … 列形式（Apache Arrow）ファイル対応

まとめ
▌Gitリポジトリ
https://github.com/heterodb/pg-strom
▌ドキュメント
http://heterodb.github.io/pg-strom/ja/
▌コンタクト
ML: pgstrom@heterodb.com
e-mail: kaigai@heterodb.com
twitter: @kkaigai
Questions?

20181211 - PGconf.ASIA - NVMESSD&GPU for BigData

20181211 - PGconf.ASIA - NVMESSD&GPU for BigData

20181211 - PGconf.ASIA - NVMESSD&GPU for BigData

Recommended

More Related Content

What's hot

What's hot(20)

Similar to 20181211 - PGconf.ASIA - NVMESSD&GPU for BigData

Similar to 20181211 - PGconf.ASIA - NVMESSD&GPU for BigData(20)

More from Kohei KaiGai

More from Kohei KaiGai(20)

Recently uploaded

Recently uploaded(7)

20181211 - PGconf.ASIA - NVMESSD&GPU for BigData