GPUとSSDがPostgreSQLを加速する
～クエリ処理スループット10GB/sへの挑戦～
HeteroDB,Inc
チーフアーキテクト 兼 代表取締役社長
海外 浩平 <kaigai@heterodb.com>

自己紹介
HBStudy#80 - GPUとSSDがPostgreSQLを加速する2
▌会社概要
 商号 ヘテロDB株式会社
 創業 2017年7月4日
 社員数 2名（海外浩平、柏木岳彦）
 事業内容 データ解析アプライアンス製品販売
データベース技術コンサルティングサービス
 拠点 品川区西大井1-1-2-206 (西大井創業支援センター内)
▌代表者プロフィール
 海外 浩平 (KaiGai Kohei)
 OSS開発者コミュニティにおいて、PostgreSQLやLinux kernelの開
発に10年以上従事。セキュリティ強化や外部データ連携等の貢
献があり、PostgreSQLのMajor Contributor として知られている。
 2007年 IPA未踏ソフト事業において “天才プログラマー” 認定
 2012年～ GPUによるPostgreSQL高速化モジュールの開発を開始
 2017年 NECを退職し、柏木と共に HeteroDB 社を創業

まさかの日経デビュー
HBStudy#80 - GPUとSSDがPostgreSQLを加速する3

我々のミッション
+
GPUを用いたSQL処理の高速化製品の提供
GPU
PG-Strom
HBStudy#80 - GPUとSSDがPostgreSQLを加速する4

データ解析基盤としての用途
✓ バッチ／レポーティング
✓ ビジネスインテリジェンス
✓ 異常検知／ログ解析
✓ 統計解析／機械学習
etc...
RDBMSとしての本質的な機能
✓ SQLパース／クエリ最適化
✓ トランザクション
✓ バックアップ／可用性
✓ レプリケーション
✓ スケールアウト
✓ 周辺ツールとの接続
etc...
PG-Stromとは？ (1/2)
一部処理のオフロード
PG-Strom: GPUの持つ数千並列コアと広帯域メモリを活用して
SQLワークロードを高速化するPostgreSQL向け拡張モジュール
自前で何もかも揃えるのではな
く、
PostgreSQL本体機能・周辺機能を
必要に応じてチョイスする。
HBStudy#80 - GPUとSSDがPostgreSQLを加速する5

GPUの特徴
HBStudy#80 - GPUとSSDがPostgreSQLを加速する6
GPU CPU
モデル
NVIDIA
Tesla P40
Intel Xeon
E5-2699v4
世代 Pascal Broadwell
発表 Q3-2016 Q1-2016
トランジスタ数 12billion 7.2billion
コア数
3840
(simple)
22
(functional)
動作クロック
1.306GHz
~1.53GHz
2.20GHz
~3.60GHz
理論性能値
(FP32)
12 TFLOPS
1.2 TFLOPS
(with AVX2)
RAMサイズ 24GB (GDDR5) max1.5TB (DDR4)
メモリ帯域 347GB/s 76.8GB/s
消費電力 250W 145W
製造プロセス 16nm 14nm
CPU: 小回りが利くが、輸送力は小さな
乗用車のようなプロセッサ
GPU: 駅でしか乗り降りできないが、
大量輸送が可能な高速鉄道のような
プロセッサ

GPU活用による計算 – 縮約アルゴリズムの例
●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;
集約関数の計算で用いる仕組み
HBStudy#80 - GPUとSSDがPostgreSQLを加速する7

PostgreSQLの共通インフラ
PG-Stromとは？ (2/2)
HBStudy#80 - GPUとSSDがPostgreSQLを加速する8
SQL Parser
Query
Optimizer
Query
Executor
Storage
PG-Strom
CustomScan
Interface
Database Applications
Storage
Manager
Transaction
Manager
Parallel
Workers
【I/O中心ワークロードの高速化】
 SSD-to-GPUダイレクトSQL実行
 インメモリ列指向キャッシュ
 時系列データへの対応
【基本機能】
• SQL to GPUプログラムジェネレータ
• GPUコード実行時コンパイラ
• GPUカーネルの非同期並列実行
【計算中心ワークロードの高速化】
 PL/CUDA ユーザ定義関数
 gstore_fdw – onGPUデータストア
 SCAN+JOIN+GROUP BY
Combined kernel
v2.0
v2.0

PostgreSQL/PG-Stromは
どのようにクエリを実行するか

PostgreSQLの内部構造
SQL Parser
Query Optimizer
Query Executor
Storage
Manager
Transaction
Manager
IPC
(Lock, Latch,
shmem)
SQLクエリ
パース木
クエリ実行計画
クエリ
実行結果  SQL構文を分解し、取り扱いやすい
内部データ形式（パース木）に変換
 文法エラーの検出
 統計情報を元にコスト値を算出
 最も合理的と予想される実行計画を
作成する。
 クエリ実行計画に基づいて、
ScanやJoin、Sortなどを実行する。
 PostgreSQL内部のインフラを使用
HBStudy#80 - GPUとSSDがPostgreSQLを加速する10

PostgreSQLはどのように実行計画を作るか (1/2)
Scan
t0 Scan
t1
Scan
t2
Join
t0,t1
Join
(t0,t1),t2
GROUP
BY cat
ORDER
BY score
LIMIT
100
HBStudy#80 - GPUとSSDがPostgreSQLを加速する11

PostgreSQLはどのように実行計画を作るか (2/2)
Scan
t0 Scan
t1
Join
t0,t1
統計情報）
nrows: 120万行
width: 80
インデックス：なし
候補パス
HashJoin
cost=4000
候補パス
MergeJoin
cost=12000
候補パス
NestLoop
cost=99999
候補パス
Parallel
Hash Join
cost=3000
候補パス
GpuJoin
cost=2500
WINNER!
PostgreSQLビルトインの実行パス拡張モジュールによる提案
（PostgreSQL v9.5以降）
（PostgreSQL v9.6以降）
GpuJoin
t0,t1
統計情報）
nrows: 4000行
width: 120
インデックス：id列
複数の処理アルゴリズムを競わせ、“コスト値”で評価
HBStudy#80 - GPUとSSDがPostgreSQLを加速する12

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

PG-Strom基本機能(1/2) – SQLからGPUコードを自動生成
HBStudy#80 - GPUとSSDがPostgreSQLを加速する14
QUERY: SELECT cat, count(*), avg(x) FROM t0
WHERE x between y and y + 20.0 GROUP BY cat;
:
STATIC_FUNCTION(bool)
gpupreagg_qual_eval(kern_context *kcxt,
kern_data_store *kds,
size_t kds_index)
{
pg_float8_t KPARAM_1 = pg_float8_param(kcxt,1);
pg_float8_t KVAR_3 = pg_float8_vref(kds,kcxt,2,kds_index);
pg_float8_t KVAR_4 = pg_float8_vref(kds,kcxt,3,kds_index);
return EVAL((pgfn_float8ge(kcxt, KVAR_3, KVAR_4) &&
pgfn_float8le(kcxt, KVAR_3,
pgfn_float8pl(kcxt, KVAR_4, KPARAM_1))));
} :
例) 条件句中の数値演算式を
CUDA命令列にオンデマンドで変換
Reference to input data
SQL expression in CUDA source code
Run-time
Compiler
(nvrtc)
Just-in-time
Compile
Parallel
Execution
v1.0

PG-Strom基本機能(2/2) – 非同期・並列実行
HBStudy#80 - GPUとSSDがPostgreSQLを加速する15
非同期DMA転送
GPUメモリ
GPU搭載の数千コアによる
並列実行
処理済みのブロックは開放
GPUへのデータ転送と、GPUでのSQL処理をパイプライン化する事で
PCIeバスのデータ転送速度の “遅さ” を隠ぺい。
 同時に、GPU RAMサイズ以上のデータを効率的に処理する事が可能に。
約64MBのブロック毎に転送
平均10万～30万行を含む
GPU上のバッファに余裕がある限り、
先行ブロックの処理完了を待たず、
次々にデータを送り込む。
v1.0

実際にユーザ様の課題をヒアリングしてみると・・・。
I/O
(ストレージ)
計算
(CPU)
『大量データの処理で困ってるんです・・・』
 実際にはCPU以上にI/O問題である事もしばしば
HBStudy#80 - GPUとSSDがPostgreSQLを加速する16

果たして I/O のボトルネックを PG-Strom で解消できるのか？
HBStudy#80 - GPUとSSDがPostgreSQLを加速する17

SSD-to-GPUダイレクトSQL実行
～GPUの役割を再定義する～

SSD-to-GPUダイレクトSQL実行とは
HBStudy#80 - GPUとSSDがPostgreSQLを加速する19
PCIe Bus
NVMe SSD GPU
SSD-to-GPU P2P DMA
(NVMe-Stromドライバ)
WHERE句
JOIN
GROUP BY
Large PostgreSQL
Tables
PostgreSQL
データブロック
SSD-to-GPUダイレクトSQL
SSDから転送したレコードを、
GPUの数千コアを用いて
SQLワークロードを実行。
CPUがロード/処理すべきデータ
量を削減し、I/Oを高速化。
従来のデータフロー
本来は不要なレコードであっても、
一度CPU/RAMへロードしなければ
要・不要を判断できないため、
データサイズは大きくなりがち。
SELECT cat, count(*), avg(X)
FROM t0 JOIN t1 ON t0.id = t1.id
WHERE YMD >= 20120701
GROUP BY cat;
SQL最適化ステージ
SQL実行ステージ
SQL-to-GPU
プログラム
ジェネレータ
GPUコード
実行時
コンパイル
SQLからGPUプログラムを
自動的に生成し、実行時
コンパイルを行う
ストレージからデータをロードする“前に” GPUでデータ量を減らす。
GPUコード生成
SQLから自動的にGPU
コードを生成するた
め、利用者からは透過
的にGPUを使用するよ
うに見える。
GPUでのSQL実行
PostgreSQLのデータ
ブロックを、直接
SSDからGPUへ転送。
SQLワークロードを
GPU上で並列実行する
事で、不要なデータを
ふるい落とす。
CPUでのSQL実行
GPUで前処理済みの
データを処理するため、
本来のデータ量よりも
遥かに小さな負荷を
処理するだけで済む。
v2.0

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

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

要素技術② NVMe-SSD
HBStudy#80 - GPUとSSDがPostgreSQLを加速する22
Intel SSD
750 Series
Intel SSD
DC P4600
Samsung
PM1725
HGST
Ultrastar SN260
Seagate
Nytro 5910
Interface PCIe 3.0 x4 PCIe 3.0 x4 PCIe 3.0 x8 PCIe 3.0 x8 PCIe 3.0 x16
Capacity 400GB, 800GB,
1.2TB
2.0TB, 4.0TB 3.2TB, 6.4TB 1.6TB, 3.2TB,
6.4TB
7.7TB
Form Factor HHHL HHHL HHHL HHHL FHHL
Max SeqRead 2.5GB/s 3.2GB/s 6.0GB/s 6.1GB/s 8.0GB/s
Max SeqWrite 1.2GB/s 1.9GB/s 2.0GB/s 2.2GB/s 4.7GB/s
Rand Read 460K IOPS 617K IOPS 1000K IOPS 1200K IOPS 975K IOPS
Rand Write 290K IOPS 225K IOPS 120K IOPS 200K IOPS 130K IOPS
Warranty 5years 5years 5years 5years 5 years
MTBF 1.2M hours 1.0M hours 2.0M hours 2.0M hours 2.0M hours
Target consumer enterprise / data-center
高速SSDの本命として、NVMe規格に対応した製品が各社からリリース

SCAN + JOIN + GROUP BY Combined Kernel (1/3)
Aggregation
GROUP BY
JOIN
SCAN
SELECT cat, count(*), avg(x)
FROM t0 JOIN t1 ON t0.id = t1.id
WHERE y like ‘%abc%’
GROUP BY cat;
count(*), avg(x)
GROUP BY cat
t0 JOIN t1
ON t0.id = t1.id
WHERE y like ‘%abc%’
実行結果
HBStudy#80 - GPUとSSDがPostgreSQLを加速する23
GpuScan
GpuJoin
Agg
+
GpuPreAgg
v2.0
PostgreSQLは集計クエリを何ステップかに分解して実行する。
データ受け渡し
データ受け渡し

SCAN + JOIN + GROUP BY Combined Kernel (2/3)
集約演算まで一気にGPU側で行ってしまう事で、
ロードすべきデータ量を極端に削減する事ができる。
GpuScan
kernel
GpuJoin
kernel
GpuPreAgg
kernel
Agg
(PostgreSQL)
GPU
CPU
Storage
実行
結果
GpuScan + GpuJoin + GpuPreAgg Combined Kernel
data size
= large
data size
= small
HBStudy#80 - GPUとSSDがPostgreSQLを加速する24
v2.0
Data
Blocks

SCAN + JOIN + GROUP BY Combined Kernel (3/3)
HBStudy#80 - GPUとSSDがPostgreSQLを加速する25
10GBのデータをスキャンして、
最終的にCPU側へ書き戻されたのは 1.2kB のみ。
v2.0

ベンチマーク (1/2) – SSBMによるスループット計測
HBStudy#80 - GPUとSSDがPostgreSQLを加速する26
▌典型的なバッチ・レポーティング処理を模した Star Schema Benchmark にて計測
 PostgreSQLの処理速度は 2.1GB/s 程度で頭打ち（SSDを3枚束ねた場合）
 SSD-to-GPUダイレクトSQL実行を用いるPG-Stromの場合、ハードウェア限界に近い
6.2GB/s 近くまで処理性能を引き出せている。
 従来はDWH専用機や小規模クラスタを用いていた水準の能力を１台のマシンで。
SSD x2枚構成の
理論限界値 [4.4GB/s]
SSD x3枚構成の
理論限界値 [6.6GB/s]
v2.0

ベンチマーク (2/2)– SSBMベンチマーク環境
HBStudy#80 - GPUとSSDがPostgreSQLを加速する27
■ クエリ例
SELECT sum(lo_revenue), d_year, p_brand1
FROM lineorder, date1, part, supplier
WHERE lo_orderdate = d_datekey
AND lo_partkey = p_partkey
AND lo_suppkey = s_suppkey
AND p_category = 'MFGR#12‘
AND s_region = 'AMERICA‘
GROUP BY d_year, p_brand1
ORDER BY d_year, p_brand1;
customer
1200万件
(1.6GB)
date1
2500件
(400KB)
part
180万件
(206MB)
supplier
400万件
(528MB)
lineorder
24億件
(351GB)
典型的な Star Schema に JOIN, GROUP BY を含む集計クエリを実行
v2.0
読出し: 2.2GB/s
Intel SSD 750
3840コア搭載
NVIDIA Tesla P40
測定環境
Chassis Supermicro 5018GR-T
CPU Xeon E5-2650v4 (2.2GHz, 12C) x1
RAM 128GB (16GB DDR4-2133 x 8)
GPU NVIDIA Tesla P40 (3840C, 24GB) x1
SSD Intel SSD 750 (HHHL; 400GB) x3
OS
Red Hat Enterprise Linux 7.4
CUDA 9.0 + Latest driver
DB PostgreSQL v9.6 + PG-Strom 2.0devel

〈余談〉GTC2017でSSD-to-GPU機能の発表がTop-5に選出
HBStudy#80 - GPUとSSDがPostgreSQLを加速する28
世界中から集まったGPU関連R&Dの
ポスター発表全138件のうち、
最も評価の高い5件の一つとして選出。
（来場者投票では惜しくも次点…）
GPU Technology Conference 2017
8th~ 11th May, San Jose

〈補足〉PostgreSQLのI/O性能に関する考察
① 小さなブロックサイズによる大量のシステムコール呼び出し
② ブロックレイヤ／ファイルシステムでの複数回のバッファコピー
PostgreSQL
(Shared Buffer)
ファイルシステム
(Page Cache)
ブロックデバイス
(DMA Buffer)
NVMe-SSD
read(2)
DMA要求 DMA完了
memcpy to
Page Cache
memcpy to
Shared Buffer
集計処理集計処理
request to
block read
NVMe-SSDにより
デバイスの遅延は
劇的に改善
バッファ間コピー
システムコール
呼び出し
HBStudy#80 - GPUとSSDがPostgreSQLを加速する29

〈補足〉ハードウェア構成に関する考慮事項
HBStudy#80 - GPUとSSDがPostgreSQLを加速する30
▌マルチGPU環境への対応
 SQLの実行開始時に、スキャンすべきテーブルを保持するSSDに至近のGPUを使う。
 PostgreSQL v10は複数の異なるテーブルを並列スキャンできないため、
マルチGPU環境下でのSSD-to-GPUダイレクトSQL実行は必ずしも効率的ではない。
 PostgreSQL v11の “Parallel Append” 機能を待って対応予定。
① 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の配下に接続されている必要がある

〈補足〉 ディスクキャッシュと一貫性を保つための工夫
HBStudy#80 - GPUとSSDがPostgreSQLを加速する31
 課題 ①対象ブロックがOSキャッシュに保持されている場合、ストレージブロックの内容は
最新でない可能性がある。
②8KB単位のコマ切れDMA（RAMGPU）は非常に性能が悪い
 対策 キャッシュされているブロック(=8KB単位)を一度ユーザ空間のバッファに書き戻し、
その後 CUDA API を用いて、一度に RAMGPU 転送を行う。
✓ 処理ペナルティ的には read(2) + cuMemcpyHtoDAsync() と同等
✓ GPUメモリ上でのブロック並び順が変わるが、処理の妥当性に影響はない。
BLK-100: uncached
BLK-101: cached
BLK-102: uncached
BLK-103: uncached
BLK-104: cached
BLK-105: cached
BLK-106: uncached
BLK-107: uncached
BLK-108: cached
BLK-109: uncached
BLCKSZ
(=8KB)
Transfer Size
Per Request
BLCKSZ *
NChunks
BLK-108: cached
BLK-105: cached
BLK-104: cached
BLK-101: cached
BLK-100: uncached
BLK-102: uncached
BLK-103: uncached
BLK-106: uncached
BLK-107: uncached
BLK-109: uncached
BLK-108: cached
BLK-105: cached
BLK-104: cached
BLK-101: cached
unused SSD-to-GPU
P2P DMA
File Userspace DMA
Buffer (RAM)
Device Memory
(GPU)
CUDA API
(userspace)
cuMemcpyHtoDAsync

想定適用領域

想定適用領域① – ビジネス・インテリジェンス
HBStudy#80 - GPUとSSDがPostgreSQLを加速する33
▌Why PG-Strom?
 SSD-to-GPUダイレクトSQL実行によってハードウェア能力を全て引き出し、
DWH専用機に匹敵する処理能力を1Uスタンドアロンシステムで実現。
 PostgreSQLの豊富な周辺ツールや運用ノウハウを“そのまま”適用できる。
レプリケーション
“ニア”リアルタイム同期
BIツール
業務系システム
集計系クエリ
結果
データの発生・集積 データの集計・サマライズ データの可視化
✓ 集計系クエリ（JOIN/GROUP BYの多用）の高速な実行
✓ 大量のデータに対する高い読み出しスループット
✓ 異種DBを含む業務系システムとの連携
課題）商用DB製品（Oracle DB, SQL Serverなど）の価格体系
集計処理は並列処理に向いているが、CPUコア単位の課金が一般的で、
並列度を上げると同時にライセンス費／保守費が急激に上昇する。

〈参考〉re:dash でPG-Stromに繋いでみた。
HBStudy#80 - GPUとSSDがPostgreSQLを加速する34
PostgreSQLと全く同じように設定、利用する事ができる。

セキュリティ
事故発生
想定適用領域② – ログ解析基盤 【通信分野】
HBStudy#80 - GPUとSSDがPostgreSQLを加速する35
▌ログ集積・解析ＤＢに求められる要件
 普段の負荷は低くても、“いざ” という時には高速な集計・探索処理が必要。
（セキュリティ事故の場合、“翌朝まで” という事も珍しくはない）
 予め検索パターンを予期できないため、インデックスや事前集計無しでも
実用時間で探索が可能な並列処理機能・高スループット
▌Why PG-Strom?
 “プロセッサとストレージの力技” でSQLを処理するため、インデックスや事前
集計の難しい問題であっても、高速に集計・探索処理を実行可能。
 定常時の負荷は高くないため、高価なDB製品の利用は費用対効果の説明が困難。
ゲートウェイサーバ ログ集積・解析ＤＢ
Real Life Log
データの生成
• セキュリティ事故の状況・影響範囲の探索
• 短納期での上位責任者への報告
事故報告レポート
（納期：翌朝）

PG-Strom開発ロードマップ
HBStudy#80 - GPUとSSDがPostgreSQLを加速する36
Development Activity Business Activity
 In-memory Columnar Cache
 時系列データ対応
 NVMe-Stromドライバ改良
 先進ユーザ開拓
 代理店／SIer開拓
 対外発表
2018年1月 PG-Strom 2.0β版リリース
 テスト＆デバッグ
 パッケージング
 ドキュメンテーション
 実ワークロードを用いた実証実験
 サポート体系の整理
2018年3月 PG-Strom 2.0GA版リリース
2018年4月 HeteroServer製品販売開始
 v3.0向け開発サイクル開始
2019年1Q（暫定）PG-Strom 3.0リリース
１月中には新機能追加を凍結。３月末のPG-Strom 2.0GAリリースを目指す。

ハードウェア限界を越えて
～インテリジェント・ストレージ構想～

〈参考〉なぜGPUには列指向のデータが向いているか
HBStudy#80 - GPUとSSDがPostgreSQLを加速する38
▌行データ形式 – 不連続なデータアクセス (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の能力をフルに引き出すには、適切なデータ形式の選択が必要

〈I/O高速化〉In-memory Columnar Cache (1/2)
HBStudy#80 - GPUとSSDがPostgreSQLを加速する39
BlockNum = 101
all_visible=false
BlockNum = 102
all_visible=true
BlockNum = 103
all_visible=true
BlockNum = 104
all_visible=true
列形式
キャッシュ
(BlockNum=102)
列形式
キャッシュ
(BlockNum=102)
background
worker
作成
INSERT
UPDATE
DELETE
invalidation
PG-Strom
行データ
行データ用
GPU Kernel
列データ
列データ用
GPU Kernel
行データ
行データ用
GPU Kernel
列データ
列データ用
GPU Kernel
v2.0
列形式データに変換してキャッシュする事で、データ転送量の削減と
GPU上でのSQL処理実行性能向上を同時に狙う。
被参照列のみGPUへ転送するた
め、
データ転送量は少なくて済む
更新時、当該ブロックのキャッシュを無効化する。
（ストレージへの書込みを伴わない）
GPUメモリバス使用率を
最大化（次項参照）

OLTPの世界 OLAPの世界
Intelligent Storage (1/4) – On-SSD Row-to-Column Converter
HBStudy#80 - GPUとSSDがPostgreSQLを加速する40
SSD上でRow-to-Column変換を行い、Rowで書いてColumnで読む
R/C
変換
ロジック
列データ
解析系データ
読出し
（列形式）
業務データ
書込み
（行データ）
データ形式変換
FPGA等による
H/W実装
SQLクエリ処理
GPU本来の計算能力を
引き出す列データ形式
集計済み、
JOIN済み
データ
列抽出において
必要なデータだけ
取出し

Intelligent Storage (2/4) – On-SSD Row-to-Column Converter
HBStudy#80 - GPUとSSDがPostgreSQLを加速する41
カスタムロジックを搭載可能な NVMe-SSD 製品が
容易に入手可能になりつつある。
Nallatech社
250Sシリーズ
NGD Systems社
Catalina 2 NVMe PCIe SSD
SSD上のロジックは単純で汎用性の高いデータ形式変換に特化
集積度の高いGPUでは、処理内容が都度変化するSQLを“超”並列実行
PostgreSQLデータブロック
カスタムロジック
PageHeader ItemPointers
Record-01Record-02
Record-03Record-04Record-05
Record-06Record-07
Record-08Record-09
列A
列D
列F

Intelligent Storage (3/4) – Edge Query Execution
HBStudy#80 - GPUとSSDがPostgreSQLを加速する42
世の中には PCIe バスを引き延ばして外部I/O拡張Boxに接続する製品がある。
• 直接GPUを装着するのに比べて
省スペース。
• （製品によっては）I/O拡張Box
の内部でP2P DMAを完結できる。

トランザクション制御
（シングルノード）
Intelligent Storage (4/4) – Edge Query Execution
外部PCIe拡張ユニットを用いてSSD/GPUペアを拡張し、
ハードウェア限界を超えたスループットを実現する。
PCIe-Switch
アップリンク・データフロー
PCIe拡張Box内部でのSQL前処理により、
相対的にI/Oサイズは小さくなる。
もはやホストシステム自身の
バス幅は律速要因ではなくなる。 エッジ・データフロー
最大限のスループットで
SSDからGPUへデータを
読み出し、SQL前処理で
データ量を削減するadopter
adopter
adopter
トランザクション制御の世界 大量データ処理の世界
必要に応じて
ユニットの
増設も可能
PostgreSQLから見ると、単に大量のGPUとSSDを
搭載しただけのシングルノード構成。
複雑な分散トランザクションを使用する必要が
ないため、運用をシンプル化できる。
PCIe拡張ユニット内で完結するP2P DMAのトラフィックがアップリンク側に
漏れなければ、スペック及びGPUの処理能力からみて、一台あたり10GB/sの
処理性能は十分に実現可能。
データサイズの増加に伴い、PCIe拡張ユニットを増設する事で対応できる。
HBStudy#80 - GPUとSSDがPostgreSQLを加速する43

PCIeトポロジ最適化とパーティション対応 (1/2)
HBStudy#80 - GPUとSSDがPostgreSQLを加速する44
▌～PostgreSQL v10までの課題
 ある一時点においては、常に特定の１テーブルだけがスキャンの対象
 SSD-to-GPUダイレクトSQL実行を使うには、SSDに近傍のGPUを選択しなければならない。
 複数GPU搭載でも、スキャン中のテーブルを保存するSSDに近傍のGPUだけがアクティブ
となり、リソース有効活用の面で課題があった。
PostgreSQL v10までは、パーティション子テーブルの並列スキャンに非対応
t1
t2
t3
t4
Append
～PostgreSQL v10
t1
t2
t3
t4
Append
PostgreSQL v11以降
※個々の子テーブルの
スキャンが並列化
される事はある パーティション配下の子テーブル
全てを並列にスキャン

PCIeトポロジ最適化とパーティション対応 (2/2)
HBStudy#80 - GPUとSSDがPostgreSQLを加速する45
 ワーカーの並列化に伴い、GPU1/GPU2を同時に利用する事が可能に
 マルチGPU環境においても、計算機資源を有効に活用できることに。
Append
ワーカーの起動時に対象SSDの近傍GPUを選択し、複数GPUを同時利用可能に
t1 t2 t4t3
GPU1 GPU2
BgWorker BgWorker BgWorker BgWorker
CPU並列処理用の
ワーカープロセス
テーブル t1 を保存する
SSDと同一のCPUに接続
されているGPU1を選択
PCIe接続トポロジーに
基づく自動チューニング

計算中心のワークロードに対して
～PL/CUDAとその周辺機能～

PL/CUDAによる統計解析アルゴリズムの実装
HBStudy#80 - GPUとSSDがPostgreSQLを加速する47
 SQLでの記述が難しいアルゴリズムや、自動生成されたGPUプログラムでは困難なレベルの
最適化を実現し、データベースの計算能力を飛躍的に引き上げるアクセラレータ機能
✓ アルゴリズムの “重い部分” だけを集中してチューニングする事が可能
✓ 前処理/後処理にSQLを使用できるため、柔軟なデータ操作が可能
CREATE FUNCTION my_logic(matrix,
matrix)
RETURNS matrix
AS $$
$$ LANGUAGE ‘plcuda’;
ユーザ定義のCUDA(*)コードブロック
(*) CUDA: GPUプログラミング言語・環境のデファクト
スタンダードで、C言語風の構文を持つ。
Storage
GPU Kernel
ユーザ定義の
CUDAコード
ブロック
SQLによる後処理
✓ テーブルJOIN
✓ Window関数
✓ ORDER BY
✓ GROUP BY
✓ etc....
PL/CUDA関数の
引数をGPUへ転送
実行結果の書き戻しとSQLによる加工
PL/CUDA関数の定義
PL/CUDA: PG-Stromの新機能で、高度な統計解析アルゴリズムを
SQL関数として実装し、GPU上での並列実行を可能にする。
アルゴリズムを
GPUで並列実行
一般的なCREATE FUNCTION構文を用いた関数定義
v2.0

検証事例）k-NN法による類似化合物サーチ (1/2)
HBStudy#80 - GPUとSSDがPostgreSQLを加速する48
データベース化合物群
(D; ~1000万件程度)
クエリ化合物群
(Q; ~1000件程度)
類似度による
サーチ
ターゲットたんぱく質
“似た特性の化合物”は
“active”である可能性も高いはず。
学術論文等から
ターゲットたんぱく質に
“active” である化合物を
ピックアップ

検証事例）k-NN法による類似化合物サーチ (2/2)
HBStudy#80 - GPUとSSDがPostgreSQLを加速する49
類似度 = 距離の定義
ID NAME Fingerprint (1024bit)
1 CHEMBL153534 000000000001000000100000000000000100000000000001000000...
2 CHEMBL405398 000000000000000100100000000000000000000000000000100000...
3 CHEMBL503634 000001000000000000000000001000000100000000000000000000...
: : :
化合物のデータ構造
Tanimoto Indexによる類似度の定義：
𝑆𝑖𝑚𝑖𝑙𝑎𝑟𝑖𝑡𝑦 𝐴, 𝐵 = Τ𝐴 𝐹𝑃 ∩ 𝐵 𝐹𝑃 𝐴 𝐹𝑃 ∪ 𝐵 𝐹𝑃

検証事例）k-NN法に必要な計算量
HBStudy#80 - GPUとSSDがPostgreSQLを加速する50
データベース化合物群
(D; 10M件程度)
Q: クエリ化合物群
(~1000件程度)
上位3件の平均
𝑑𝑖 ∈ 𝐷
d 𝑄, 𝑑𝑖 : Q~di間の距離
𝑑𝑗 ∈ 𝐷
上位3件の平均
計算量の目安:
𝑂 𝑄 × 𝐷 + 𝑂 𝐷 × 𝑄𝑙𝑜𝑔𝑄
(距離計算) (ソート+平均値)
d 𝑄, 𝑑𝑗 : Q~dj間の距離

検証事例）PL/CUDA関数の呼び出し例
HBStudy#80 - GPUとSSDがPostgreSQLを加速する51
SELECT row_number() OVER (),
float4_as_int4(R.key_id) key_id,
R.score
FROM matrix_unnest(
(SELECT my_plcuda_function(A.matrix,
B.matrix)
FROM (SELECT cbind(array_matrix(id),
array_matrix(x, y, z)) matrix
FROM normal_table
WHERE tag LIKE ‘%abc%’) A,
(SELECT matrix
FROM matrix_table) B
)
) AS R(key_id real, score real)
ORDER BY score DESC
LIMIT 1000;
2つのMatrix-like Arrayを
引数に持つ
PL/CUDA関数の呼出し
Matrix-like Arrayの生成、
または構築済みのものをロード
Matrix-like Arrayを
N個のレコードに再展開
SQLによる後処理
(JOIN, Window関数)

検証事例）PL/CUDAによるパフォーマンス改善
HBStudy#80 - GPUとSSDがPostgreSQLを加速する52
 CPU版は、同等のロジックをC言語によるバイナリ版で実装して比較計測
 D化合物群の数は1000万レコード、Q化合物群の数は10,50,100,500,1000個の5通り
 最大で100億通りの組合せを計算。これは実際の創薬ワークロードの規模と同等。
 HW) CPU: Xeon E5-2670v3, GPU: GTX980 / GTX1080, RAM:384GB
 SW) CentOS7, CUDA8.0, PostgreSQL v9.5 + PG-Strom v1.0
30.25
145.29
295.95
1503.31
3034.94
12.97 13.46 13.90 18.16 24.6513.00 13.23 13.59 16.01 19.13
0
500
1000
1500
2000
2500
3000
3500
10 50 100 500 1000
QueryResponseTime[sec]
(*Lowerisbetter)
クエリ化合物群の数[Q]
k-NN法による類似化合物サーチ応答時間 (k=3, D=10M)
CPU(E5-2670v3) GTX980 GTX1080
x150 times
faster!

他の検証事例 – 教師なし学習アルゴリズム
HBStudy#80 - GPUとSSDがPostgreSQLを加速する53
1350万件の交通量データを
GPU版 k-means 法によって
クラスタリング処理
デンマーク・オーフス市(Arhus, Denmark)にお
ける
449観測点のオープンデータを使用。
(2014年2月～6月; 13.5M records)
統計解析アルゴリズムの
代表的なin-database実装である
MADLibとの比較で、
200倍以上の高速化を実現。
仮説に対して、リアルタイムで
トライ＆エラーを繰り返す事が
可能に。
v2.0

想定適用領域④ – アノマリー検知 【金融分野】
HBStudy#80 - GPUとSSDがPostgreSQLを加速する54
▌背景と課題
 金融系の決済データはほぼ間違いなくRDBMSで保存・管理されている。
 異常検知を実行するために、DBからデータをエクスポートするのは大変な負荷。
▌なぜ HeteroServer を適用するのか
 PL/CUDA統計解析関数を用いて、In-databaseかつ高速に異常検知ロジックを実行
できる。外部へデータをエクスポートする必要がなくなる。
 異常検知の間隔を短くできれば、不正利用が発生して即座にクレジットカードを
利用停止にできるため、被害額を最小限に抑える事ができる。
DBサーバ
クレジットカード
不正利用
決済サーバ
In-databaseかつ
リアルタイムに
異常検知ロジックを実行
クレジットカード決済
データの
エクスポート
従来の手法
外部プログラムで異常検知
ロジックを定期的に実行
私たちの提案
いつもと違う！？
トランザクション
In-database処理で
この部分が不要に
クレジットカードや振り込め詐欺の検知をより短いサイクルで実行する

（かつての）課題
HBStudy#80 - GPUとSSDがPostgreSQLを加速する55
▌引数セットアップのコストが高すぎる
▌PostgreSQL可変長データ形式の制限
 先頭30bitで可変長データの長さを表現  最大で1GB
 他のフィールドは「圧縮の有無(1bit)」「Short形式かどうか(1bit)」
12.97 13.46 13.90
18.16
24.65
13.00 13.23 13.59
16.01
19.13
0
5
10
15
20
25
30
10 50 100 500 1000
QueryResponseTime[sec]
(*Lowerisbetter)
クエリ化合物群の数[Q]
k-NN法による類似化合物サーチ応答時間 (k=3, D=10M)
CPU(E5-2670v3) GTX980 GTX1080

Storage
ホスト側
共有バッファ
gstore_fdw – SQLによるGPUメモリの読み書き
HBStudy#80 - GPUとSSDがPostgreSQLを加速する56
▌gstore_fdw: PostgreSQLの外部表（Foreign Table）の仕組みを用いる事で、
SQLのSELECT/INSERTによってGPU上のメモリ領域の読み書きを行う。
 母集団の選択や前処理・後処理を、SQLで柔軟かつ簡潔に記述できる。
 GPUメモリ領域を他のプログラムと共有する事が可能で、RやPython用の豊富な統計解析・
機械学習ライブラリとゼロコピーでデータ連携が可能。
 PL/CUDA関数においても引数の受け渡し時間を“ほぼゼロ”に。
Foreign Table
(gstore_fdw)
GPU device memoryINSERTSELECT
IPC Handle
IPC Handle
Device Memory Exporting:
GPUメモリ領域の識別子を用いて、
他のプログラムと当該領域を共有。
ゼロコピーでのデータ参照が可能
に。
User written
Scripts
v2.0
SQLを用いたGPUメモリへの
データロードが可能に。

統計解析・機械学習とデータマネジメントの統合
HBStudy#80 - GPUとSSDがPostgreSQLを加速する57
gstore_fdw
サマリー
前処理・後処理Device Memory
Exporting
v2.0
データの散逸を防ぐと同時に、高速なTry&Errorサイクルを回転させる。
ローカルでの
統計解析・機械学習
環境とのデータ連携
postgres_fdw
リモートDBと接続し、ダイレクトにデータを取り
込む機能。条件評価や集計をリモート側で実行で
きるため、データ転送の負荷が小さい。
データサイエンティスト
データレイクから必要なデータを取り
込み、PG-Strom (gstore_fdw) を用いて
データをロード。RやPythonと連携し
て統計解析・機械学習処理を実行。
データレイク／
データウェアハウス