Weitere ähnliche Inhalte Ähnlich wie GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017] (20) Mehr von Kohei KaiGai (20) GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]2. HeteroDB社について
▌会社プロフィール
商号: ヘテロDB株式会社
所在地: 東京都品川区西大井1ー1ー2
設立: 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
3. コア技術 – PG-Strom
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-3
▌特長
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クエリ
共通のデータ形式
5. 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;
集約関数の計算で用いる仕組み
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-5
9. DB tech showcase での登壇は二回目です
DBTS2014: GPGPUがPostgreSQLを加速する
DBTS2017: GPUと SSD がPostgreSQLを加速する
DB tech showcase 2014
適用領域の拡大とともに、新たなデバイスを活用する事に
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-9
11. PostgreSQLの内部構造
SQL Parser
Query Optimizer
Query Executor
Storage
Manager
Transaction
Manager
IPC
(Lock, Latch,
shmem)
SQLクエリ
パース木
クエリ実行計画
クエリ
実行結果 SQL構文を分解し、取り扱いやすい
内部データ形式(パース木)に変換
文法エラーの検出
統計情報を元にコスト値を算出
最も合理的と予想される実行計画を
作成する。
クエリ実行計画に基づいて、
ScanやJoin、Sortなどを実行する。
PostgreSQL内部のインフラを使用
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-11
13. 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列
複数の処理アルゴリズムを競わせ、“コスト値”で評価
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-13
15. SQLからGPUコードを自動生成(WHERE句の例)
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-15
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
16. 簡単なマイクロベンチマーク
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-16
▌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
19. SSD-to-GPUダイレクトSQL実行
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-19
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負荷を削減。
20. 要素技術① GPUDirect RDMA (1/2)
▌CPUを介さず、GPU他のPCIeデバイス間のP2Pデータ転送を行う機能
元々は、マルチノード環境でInfinibandを介したGPU間のデータ転送効率化技術
Linux kernelドライバを作成する事で、他の PCIe デバイスにも対応可能
Copyright (c) NVIDIA corporation, 2015
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-20
21. 要素技術① GPUDirect RDMA (2/2)
物理アドレス空間
PCIe BAR1領域
GPU
デバイス
メモリ
RAM
NVMe-SSD Infiniband
HBA
PCIe デバイス
GPUDirect RDMA
GPUデバイスメモリを
物理アドレス空間に
マップする機能
『GPUデバイスメモリの物理アドレス』が
存在すれば、PCIeデバイスとのDMAで、
Source/Destinationアドレスとして指定でき
る。
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-21
0xf0000000
0xe0000000
DMA要求
SRC: 1200th sector
LEN: 40 sectors
DST: 0xe0200000
22. 要素技術② NVMe-SSD
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-22
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規格に対応した製品が各社からリリース
23. ベンチマーク環境 (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
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-23
24. ベンチマーク環境 (2/2) – キーデバイス
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-24
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:
25. ベンチマーク結果 (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
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-25
26. ベンチマーク結果 (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
:
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-26
27. ハードウェア構成に関する考慮事項
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-27
① 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 動かない
29. NVMe-Strom ソフトウェアスタック
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-29
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
30. NVMe-Strom ソフトウェアスタック
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-30
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
31. NVMe-Strom ソフトウェアスタック
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-31
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
32. 【補足】 ディスクキャッシュと一貫性を保つための工夫
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-32
課題 ①対象ブロックが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-GPU
P2P DMA
File Userspace DMA
Buffer (RAM)
Device Memory
(GPU)
CUDA API
(userspace)
cuMemcpyHtoDAsync
36. (与太話) GTC2017 – SSD-to-GPU機能がTop-5ポスターに選出
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-36
世界中から集まったGPU関連R&Dの
ポスター発表全138件のうち、
最も評価の高い5件の一つとして選出。
(来場者投票では惜しくも次点…)
GPU Technology Conference 2017
8th~ 11th May, San Jose
5月時点では、SSD x3枚構成
理論値6.6GB/sに対して
実測性能は4.5GB/s。なぜか?
40. 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のバンド幅でデータを供給する。
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-40
41. 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%’
実行結果
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-41
GpuScan
GpuJoin
Agg
+
GpuPreAgg
42. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (2/5)
GpuScan
kernel
GpuJoin
kernel
GpuPreAgg
kernel
DMA
Buffer
Agg
(PostgreSQL)
GPU
CPU
Storage
単純にロジックを置き換えるだけでは、CPU<->GPU間の
データ転送のピンポンが発生してしまう。
DMA
Buffer
DMA
Buffer
実行
結果
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-42
43. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (3/5)
構造の単純なWHERE句評価は、既にJOINと同じタイミングで
実行するようになっている。
GpuScan
kernel
GpuJoin
kernel
GpuPreAgg
kernel
DMA
Buffer
Agg
(PostgreSQL)
GPU
CPU
Storage
DMA
Buffer
実行
結果
GpuScan + GpuJoin
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-43
44. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (4/5)
集約演算まで一気に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
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-44
45. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (5/5)
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-45
10GBのデータをスキャンして、
最終的にCPU側へ書き戻されたのは 1.2kB のみ。
46. 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
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-46
48. OLTPの世界 OLAPの世界
インテリジェント・ストレージ構想 (1/2)
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-48
SSD上でRow-to-Column変換により、Rowで書いてColumnで読む
R/C
変換
ロジック
列データ
解析系データ
読出し
(列形式)
業務データ
書込み
(行データ)
データ形式変換
FPGA等による
H/W実装
SQLクエリ処理
GPU本来の計算能力を
引き出す列データ形式
集計済み、
JOIN済み
データ
列抽出において
必要なデータだけ
取出し
49. なぜGPUには列志向のデータが向いているか
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-49
▌行データ形式 – 不連続なデータアクセス (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の能力をフルに引き出すには、適切なデータ形式の選択が必要
50. インテリジェント・ストレージ構想 (2/2)
DB Tech Showcase 2017 - GPU/SSDがPostgreSQLを加速する-50
Large PostgreSQL Tables
PCIe Bus
“SQL-aware”
NVMe SSD GPU
SSD-to-GPU P2P DMA
WHERE句
JOIN
GROUP BYPostgreSQL
データブロック
行データ列データ変換
必要なデータのみを抽出する事で、
PCIeバスの帯域以上の実効データ転送
GPUでの“超”並列SQL実行
入力データのフォーマットを列形式と
する事で、最大限のGPU性能を発揮
行データとして書込み
トランザクション性能に
影響を与えず、リアル
タイム集計・分析を可能に