GPUとSSDがPostgreSQLを加速する～クエリ処理スループット10GB/sへの挑戦～ [DB Tech Showcase Tokyo/2017]

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

HeteroDB社について
▌会社プロフィール
 商号：ヘテロＤＢ株式会社
 所在地：東京都品川区西大井１ー１ー２
 設立： 2017年7月4日(火)
 事業内容： GPU/SSDによる高速SQLデータベース製品の開発・販売
GPU等の活用を含むSQLチューニングサービス
 主要株主：設立メンバーによる100%保有
▌設立メンバー
海外浩平（チーフアーキテクト兼代表取締役社長）
OSS開発者コミュニティにおいて、Linux kernelやPostgreSQLデータベースの開発に10年以上従事。
PostgreSQLのSELinux対応やFDW機能拡張などコア機能強化に貢献しており、PostgreSQLのMajor Contributor
として知られている。
2012年、 GPUによるPostgreSQLの高速化機構であるPG-Stromの開発に着手。以降、ヘテロジニアスコン
ピューティング技術を用いたSQL処理の並列化・高速化技術の開発に注力し、現在に至る。
2007年 IPA未踏ソフトウェア創造事業において「天才プログラマ・スーパークリエータ」受賞、2014年
日本OSS推進フォーラムより「OSS貢献者賞」受賞
柏木岳彦（チーフセールスエンジニア兼取締役副社長）
NEC中央研究所において、スケールアウトインメモリデータベース、GPGPUをアクセラレータとするイン
メモリカラムストアデータベースの研究に従事。また、NEC在職中は海外と共にPG-Stromプロジェクトの
一員としてユーザ開拓にあたる。
2015年にパラレルネットワーク合同会社を設立。ネットワーク製品・サービスの企画開発を行うと共に、
ヘテロDB社ではマーケティング、ユーザ開拓を担当。
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-2

コア技術 – PG-Strom
▌特長
 GPUの計算能力を活かして、
SQLワークロードをオフロード。
数千並列処理による高速化。
 SQLからGPUプログラムを
自動生成し実行時コンパイル。
透過的な高速化を実現。
 オープンソースソフトウェア。
▌機能
 WHERE句、JOIN、GROUP BYの
GPU並列処理に対応
 ユーザ定義CUDA関数(PL/CUDA)
▌用途
 バッチ処理、集計・レポート
 In-database統計解析・機械学習
Query
Optimizer
Query
Executor
PG-Strom
Extension
Storage Manager
SQL Parser
Application
Storage
PG-Strom: GPUを用いたPostgreSQL高速化拡張モジュール
共通のSQLクエリ
共通のデータ形式

GPUの特徴
数千コアの処理能力と数百GB/sのメモリ帯域を
ワンチップに実装した並列演算プロセッサ
CPU
小回りが利くが輸送力は小さな
乗用車のようなプロセッサ
GPU
乗り降りは少し手間だが、大量輸送が
可能な高速鉄道のようなプロセッサ
モデル Intel Xeon E5-2699v4 NVIDIA Tesla P40
トランジスタ数 7.2billion 12billion
コア数 22 (functional) 3840 (simple)
理論性能 (FP32) 1.2 TFLOPS (with AVX2) 12TFLOPS
メモリ容量 max 1.5TB (DDR4) 24GB (GDDR5)
メモリ帯域 76.8GB/s 347GB/s
TDP 145W 250W

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;
集約関数の計算で用いる仕組み

画像データ処理はSQL処理に似ている？
画像データ =
int/float[]型配列
転置
ID X Y Z
SELECT * FROM my_table
WHERE X BETWEEN 40 AND 60
並列処理
GPUの得意分野：同一の演算を大量のデータに対して適用する

PG-Stromが解決しようとする問題
RAM
データ
(small)  プリミティブなPG-Strom
✓ ヘビーSQL（JOIN、GROUP BY）
✓ データサイズはRAMに載る程度
2015年

RAM
データ
(small)
データ
(large)
より計算集約的な
ワークロードへ
よりI/O集約的な
 PL/CUDA
✓ In-database統計解析・機械学習
✓ 創薬、アノマリー検知
 SSD-to-GPU ダイレクトSQL実行
✓ H/W限界までI/Oを高速化
✓ 大規模バッチ処理、レポーティング
 プリミティブなPG-Strom
✓ ヘビーSQL（JOIN、GROUP BY）
✓ データサイズはRAMに載る程度
2017年

DB tech showcase での登壇は二回目です
DBTS2014: GPGPUがPostgreSQLを加速する
DBTS2017: GPUと SSD がPostgreSQLを加速する
DB tech showcase 2014
適用領域の拡大とともに、新たなデバイスを活用する事に

PG-Stromのアーキテクチャ

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

PostgreSQLはどのように実行計画を作るか (1/2)
Scan
t0 Scan
t1
Scan
t2
Join
t0,t1
Join
(t0,t1),t2
GROUP
BY cat
ORDER
BY score
LIMIT
100

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列
複数の処理アルゴリズムを競わせ、“コスト値”で評価

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

簡単なマイクロベンチマーク
▌Test Query:
SELECT cat, count(*), avg(x)
FROM t0 NATURAL JOIN t1 [NATURAL JOIN t2 ...]
GROUP BY cat;
✓ t0 contains 100M rows, t1...t8 contains 100K rows (like a star schema)
8.48
13.23
18.28
23.42
28.88
34.50
40.77
47.16
5.00 5.46 5.91 6.45 7.17 8.07
9.22 10.21
0.0
5.0
10.0
15.0
20.0
25.0
30.0
35.0
40.0
45.0
50.0
2 3 4 5 6 7 8 9
QueryResponseTime[sec]
Number of tables joined
PG-Strom microbenchmark with JOIN/GROUP BY
PostgreSQL v9.6 PG-Strom 2.0devel
CPU: Xeon E5-2650v4
GPU: Tesla P40
RAM: 128GB
OS: CentOS 7.3
DB: PostgreSQL 9.6.2 +
PG-Strom 2.0devel

RAM
データ
(small)
データ
(large)
より計算集約的な
よりI/O集約的な
どのようにして
この領域へ踏み出すか？

～GPUの役割を再定義する～
SSD-to-GPU Direct SQL Execution

SSD-to-GPUダイレクトSQL実行
Large PostgreSQL Tables
PCIe Bus
NVMe SSD GPUSSD-to-GPU P2P DMA
(NVMe-Stromドライバ)
WHERE句
JOIN
GROUP BYPostgreSQL
データブロック
SQLに従ってレコードを
前処理する事で、
CPUがロード/処理すべき
データ量を削減する。
従来のデータフロー
（I/Oサイズ ... 大）
SSDから直接GPUにデータを転送し、GPUでSQLワークロードを処理。
CPU/RAMへのロード前にデータを減らし、見かけ上I/O負荷を削減。

要素技術① 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-SSD
Intel SSD
750 Series
Intel SSD P3608
Samsung
PM1725
HGST
Ultrastar SN260
Seagate
Nytro XP7200
Interface PCIe 3.0 x4 PCIe 3.0 x8 PCIe 3.0 x8 PCIe 3.0 x8 PCIe 3.0 x16
Capacity 400GB, 800GB,
1.2TB
1.6TB, 3.2TB,
4.0TB
3.2TB, 6.4TB 1.6TB, 3.2TB,
6.4TB
3.8TB, 7.7TB
Form Factor HHHL HHHL HHHL HHHL FHHL
Max SeqRead 2.5GB/s 5.0GB/s 6.0GB/s 6.1GB/s 10.0GB/s
Max SeqWrite 1.2GB/s 3.0GB/s 2.0GB/s 2.2GB/s 3.6GB/s
Rand Read 460K IOPS 850K IOPS 1000K IOPS 1200K IOPS 940K IOPS
Rand Write 290K IOPS 50K IOPS 120K IOPS 200K IOPS 160K IOPS
Warranty 5years 5years 5years 5years 5 years
MTBF 1.2M hours 1.0M hours 2.0M hours 2.0M hours 2.0M hours
Target consumer enterprise / data-center
高速SSDの本命として、NVMe規格に対応した製品が各社からリリース

ベンチマーク環境 (1/2)
 Server: Supermicro 5018GR-T
 CPU: Intel Xeon 2650v4 x1
 RAM: 128GB (16GB ECC DDR4-2166 x8)
 GPU: NVIDIA Tesla P40
 SSD: HGST SN260 (7.68TB)
 HDD: SATA 1TB + 3TB x2
 OS: CentOS 7.3
CUDA 8.0 + nvidia driver 375.51
NVMe-Strom driver
 DB: PostgreSQL 9.6.4
PG-Strom v2.0devel
 Data: Star Schema Benchmark
(SF=401, 351GB)
HGST社製
Ultrastar
SN260
NVIDIA社製
Tesla P40

ベンチマーク環境 (2/2) – キーデバイス
model HGST Ultrastar SN260
Interface PCIe 3.0 x8 (NVMe 1.2)
Capacity 7.68TB
Form Factor HHHL
Sequential Read 6,170MB/s
Sequential Write 2,200MB/s
Random Read 1200K IOPS
Random Write 75K IOPS
model NVIDIA Tesla P40
GPU Architecture NVIDIA Pascal
Interface PCIe 3.0 x16
Form Factor FHFL, Dual-Slot
# of CUDA cores 3840
Performance (FP32) 12 TFLOPS
GPU Memory 24GB (GDDR5)
GPU Memory Band 346GB/s
TDP 250W
SPECIAL THANKS FOR: SPECIAL THANKS FOR:

ベンチマーク結果 (1/2)
 351GBのlineorderテーブルに対し、下記のクエリQ1～Q4をそれぞれ実行。
（351 * 1024）/（クエリ応答時間）を処理スループットとして定義。
Q1... SELECT count(*) FROM lineorder;
Q2... SELECT count(*),sum(lo_revenue),sum(lo_supplycost) FROM lineorder;
Q3... SELECT count(*) FROM lineorder GROUP BY lo_orderpriority;
Q4... SELECT count(*),sum(lo_revenue),sum(lo_supplycost)
FROM lineorder GROUP BY lo_shipmode;
※ PostgreSQL v9.6のCPU並列度は24を指定、PG-Strom v2.0develのCPU並列度は4を指定。
889.05 859.31 875.69 842.04
5988.0 5989.9 5988.8 5979.6
0
1000
2000
3000
4000
5000
6000
Q1 Q2 Q3 Q4
QueryExecutionThroughput[MB/s]
PostgreSQL v9.6 + SN260 PG-Strom v2.0 + SN260

ベンチマーク結果 (2/2)
 物理メモリ 128GB のマシンで351GBのテーブルを全件スキャンしている事から、
ワークロードの律速要因はストレージ。
 PG-Stromの場合、SSDのカタログスペックに近い読出し速度を達成できている。
 PostgreSQLの場合、I/Oに伴うオーバーヘッドが大きい。
0
1000
2000
3000
4000
5000
6000
7000
0 100 200 300 400
StorageReadThroughput[MB/s]
Elapsed Time for Query Execution [sec]
Time Series Results (Q4) with iostat
PG-Strom v2.0devel + SN260 PostgreSQL v9.6 + SN260
[kaigai@saba ~]$ iostat -cdm 1
:
Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 6.00 0.19 0.00 0 0
sdb 0.00 0.00 0.00 0 0
sdc 0.00 0.00 0.00 0 0
nvme0n1 24059.00 5928.41 0.00 5928 0
:

ハードウェア構成に関する考慮事項
① PCIeスイッチを介して
SSDとGPUが接続の場合
OK
② CPUがPCIeバスを管理し、
SSDにGPU直接接続の場合
Workable
③ SSDとGPUが互いに異なる
CPUに接続の場合
Not Supported
CPU CPU
PLX
SSD GPU
PCIeスイッチ
この接続トポロジは HeteroDB 環境で検証済
み。
転送レート～9.5GB/sまでは記録した実績あ
り。
（CPUはXeon E5-2650 v4）
非常に遅い。数十～数百MB/s程度の
転送レートしか出ないので、避けな
ければならない。
CPU CPU
SSD GPU
CPU CPU
SSD GPU
QPI
Pros:
対応HWが入手しやすい
Cons:
最大スループットが
PLXよりも低い
Pros:
最大限のスループットを
発揮できる（らしい）
Cons:
対応HWが限られる。
Pros:
なし
Cons:
遅い or 動かない

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により
デバイスの遅延は
劇的に改善
バッファ間コピー
システムコール
呼び出し

NVMe-Strom ソフトウェアスタック
pg-strom
NVMe-Strom
driver
VFS
(ext4/xfs)
Page Cache
NVMe SSD
Driver
nvidia
driver
GPU
device
memory
PostgreSQL
cuMemAlloc()
/proc/nvme-strom
read(2)
User
Space
Kernel
Space

pg-strom
NVMe-Strom
driver
VFS
(ext4/xfs)
Page Cache
NVMe SSD
Driver
nvidia
driver
GPU
device
memory
GPU
device
memory
PostgreSQL
cuMemAlloc()
/proc/nvme-strom
ioctl(2)
read(2)
User
Space
Kernel
Space

pg-strom
NVMe-Strom
driver
VFS
(ext4/xfs)
Page Cache
NVMe SSD
Driver
nvidia
driver
GPU
device
memory
GPU
device
memory
PostgreSQL
DMA
request
File offset?
SSD-to-GPU Peer-to-Peer DMA
cuMemAlloc()
/proc/nvme-strom
ioctl(2)
read(2)
User
Space
Kernel
Space
Exists?
Block Number

【補足】ディスクキャッシュと一貫性を保つための工夫
 課題 ①対象ブロックが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

クエリ処理スループット10GB/sへの挑戦

なぜシングルノード 10GB/s を目指すのか？
そこに山があるからではない。

なぜシングルノード 10GB/s を目指すのか？
一世代前のDWH専用機
処理性能：8.6GB/s
お値段：数千万円～
システム更新時期
さて、後継システムは？
小規模なHadoopクラスタ
運用：複数台サーバの
管理はそれなりに面倒
シングルノードかつ
SQLで同等性能が可能なら？
 集計・解析系はGPU/SSDにより強化
前世代のDWH専用機に匹敵する処理能力
 1/10の製品価格
 DBMSとしての基本機能は、長年にわたる
実績を有する PostgreSQL そのもの。
 バックアップ、レプリケーション、
各種ドライバ、周辺ツール類
HeteroServer 120GS
(2018年3月リリース予定)

(与太話) GTC2017 – SSD-to-GPU機能がTop-5ポスターに選出
世界中から集まったGPU関連R&Dの
ポスター発表全138件のうち、
最も評価の高い5件の一つとして選出。
（来場者投票では惜しくも次点…）
GPU Technology Conference 2017
8th~ 11th May, San Jose
5月時点では、SSD x3枚構成
理論値6.6GB/sに対して
実測性能は4.5GB/s。なぜか？

プロファイラを使って詳しく見てみる。
Dynamic Parallelismを使って起動した
GPUサブカーネルの消費時間が
異常に少ない（= 10%程度）

プロファイラを使って詳しく見てみる。
GPUサブカーネルの同期のために、
本来のSQL処理を行うGPUカーネルの
多重度が非常に低くなっていた。

GPU内の同期ポイント削減の効果
GPU使用率に余裕が出てきた。
 再びストレージ律速に。10GB/sは十分耐えられそう。

10GB/sのクエリ処理スループットを実現するために
▌GPUカーネル同期ポイントの削減
 GpuScan, GpuPreAgg は既に対応完了
 GpuJoin の対応作業が進行中
▌GPUタスクスケジューラの改善
 Dynamic Parallelismの不使用と、Unified Memoryの利用により、
GPU関連処理を（別プロセスの）GPUサーバで実行せずに済む。
▌GpuScan + GpuJoin + GpuPreAgg Combined Kernel
 典型的な集計処理を実行する際にCPUを介在させない。
 スキャンが完了した時点で、既にJOIN/GROUP BYが完了している。
▌md-raid0 (ストライピング) の最適化
 複数枚のNVMe-SSDを束ねる事で、
GPUへ10GB/sのバンド幅でデータを供給する。

GpuScan + GpuJoin + GpuPreAgg Combined Kernel (1/5)
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

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

構造の単純なWHERE句評価は、既にJOINと同じタイミングで
実行するようになっている。
GpuScan
kernel
GpuJoin
kernel
GpuPreAgg
kernel
DMA
Buffer
Agg
(PostgreSQL)
GPU
CPU
Storage
DMA
Buffer
実行
結果
GpuScan + GpuJoin

集約演算まで一気にGPU側で行ってしまう事で、
ロードすべきデータ量を極端に削減する事ができる。
GpuScan
kernel
GpuJoin
kernel
GpuPreAgg
kernel
DMA
Buffer
Agg
(PostgreSQL)
GPU
CPU
Storage
実行
結果
GpuScan + GpuJoin + GpuPreAgg Combined Kernel
data size
= large
data size
= small

10GBのデータをスキャンして、
最終的にCPU側へ書き戻されたのは 1.2kB のみ。

PG-Strom v2.0 へ向けて
Dec-2017, PG-Strom v2.0 beta
Mar-2018, PG-Strom v2.0 GA
HeteroServer 120GS
新機能の開発
 SSD-to-GPUダイレクトSQL実行周辺機能強化
 GPUタスクスケジューラ改良
 On-GPUデータストア（Foreign Table）
 列指向キャッシュ
 In-database統計解析・機械学習ライブラリ
 テスト・品質安定化
 パッケージング
 ドキュメンテーション
先進ユーザの開拓
Open Source Activity Business Activity

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

OLTPの世界 OLAPの世界
インテリジェント・ストレージ構想 (1/2)
SSD上でRow-to-Column変換により、Rowで書いてColumnで読む
R/C
変換
ロジック
列データ
解析系データ
読出し
（列形式）
業務データ
書込み
（行データ）
データ形式変換
FPGA等による
H/W実装
SQLクエリ処理
GPU本来の計算能力を
引き出す列データ形式
集計済み、
JOIN済み
データ
列抽出において
必要なデータだけ
取出し

なぜ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の能力をフルに引き出すには、適切なデータ形式の選択が必要

インテリジェント・ストレージ構想 (2/2)
Large PostgreSQL Tables
PCIe Bus
“SQL-aware”
NVMe SSD GPU
SSD-to-GPU P2P DMA
WHERE句
JOIN
GROUP BYPostgreSQL
データブロック
行データ列データ変換
必要なデータのみを抽出する事で、
PCIeバスの帯域以上の実効データ転送
GPUでの“超”並列SQL実行
入力データのフォーマットを列形式と
する事で、最大限のGPU性能を発揮
行データとして書込み
トランザクション性能に
影響を与えず、リアル
タイム集計・分析を可能に

THANK YOU!
contacts
e-mail: kaigai@heterodb.com
tw: @kkaigai

GPUとSSDがPostgreSQLを加速する～クエリ処理スループット10GB/sへの挑戦～ [DB Tech Showcase Tokyo/2017]

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (10)

Similar to GPUとSSDがPostgreSQLを加速する～クエリ処理スループット10GB/sへの挑戦～ [DB Tech Showcase Tokyo/2017]

Similar to GPUとSSDがPostgreSQLを加速する～クエリ処理スループット10GB/sへの挑戦～ [DB Tech Showcase Tokyo/2017] (20)

More from Kohei KaiGai

More from Kohei KaiGai (20)

GPUとSSDがPostgreSQLを加速する～クエリ処理スループット10GB/sへの挑戦～ [DB Tech Showcase Tokyo/2017]