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

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

HeteroDB,Incチーフアーキテクト兼代表取締役社長

海外浩平 <[email protected]>

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統計解析・機械学習

QueryOptimizer

QueryExecutor

PG-StromExtension

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_tableWHERE 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

StorageManager

TransactionManager

IPC(Lock, Latch,

shmem)

SQLクエリ

パース木

クエリ実行計画

クエリ実行結果 SQL構文を分解し、取り扱いやすい

内部データ形式（パース木）に変換

文法エラーの検出

統計情報を元にコスト値を算出

最も合理的と予想される実行計画を作成する。

クエリ実行計画に基づいて、ScanやJoin、Sortなどを実行する。

PostgreSQL内部のインフラを使用


PostgreSQLはどのように実行計画を作るか (1/2)

Scant0 Scan

t1

Scant2

Joint0,t1

Join(t0,t1),t2

GROUP BY cat

ORDERBY score

LIMIT100


PostgreSQLはどのように実行計画を作るか (2/2)

Scant0 Scan

t1

Joint0,t1

統計情報）nrows: 120万行

width: 80インデックス：なし

候補パス

HashJoincost=4000

候補パス

MergeJoincost=12000

候補パス

NestLoopcost=99999

候補パス

ParallelHash Joincost=3000

候補パス

GpuJoincost=2500

WINNER!

PostgreSQLビルトインの実行パス拡張モジュールによる提案（PostgreSQL v9.5以降）

（PostgreSQL v9.6以降）

GpuJoint0,t1

統計情報）nrows: 4000行

width: 120インデックス：id列

複数の処理アルゴリズムを競わせ、“コスト値”で評価


CustomScanによる介入

同じ結果を返しさえすれば、手段は問わない。

CustomScan (GpuJoin)

(*BeginCustomScan)(...)

(*ExecCustomScan)(...)

(*EndCustomScan)(...)

:

SeqScanon t0

SeqScanon t1

GroupAggkey: 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コンパイラ

ParallelExecution

簡単なマイクロベンチマーク


▌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

Qu

ery

Res

po

nse

Tim

e [s

ec]

Number of tables joined

PG-Strom microbenchmark with JOIN/GROUP BY

PostgreSQL v9.6 PG-Strom 2.0devel

CPU: Xeon E5-2650v4GPU: Tesla P40RAM: 128GBOS: CentOS 7.3DB: 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 InfinibandHBA

PCIeデバイス

GPUDirect RDMAGPUデバイスメモリを物理アドレス空間にマップする機能

『GPUデバイスメモリの物理アドレス』が存在すれば、PCIeデバイスとのDMAで、Source/Destinationアドレスとして指定できる。


0xf0000000

0xe0000000

DMA要求

SRC: 1200th sectorLEN: 40 sectorsDST: 0xe0200000

要素技術② NVMe-SSD


Intel SSD750 Series

Intel SSD P3608SamsungPM1725

HGSTUltrastar SN260

SeagateNytro 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.3CUDA 8.0 + nvidia driver 375.51NVMe-Strom driver

DB: PostgreSQL 9.6.4PG-Strom v2.0devel

Data: Star Schema Benchmark(SF=401, 351GB)

HGST社製

UltrastarSN260

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

Qu

ery

Exec

uti

on

Th

rou

ghp

ut

[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

Sto

rage

Re

ad T

hro

ugh

pu

t [M

B/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_wrtnsda 6.00 0.19 0.00 0 0sdb 0.00 0.00 0.00 0 0sdc 0.00 0.00 0.00 0 0nvme0n1 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 toPage Cache

memcpy toShared Buffer

集計処理集計処理

request toblock read

NVMe-SSDによりデバイスの遅延は劇的に改善

バッファ間コピーシステムコール呼び出し


NVMe-Strom ソフトウェアスタック


pg-strom

NVMe-Stromdriver

VFS(ext4/xfs)

Page Cache

NVMe SSDDriver

nvidiadriver

GPUdevice

memory

PostgreSQL

cuMemAlloc()

/proc/nvme-strom

read(2)

UserSpace

KernelSpace



pg-strom

NVMe-Stromdriver

VFS(ext4/xfs)

Page Cache

NVMe SSDDriver

nvidiadriver

GPUdevice

memoryGPU

devicememory

PostgreSQL

cuMemAlloc()

/proc/nvme-strom

ioctl(2)read(2)

UserSpace

KernelSpace



pg-strom

NVMe-Stromdriver

VFS(ext4/xfs)

Page Cache

NVMe SSDDriver

nvidiadriver

GPUdevice

memoryGPU

devicememory

PostgreSQL

DMArequest

File offset?

SSD-to-GPU Peer-to-Peer DMA

cuMemAlloc()

/proc/nvme-strom

ioctl(2)read(2)

UserSpace

KernelSpace

Exists?

Block Number

【補足】ディスクキャッシュと一貫性を保つための工夫


課題 ①対象ブロックがOSキャッシュに保持されている場合、ストレージブロックの内容は最新でない可能性がある。②8KB単位のコマ切れDMA（RAMGPU）は非常に性能が悪い

対策キャッシュされているブロック(=8KB単位)を一度ユーザ空間のバッファに書き戻し、その後 CUDA APIを用いて、一度に RAMGPU転送を行う。

✓ 処理ペナルティ的には 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-GPUP2P 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 20178th~ 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)

AggregationGROUP BY

JOIN

SCAN

SELECT cat, count(*), avg(x)FROM t0 JOIN t1 ON t0.id = t1.idWHERE y like ‘%abc%’GROUP BY cat;

count(*), avg(x)GROUP BY cat

t0 JOIN t1ON t0.id = t1.id

WHERE y like ‘%abc%’

実行結果


GpuScan

GpuJoin

Agg+

GpuPreAgg


GpuScankernel

GpuJoinkernel

GpuPreAggkernel

DMABuffer

Agg(PostgreSQL)

GPU

CPU

Storage

単純にロジックを置き換えるだけでは、CPU<->GPU間のデータ転送のピンポンが発生してしまう。

DMABuffer

DMABuffer

実行結果



構造の単純なWHERE句評価は、既にJOINと同じタイミングで実行するようになっている。

GpuScankernel

GpuJoinkernel

GpuPreAggkernel

DMABuffer

Agg(PostgreSQL)

GPU

CPU

Storage

DMABuffer

実行結果

GpuScan + GpuJoin



集約演算まで一気にGPU側で行ってしまう事で、ロードすべきデータ量を極端に削減する事ができる。

GpuScankernel

GpuJoinkernel

GpuPreAggkernel

DMABuffer

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 DMAWHERE句

JOIN

GROUP BYPostgreSQLデータブロック

行データ列データ変換

必要なデータのみを抽出する事で、PCIeバスの帯域以上の実効データ転送

GPUでの“超”並列SQL実行

入力データのフォーマットを列形式とする事で、最大限のGPU性能を発揮

行データとして書込み

トランザクション性能に影響を与えず、リアルタイム集計・分析を可能に

THANK YOU!contacts

e-mail: [email protected]: @kkaigai

Engineering

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