SlideShare a Scribd company logo
PostgreSQLは最新ハードウェアでどこまでやれるのか?
~GPUとNVMEで実現する超高速ログデータ処理基盤~
HeteroDB,Inc
KaiGai Kohei <kaigai@heterodb.com>
HeteroDB社について
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~2
会社概要
 商号 ヘテロDB株式会社
 創業 2017年7月4日
 拠点 品川区西大井1-1-2-201
 事業内容 高速データベース製品の販売
GPU&DB領域の技術コンサルティング
ヘテロジニアスコンピューティング技術を
データベース領域に適用し、
誰もが使いやすく、安価で高速なデータ解析基盤を提供する。
代表者プロフィール
 海外 浩平(KaiGai Kohei)
 OSS開発者コミュニティにおいて、PostgreSQLやLinux kernelの
開発に15年以上従事。主にセキュリティ・FDW等の分野でアッ
プストリームへの貢献。
 2007年 IPA未踏ソフト事業において“天才プログラマー”認定
 2017年 GPU Technology ConferenceでTop-5 Posters Finalistに選定
私たちの目指すもの – IoT/M2M向けログデータ処理基盤
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~3
増え続けるログデータの管理、集計から解析・機械学習まで対応したデータ管理基盤
Manufacturing Logistics Mobile Home electronics
 処理ユニットの拡張により、シングルノードで~数十TBのデータにも対応。
 システム全体の大幅なダウンサイジングが可能に(ラック  2Uサイズ)
 蓄積した生ログデータのまま、H/W限界に近い速度で集計する事が可能。
 使い慣れたPostgreSQLのSQL構文、周辺アプリケーションを適用可能。
JBoF: Just Bunch of Flash
NVME over
Fabric
(RDMA)
DB管理者
BIツール
データ集計・解析の
高速化ソフトウェア
PG-Strom
RDBに求められる諸機能
 可用性/クラスタリング
 バックアップ/運用管理
 トランザクション
 BI・可視化
 PostgreSQLのものをAs-Isで利用
中核技術 – PG-Strom
PG-Strom: GPUの持つ数百~数千コアと広帯域メモリを利用して、
SQLワークロードを高速化するPostgreSQL向け拡張モジュール
GPU
大量データの集計・解析
機械学習・統計解析
PG-Strom
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~4
大量のデータを高速に
ストレージから読み出す
GPUとはどんなプロセッサなのか?
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~5
主にHPC分野で実績があり、機械学習用途で爆発的に普及
NVIDIA Tesla V100
スーパーコンピュータ
(東京工業大学 TSUBAME3.0) CG(Computer Graphics) 機械学習
“計算アクセラレータ”のGPUで、どうやってI/Oを高速化するのか?
シミュレーション
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~6
PostgreSQLはどうGPUを活用するのか?
~PG-Stromのアーキテクチャ~
PostgreSQL  PG-Strom間の相互作用
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~7
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列
複数の処理アルゴリズムを競わせ、“コスト値”で評価
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~8
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リソースの解放
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~9
SQLからGPUコードを自動生成(WHERE句の例)
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~10
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
実行計画を確認する
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~11
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)
(actual time=1511.612..1511.613 rows=26 loops=1)
Sort Key: tbl.cat
Sort Method: quicksort Memory: 27kB
-> Custom Scan (GpuPreAgg) (cost=203489.25..203491.98 rows=182 width=20)
(actual time=1511.554..1511.562 rows=26 loops=1)
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)
(actual time=50.726..1101.414 rows=19995540 loops=1)
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)
(actual time=0.016..15.407 rows=100000 loops=1)
Planning Time: 0.721 ms
Execution Time: 1595.815 ms
(19 rows)
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~12
GPUの役割を再定義する
~どのようにI/Oを高速化するのか~
一般的な x86_64 サーバの構成
GPUSSD
CPU
RAM
HDD
N/W
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~13
大量データを処理する時のデータの流れ
CPU RAM
SSD GPU
PCIe
PostgreSQL
データブロック
通常のデータフロー
本来は不要なレコードであっても、
一度CPU/RAMへロードしなければ
要・不要を判断できないため、
データサイズは大きくなりがち。
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~14
一度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を処理し、
データ量を削減する
データ量:小
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~15
要素技術:GPUDirect RDMA
▌CPUを介さず、GPU他のPCIeデバイス間のP2Pデータ転送を行う機能
 元々は、マルチノード環境でInfinibandを介したGPU間のデータ転送効率化技術
 Linux kernelドライバを作成する事で、他の PCIe デバイスにも対応可能
Copyright (c) NVIDIA corporation, 2015
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~16
例えば、NVME-SSD
SSD-to-GPU Direct SQL:ソフトウェアスタック
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~17
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) に対応
ベンチマーク(1/2)- システム構成とワークロード
Supermicro SYS-1019GP-TT
CPU Xeon Gold 6126T (2.6GHz, 12C) x1
RAM 192GB (32GB DDR4-2666 x 6)
GPU NVIDIA Tesla V100 (5120C, 16GB) x1
SSD
Intel SSD DC P4600 (HHHL; 2.0TB) x3
(md-raid0によるストライピング構成)
HDD 2.0TB(SATA; 72krpm) x6
Network 10Gb Ethernet 2ports
OS
Red Hat Enterprise Linux 7.6
CUDA 10.1 + NVIDIA Driver 418.40.04
DB
PostgreSQL v11.2
PG-Strom v2.2devel
■ クエリ例(Q2_3)
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)
典型的なスタースキーマに対し、JOIN,GROUP BYを含む集計クエリを実行
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~18
ベンチマーク(2/2)- 測定結果
 クエリ実行スループット = 353GB (DBサイズ) ÷ クエリ応答時間
 PostgreSQLの2.2~2.3GB/sに対して、SSD-to-GPUダイレクトSQLの効果により
7.2~7.9GB/s(3倍強)の処理性能を発揮
 従来はDWH専用機や小規模クラスタを用いていた水準の能力を1台のマシンで。
2343.7 2320.6 2315.8 2233.1 2223.9 2216.8 2167.8 2281.9 2277.6 2275.9 2172.0 2198.8 2233.3
7880.4 7924.7 7912.5
7725.8 7712.6 7827.2
7398.1 7258.0
7638.5 7750.4
7402.8 7419.6
7639.8
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
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
クエリ実行スループット[MB/s]
Star Schema Benchmark on 1xNVIDIA Tesla V100 + 3xIntel DC P4600
PostgreSQL 11.2 PG-Strom 2.2devel
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~19
適用例:ログ集積・解析システム
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~20
GPU+NVME-SSD搭載
データベースサーバ
SQLによる検索
セキュリティ事故
被害状況把握
影響範囲特定
責任者への報告
• 高速なトライ&エラー
• 使い慣れたインターフェース
• 行データのままで高速な検索
従来システム40分の
クエリを30秒で実行
Aug 12 18:01:01 saba systemd: Started
Session 21060 of user root.
More faster, beyond the limitation
更なる高速化に向けたアプローチ
スケールアウト スケールアップ 列指向データ
複数台のPostgreSQLノードで
処理を分散させる。
各ノードにおける処理はシング
ルノードと同様に、GPUとSSD
による高速化が可能。
GPUやSSDの台数を増やし、
一台あたり並列処理能力を
増強する。
スケールアウトと異なり、コー
ディネーターを必要としない。
ストレージ上のデータ形式を
集計・解析系処理に適した
列形式に変更し、SSDから読み
出すべきI/O量を削減する。
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~22
スケールアップによる性能強化
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~23
ハードウェア構成に関する検討(1/3)
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~24
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
ハードウェア構成に関する検討(2/3)
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~25
PCIeバスを制御するCPUがデータ転送のボトルネックになる
GPU
SSD-1
SSD-2
SSD-3
md-raid0
Xeon
Gold
6126T
routing
by CPU
ハードウェア構成に関する検討(3/3)
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~26
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スイッチがI/Oをバイパスする事でCPUの負荷を軽減できる
マルチGPU・パーティション対応(1/3)
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~27
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
slotGen3
x16
▌HPCサーバ – デバイス間RDMAに最適化したサーバ製品が販売されている
▌I/O拡張ボックス – 本来はデバイスの増設を目的とした製品だが…。
NEC ExpEther 40G
(4slots版)
ネットワーク
スイッチ
4 slots of
PCIe Gen3 x8
PCIe
Swich
40Gb
Ethernet
CPU
NIC
追加のI/Oボックス
マルチGPU・パーティション対応(2/3)
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~28
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
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
I/F: PCIe 3.0 x4
SPECIAL THANKS FOR
lineorder
lineorder_a
(351GB)
lineorder_b
(351GB)
lineorder_c
(351GB)
Table Partition by Hash
マルチGPU・パーティション対応(3/3)- ベンチマーク
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~29
 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 のクエリ処理速度を実現
列指向データによる性能強化
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~30
データ構造を読み解く(1/2)- PostgreSQL(行データ)
テーブル
セグメント
1GB単位に分割
されたファイル
ブロック
通常8KBの固定長領域で、
PostgreSQLにおけるI/O単位
PageHeaderData
HeapTuple-0HeapTuple-1
HeapTuple-2
ItemPointer
HeapTuple
Header
• MVCC可視性制御情報
• 各種のフラグ情報
• 含まれる列の個数
• オブジェクトID(≦PG11)
NULL
Bitmap
Column-1
value
Column-2
value
Column-4
value
タプル
PostgreSQLにおけるストレージ上の行
NULL値や可変長データがあると、
常に一定の場所にデータが置かれる
わけではない。
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~31
データ構造を読み解く(2/2)- Apache Arrow(列データ)
Footer
Apache Arrow形式ファイル
RecordBatch-2
RecordBatch-N
RecordBatch-1
Schema
column-1 null-bitmap
column-1 values-array
column-2 values-array
column-3 null-bitmap
column-3 offset-array
column-3 extra buffer
column-4 values-array
SELECT sum(col2) WHERE col2 < col4;
“被参照列のみロードする”
事が容易なデータ形式
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~32
《補足》なぜ列指向データがGPUに適するのか?
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~33
▌行データ形式 – 不連続なデータアクセス (random memory access)
 メモリトランザクションの回数が増え、データバスの使用率が低下
列データ構造は、GPUのメモリバス使用率を最大化する
▌列データ形式 – 隣接領域に対するデータアクセス (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コア
Apache Arrowとは(1/2)
▌特徴
 列指向で分析用途向けに設計されたデータ形式
 アプリケーションによらず、共通のデータ交換形式として利用可能
 整数、実数、日付時刻、文字列など基本的なデータ型を定義
NVIDIA GPU
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~34
Apache Arrowとは(2/2)- データ型の対応
Apache Arrowデータ型 PostgreSQLデータ型 備考
Int int2, int4, int8
FloatingPoint float2, float4, float8 float2はPG-Stromによる独自拡張
Binary bytea
Utf8 text
Bool bool
Decimal numeric
Date date unitsz = Day に補正
Time time unitsz = MicroSecondに補正
Timestamp timestamp unitsz = MicroSecondに補正
Interval interval
List 配列型(array) PostgreSQLでは行ごとに異なる次元数を指定可
Struct 複合型(composite)
Union ------
FixedSizeBinary char(n)
FixedSizeList array型?
Map ------
Apache Arrow⇔PostgreSQL間でデータ型の相互変換は可能
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~35
FDW (Foreign Data Wrapper) 機能とは
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~36
 FDWモジュールは、外部データPostgreSQLの相互変換に責任を持つ。
 Arrow_Fdwの場合、ファイルシステム上の Arrow 形式ファイルを
Foreign Table という形で参照できるようにマップする。
 改めてデータをDBシステムにインポートする必要がない。
外部テーブル(Foreign Table)- PostgreSQL管理外のデータソースを、
あたかもテーブルであるかのように取り扱うための機能
Table
外部テーブル
postgres_fdw
外部テーブル
file_fdw
外部テーブル
twitter_fdw
外部テーブル
Arrow_fdw
外部RDBMSサーバ
CSVファイル
Twitter (Web API)
Arrowファイル
《補足》ログデータはどこで生成されるのか?
ETL
OLTP OLAP
伝統的なOLTP&OLAPシステム - データはDBシステムの内側で生成される
Data
Creation
IoT/M2M時代 - データはDBシステムの外側で生成される
Log processing
BI Tools
BI Tools
Gateway Server
Async
Write
Async
Read
Data
Creation
Many Devices
Import!
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~37
SSD-to-GPUダイレクトSQL on Arrow_Fdw
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~38
PCIe Bus
NVMe SSD GPU
SSD-to-GPU P2P DMA WHERE句
JOIN
GROUP BY
Apache Arrow
データファイル
Arrow_Fdw
モジュール
Apache Arrow 
PostgreSQL Heapへの
データ形式変換
WHERE句
JOIN
GROUP BY
被参照列だけを
P2P DMAで転送
Apache Arrow形式に対応。
GPUがデータ形式を解釈し、
数千コアを用いた並列実行
実行結果は PostgreSQL の
Heap形式でホスト側へ転送。
(通常、元データより小さい)
実行結果
“被参照列だけ”をGPUに転送する点を除き、同一のインフラを使用している。
ベンチマーク結果(1/2)
 クエリ実行スループット = 353GB(DB) or 310GB(ファイル) ÷ クエリ応答時間
 PostgreSQLの2.2~2.3GB/sに対して、SSD-to-GPUダイレクトと列データの効果に
より、15GB/s~49GB/s相当のクエリ実行スループットを実現。
 シングルノードで数十TB相当のデータ処理も現実的なスコープに達してきた。
2343.7 2320.6 2315.8 2233.1 2223.9 2216.8 2167.8 2281.9 2277.6 2275.9 2172.0 2198.8 2233.3
7880.4 7924.7 7912.5 7725.8 7712.6 7827.2 7398.1 7258.0 7638.5 7750.4 7402.8 7419.6 7639.8
49038
27108
29171 28699
27876
29969
19166
20953 20890
22395
15919 15925
17061
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
50000
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
クエリ実行スループット[MB/s]
Star Schema Benchmark on 1xNVIDIA Tesla V100 + 3xIntel DC P4600
PostgreSQL 11.2 PG-Strom 2.2devel PG-Strom 2.2devel + Arrow_Fdw
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~39
ベンチマーク結果(2/2)- 総実行時間の比較
※ ベンチマーク結果を採取するために、SSBMの13本のクエリを各々3回ずつ実行した。
上記グラフは、その総実行時間を実行エンジンごとに集計したもの。
0 1000 2000 3000 4000 5000 6000 7000
PG-Strom v2.2devel
+ Arrow_Fdw
PG-Strom v2.2devel
PostgreSQL 11.2
総実行時間ベースでの比較 [sec]
PG-Strom v2.2devel
+ Arrow_Fdw
PG-Strom v2.2devel PostgreSQL 11.2
(かなり長めの)お昼寝並みに
時間を要していたバッチ処理を
オムツ替え程度の時間で実行。
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~40
ベンチマーク結果の検証
Foreign table "public.flineorder"
Column | Type | Size
--------------------+---------------+--------------------------------
lo_orderkey | numeric | 35.86GB
lo_linenumber | integer | 8.96GB
lo_custkey | numeric | 35.86GB
lo_partkey | integer | 8.96GB
lo_suppkey | numeric | 35.86GB <-- ★Q2_1で参照
lo_orderdate | integer | 8.96GB <-- ★Q2_1で参照
lo_orderpriority | character(15) | 33.61GB <-- ★Q2_1で参照
lo_shippriority | character(1) | 2.23GB
lo_quantity | integer | 8.96GB
lo_extendedprice | bigint | 17.93GB
lo_ordertotalprice | bigint | 17.93GB
lo_discount | integer | 8.96GB
lo_revenue | bigint | 17.93GB
lo_supplycost | bigint | 17.93GB <-- ★Q2_1で参照
lo_tax | integer | 8.96GB
lo_commit_date | character(8) | 17.93GB
lo_shipmode | character(10) | 22.41GB
FDW options: (file '/opt/nvme/lineorder_s401.arrow') ... file size = 310GB
▌実際に読み出しているデータの合計は310GB中96.4GBのみ(31.08%)
▌Q2_1の実行時間は 11.06s なので、96.4GB / 11.06s = 8.7GB/s
 Intel DC P4600 x3 の読出し速度としては概ね妥当なパフォーマンス。
データ転送の性能は変わらないが、予め不要な列を読み飛ばせる事による高速化
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~41
Apache Arrowファイルの作成(1/2)
 実行すべきSQLとArrow形式データを
出力するファイルを指定すればOK
$./pg2arrow -h
Usage:
pg2arrow [OPTION]... [DBNAME [USERNAME]]
General options:
-d, --dbname=DBNAME database name to connect to
-c, --command=COMMAND SQL command to run
-f, --file=FILENAME SQL command from file
-o, --output=FILENAME result file in Apache Arrow format
Arrow format options:
-s, --segment-size=SIZE size of record batch for each
(default is 256MB)
Connection options:
-h, --host=HOSTNAME database server host
-p, --port=PORT database server port
-U, --username=USERNAME database user name
-w, --no-password never prompt for password
-W, --password force password prompt
Debug options:
--dump=FILENAME dump information of arrow file
--progress shows progress of the job.
Pg2Arrowコマンドで、SQL出力結果をArrow形式で保存できる
Apache Arrow
データファイル
Arrow_Fdw
Pg2Arrow
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~42
Apache Arrowファイルの作成(2/2)- Pg2arrow使用例
$ ./pg2arrow -d postgres -c “SELECT * FROM hogehoge LIMIT 1000“
-o /tmp/hogehoge1000.arrow
$ python
>>> import pyarrow as pa
>>> X = pa.RecordBatchFileReader("/tmp/hogehoge1000.arrow").read_all()
>>> X.schema
id: int32
a: int64
b: double
c: struct<x: int32, y: double, z: decimal(30, 11), memo: string>
child 0, x: int32
child 1, y: double
child 2, z: decimal(30, 11)
child 3, memo: string
d: string
e: double
ymd: date32[day]
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~43
今後のロードマップ
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~44
作ってみたいシステム構成(1/2)
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
slotGen3
x16
U.2 NVME JBOF製品
NVIDIA Tesla V100 x4台
HBA HBA HBA HBA
各HBA毎に U.2 NVME SSDを4台接続
= 合計16台、最大読み出し速度 51.2GB/s
スケールアップ技術と列データ処理技術を組合せ、実効処理速度 100GB/s を目指
す。
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~45
~100TB程度の
ログデータを
シングルノードで
処理可能に
4ユニットの並列動作
で、100~120GB/sの
実効データ処理能力
列データ構造により
ユニット毎25~30GB/sの
実効データ転送性能
作ってみたいシステム構成(2/2)
QPI
スケールアップ技術と列データ処理技術を組合せ、実効処理速度 100GB/s を目指す。
CPU2CPU1RAM RAM
PCIe-SW PCIe-SW
NVME0
NVME1
NVME2
NVME3
NVME4
NVME5
NVME6
NVME7
NVME8
NVME9
NVME10
NVME11
NVME12
NVME13
NVME14
NVME15
GPU0 GPU1 GPU2 GPU3HBA0 HBA1 HBA2 HBA3
GPU+4xSSDユニット
あたり8.0~10GB/sの
物理データ転送性能
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~46
Apache Arrow / NVIDIA RAPIDSを介した機械学習エンジンとの統合
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~47
NVIDIA RAPIDS:
GPU上のデータフレームを統計解析・
機械学習のソリューション間で交換
するためのインフラストラクチャ。
データ形式にはApache Arrowを
採用している。
Why PG-Strom is unique:
NVIDIA自身も、GPUがI/O中心の
ワークロードに適用可能だとは
考えていない節があります。
しかし、SSD-to-GPU Direct SQL技術は
GPUの適用領域をインメモリサイズ
から、ストレージサイズへと拡大し、
データ処理のライフサイクル全体を
カバーする事が可能となるのです。
Our focus
まとめ
▌PG-Stromの中核機能
 SQLからGPUプログラムを自動生成し、数千コアでSQLワークロードを並列処理。
 SSD-to-GPUダイレクトSQLにより、I/OもGPUで高速化できる時代になってきた。
▌更なる高速化に向けて
 PCIeスイッチ:CPUをバイパスしてSSDGPU間のデータ転送を可能にする。
 テーブルパーティションとの併用でデータ転送経路を最適化
 Apache Arrow:列指向データ構造で、外部アプリとのデータ交換も可能に。
 被参照列だけを読み出す事で、I/O負荷を減らし実効性能を向上させる。
 DBシステムへのインポートが不要であり、前処理時間を短縮可能
▌今後のロードマップ
 HPC向けハードウェアを活用する事で、実効処理性能 100GB/s を目指す。
 NVIDIA RAPIDSに対応する事で、同一システム上で大量データの集計・解析
処理から、機械学習処理までをカバーする。
 IoT/M2M系ワークロードで、総データ容量 100TB 以下の領域をターゲットに
ソリューションの開発を進める。
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~48
関連リソース
▌本日の発表資料
 https://www.slideshare.net/kaigai/20190418pgstromonapachearrow/
▌PG-Stromドキュメント
 http://heterodb.github.io/pg-strom/ja/
▌ソースコード
 https://github.com/heterodb/pg-strom
 https://github.com/heterodb/pg2arrow
▌コンタクト
 e-mail: kaigai@heterodb.com
 twitter: @kkaigai
PostgreSQLは最新ハードウェアでどこまでやれるのか? ~GPUとNVMEで実現する超高速ログデータ処理基盤~49
20190418_PGStrom_on_ArrowFdw

More Related Content

What's hot

20170127 JAWS HPC-UG#8
20170127 JAWS HPC-UG#820170127 JAWS HPC-UG#8
20170127 JAWS HPC-UG#8
Kohei KaiGai
 
20170329_BigData基盤研究会#7
20170329_BigData基盤研究会#720170329_BigData基盤研究会#7
20170329_BigData基盤研究会#7
Kohei KaiGai
 
20190516_DLC10_PGStrom
20190516_DLC10_PGStrom20190516_DLC10_PGStrom
20190516_DLC10_PGStrom
Kohei KaiGai
 
20210511_PGStrom_GpuCache
20210511_PGStrom_GpuCache20210511_PGStrom_GpuCache
20210511_PGStrom_GpuCache
Kohei KaiGai
 
20201113_PGconf_Japan_GPU_PostGIS
20201113_PGconf_Japan_GPU_PostGIS20201113_PGconf_Japan_GPU_PostGIS
20201113_PGconf_Japan_GPU_PostGIS
Kohei KaiGai
 
TPC-DSから学ぶPostgreSQLの弱点と今後の展望
TPC-DSから学ぶPostgreSQLの弱点と今後の展望TPC-DSから学ぶPostgreSQLの弱点と今後の展望
TPC-DSから学ぶPostgreSQLの弱点と今後の展望
Kohei KaiGai
 
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database AnalyticsPL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
Kohei KaiGai
 
20171220_hbstudy80_pgstrom
20171220_hbstudy80_pgstrom20171220_hbstudy80_pgstrom
20171220_hbstudy80_pgstrom
Kohei KaiGai
 
[20170922 Sapporo Tech Bar] 地図用データを高速処理!オープンソースGPUデータベースMapDってどんなもの?? by 株式会社...
[20170922 Sapporo Tech Bar] 地図用データを高速処理!オープンソースGPUデータベースMapDってどんなもの?? by 株式会社...[20170922 Sapporo Tech Bar] 地図用データを高速処理!オープンソースGPUデータベースMapDってどんなもの?? by 株式会社...
[20170922 Sapporo Tech Bar] 地図用データを高速処理!オープンソースGPUデータベースMapDってどんなもの?? by 株式会社...
Insight Technology, Inc.
 
An Intelligent Storage?
An Intelligent Storage?An Intelligent Storage?
An Intelligent Storage?
Kohei KaiGai
 
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】
Kohei KaiGai
 
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
NTT DATA Technology & Innovation
 
20191211_Apache_Arrow_Meetup_Tokyo
20191211_Apache_Arrow_Meetup_Tokyo20191211_Apache_Arrow_Meetup_Tokyo
20191211_Apache_Arrow_Meetup_Tokyo
Kohei KaiGai
 
20190925_DBTS_PGStrom
20190925_DBTS_PGStrom20190925_DBTS_PGStrom
20190925_DBTS_PGStrom
Kohei KaiGai
 
SQL+GPU+SSD=∞ (Japanese)
SQL+GPU+SSD=∞ (Japanese)SQL+GPU+SSD=∞ (Japanese)
SQL+GPU+SSD=∞ (Japanese)
Kohei KaiGai
 
20180217 FPGA Extreme Computing #10
20180217 FPGA Extreme Computing #1020180217 FPGA Extreme Computing #10
20180217 FPGA Extreme Computing #10
Kohei KaiGai
 
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]
Kohei KaiGai
 
20171212_GTCJapan_InceptionSummt_HeteroDB
20171212_GTCJapan_InceptionSummt_HeteroDB20171212_GTCJapan_InceptionSummt_HeteroDB
20171212_GTCJapan_InceptionSummt_HeteroDB
Kohei KaiGai
 
20180914 GTCJ INCEPTION HeteroDB
20180914 GTCJ INCEPTION HeteroDB20180914 GTCJ INCEPTION HeteroDB
20180914 GTCJ INCEPTION HeteroDB
Kohei KaiGai
 
pg_bigm(ピージーバイグラム)を用いた全文検索のしくみ
pg_bigm(ピージーバイグラム)を用いた全文検索のしくみpg_bigm(ピージーバイグラム)を用いた全文検索のしくみ
pg_bigm(ピージーバイグラム)を用いた全文検索のしくみ
Masahiko Sawada
 

What's hot (20)

20170127 JAWS HPC-UG#8
20170127 JAWS HPC-UG#820170127 JAWS HPC-UG#8
20170127 JAWS HPC-UG#8
 
20170329_BigData基盤研究会#7
20170329_BigData基盤研究会#720170329_BigData基盤研究会#7
20170329_BigData基盤研究会#7
 
20190516_DLC10_PGStrom
20190516_DLC10_PGStrom20190516_DLC10_PGStrom
20190516_DLC10_PGStrom
 
20210511_PGStrom_GpuCache
20210511_PGStrom_GpuCache20210511_PGStrom_GpuCache
20210511_PGStrom_GpuCache
 
20201113_PGconf_Japan_GPU_PostGIS
20201113_PGconf_Japan_GPU_PostGIS20201113_PGconf_Japan_GPU_PostGIS
20201113_PGconf_Japan_GPU_PostGIS
 
TPC-DSから学ぶPostgreSQLの弱点と今後の展望
TPC-DSから学ぶPostgreSQLの弱点と今後の展望TPC-DSから学ぶPostgreSQLの弱点と今後の展望
TPC-DSから学ぶPostgreSQLの弱点と今後の展望
 
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database AnalyticsPL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
PL/CUDA - Fusion of HPC Grade Power with In-Database Analytics
 
20171220_hbstudy80_pgstrom
20171220_hbstudy80_pgstrom20171220_hbstudy80_pgstrom
20171220_hbstudy80_pgstrom
 
[20170922 Sapporo Tech Bar] 地図用データを高速処理!オープンソースGPUデータベースMapDってどんなもの?? by 株式会社...
[20170922 Sapporo Tech Bar] 地図用データを高速処理!オープンソースGPUデータベースMapDってどんなもの?? by 株式会社...[20170922 Sapporo Tech Bar] 地図用データを高速処理!オープンソースGPUデータベースMapDってどんなもの?? by 株式会社...
[20170922 Sapporo Tech Bar] 地図用データを高速処理!オープンソースGPUデータベースMapDってどんなもの?? by 株式会社...
 
An Intelligent Storage?
An Intelligent Storage?An Intelligent Storage?
An Intelligent Storage?
 
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】
SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】
 
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
 
20191211_Apache_Arrow_Meetup_Tokyo
20191211_Apache_Arrow_Meetup_Tokyo20191211_Apache_Arrow_Meetup_Tokyo
20191211_Apache_Arrow_Meetup_Tokyo
 
20190925_DBTS_PGStrom
20190925_DBTS_PGStrom20190925_DBTS_PGStrom
20190925_DBTS_PGStrom
 
SQL+GPU+SSD=∞ (Japanese)
SQL+GPU+SSD=∞ (Japanese)SQL+GPU+SSD=∞ (Japanese)
SQL+GPU+SSD=∞ (Japanese)
 
20180217 FPGA Extreme Computing #10
20180217 FPGA Extreme Computing #1020180217 FPGA Extreme Computing #10
20180217 FPGA Extreme Computing #10
 
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]
GPUとSSDがPostgreSQLを加速する~クエリ処理スループット10GB/sへの挑戦~ [DB Tech Showcase Tokyo/2017]
 
20171212_GTCJapan_InceptionSummt_HeteroDB
20171212_GTCJapan_InceptionSummt_HeteroDB20171212_GTCJapan_InceptionSummt_HeteroDB
20171212_GTCJapan_InceptionSummt_HeteroDB
 
20180914 GTCJ INCEPTION HeteroDB
20180914 GTCJ INCEPTION HeteroDB20180914 GTCJ INCEPTION HeteroDB
20180914 GTCJ INCEPTION HeteroDB
 
pg_bigm(ピージーバイグラム)を用いた全文検索のしくみ
pg_bigm(ピージーバイグラム)を用いた全文検索のしくみpg_bigm(ピージーバイグラム)を用いた全文検索のしくみ
pg_bigm(ピージーバイグラム)を用いた全文検索のしくみ
 

Similar to 20190418_PGStrom_on_ArrowFdw

(JP) GPGPUがPostgreSQLを加速する
(JP) GPGPUがPostgreSQLを加速する(JP) GPGPUがPostgreSQLを加速する
(JP) GPGPUがPostgreSQLを加速する
Kohei KaiGai
 
20170421 tensor flowusergroup
20170421 tensor flowusergroup20170421 tensor flowusergroup
20170421 tensor flowusergroup
ManaMurakami1
 
pg_bigmを用いた全文検索のしくみ(前編)
pg_bigmを用いた全文検索のしくみ(前編)pg_bigmを用いた全文検索のしくみ(前編)
pg_bigmを用いた全文検索のしくみ(前編)
NTT DATA OSS Professional Services
 
20180920_DBTS_PGStrom_JP
20180920_DBTS_PGStrom_JP20180920_DBTS_PGStrom_JP
20180920_DBTS_PGStrom_JP
Kohei KaiGai
 
機械学習とこれを支える並列計算: ディープラーニング・スーパーコンピューターの応用について
機械学習とこれを支える並列計算: ディープラーニング・スーパーコンピューターの応用について機械学習とこれを支える並列計算: ディープラーニング・スーパーコンピューターの応用について
機械学習とこれを支える並列計算: ディープラーニング・スーパーコンピューターの応用について
ハイシンク創研 / Laboratory of Hi-Think Corporation
 
Magnum IO GPUDirect Storage 最新情報
Magnum IO GPUDirect Storage 最新情報Magnum IO GPUDirect Storage 最新情報
Magnum IO GPUDirect Storage 最新情報
NVIDIA Japan
 
Postgres Playground で pgbench を走らせよう!(第35回PostgreSQLアンカンファレンス@オンライン 発表資料)
Postgres Playground で pgbench を走らせよう!(第35回PostgreSQLアンカンファレンス@オンライン 発表資料)Postgres Playground で pgbench を走らせよう!(第35回PostgreSQLアンカンファレンス@オンライン 発表資料)
Postgres Playground で pgbench を走らせよう!(第35回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
 
2015年度GPGPU実践基礎工学 第14回 GPGPU組込開発環境
2015年度GPGPU実践基礎工学 第14回 GPGPU組込開発環境2015年度GPGPU実践基礎工学 第14回 GPGPU組込開発環境
2015年度GPGPU実践基礎工学 第14回 GPGPU組込開発環境
智啓 出川
 
NVIDIA GPU 技術最新情報
NVIDIA GPU 技術最新情報NVIDIA GPU 技術最新情報
NVIDIA GPU 技術最新情報
IDC Frontier
 
20181212 - PGconf.ASIA - LT
20181212 - PGconf.ASIA - LT20181212 - PGconf.ASIA - LT
20181212 - PGconf.ASIA - LT
Kohei KaiGai
 
Prometech Particleworks on Rescale
Prometech Particleworks on RescalePrometech Particleworks on Rescale
Prometech Particleworks on Rescale
Rescale Japan株式会社
 
[db tech showcase Tokyo 2017] B35: 地図用データを高速処理!オープンソースGPUデータベースMapDの魅力に迫る!!by...
[db tech showcase Tokyo 2017] B35: 地図用データを高速処理!オープンソースGPUデータベースMapDの魅力に迫る!!by...[db tech showcase Tokyo 2017] B35: 地図用データを高速処理!オープンソースGPUデータベースMapDの魅力に迫る!!by...
[db tech showcase Tokyo 2017] B35: 地図用データを高速処理!オープンソースGPUデータベースMapDの魅力に迫る!!by...
Insight Technology, Inc.
 
Cmc cmd slim
Cmc cmd slimCmc cmd slim
Cmc cmd slim
Shinji Shimojo
 
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜Takahiro Inoue
 
20221116_DBTS_PGStrom_History
20221116_DBTS_PGStrom_History20221116_DBTS_PGStrom_History
20221116_DBTS_PGStrom_History
Kohei KaiGai
 
オープンソースのIoT向けスケールアウト型データベース GridDB 〜性能ベンチマーク結果とOSSを利用したビッグデータ分析環境〜
オープンソースのIoT向けスケールアウト型データベース GridDB 〜性能ベンチマーク結果とOSSを利用したビッグデータ分析環境〜オープンソースのIoT向けスケールアウト型データベース GridDB 〜性能ベンチマーク結果とOSSを利用したビッグデータ分析環境〜
オープンソースのIoT向けスケールアウト型データベース GridDB 〜性能ベンチマーク結果とOSSを利用したビッグデータ分析環境〜
griddb
 
FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化
Kazunori Sato
 
NVIDIA deep learning最新情報in沖縄
NVIDIA deep learning最新情報in沖縄NVIDIA deep learning最新情報in沖縄
NVIDIA deep learning最新情報in沖縄
Tak Izaki
 

Similar to 20190418_PGStrom_on_ArrowFdw (18)

(JP) GPGPUがPostgreSQLを加速する
(JP) GPGPUがPostgreSQLを加速する(JP) GPGPUがPostgreSQLを加速する
(JP) GPGPUがPostgreSQLを加速する
 
20170421 tensor flowusergroup
20170421 tensor flowusergroup20170421 tensor flowusergroup
20170421 tensor flowusergroup
 
pg_bigmを用いた全文検索のしくみ(前編)
pg_bigmを用いた全文検索のしくみ(前編)pg_bigmを用いた全文検索のしくみ(前編)
pg_bigmを用いた全文検索のしくみ(前編)
 
20180920_DBTS_PGStrom_JP
20180920_DBTS_PGStrom_JP20180920_DBTS_PGStrom_JP
20180920_DBTS_PGStrom_JP
 
機械学習とこれを支える並列計算: ディープラーニング・スーパーコンピューターの応用について
機械学習とこれを支える並列計算: ディープラーニング・スーパーコンピューターの応用について機械学習とこれを支える並列計算: ディープラーニング・スーパーコンピューターの応用について
機械学習とこれを支える並列計算: ディープラーニング・スーパーコンピューターの応用について
 
Magnum IO GPUDirect Storage 最新情報
Magnum IO GPUDirect Storage 最新情報Magnum IO GPUDirect Storage 最新情報
Magnum IO GPUDirect Storage 最新情報
 
Postgres Playground で pgbench を走らせよう!(第35回PostgreSQLアンカンファレンス@オンライン 発表資料)
Postgres Playground で pgbench を走らせよう!(第35回PostgreSQLアンカンファレンス@オンライン 発表資料)Postgres Playground で pgbench を走らせよう!(第35回PostgreSQLアンカンファレンス@オンライン 発表資料)
Postgres Playground で pgbench を走らせよう!(第35回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
2015年度GPGPU実践基礎工学 第14回 GPGPU組込開発環境
2015年度GPGPU実践基礎工学 第14回 GPGPU組込開発環境2015年度GPGPU実践基礎工学 第14回 GPGPU組込開発環境
2015年度GPGPU実践基礎工学 第14回 GPGPU組込開発環境
 
NVIDIA GPU 技術最新情報
NVIDIA GPU 技術最新情報NVIDIA GPU 技術最新情報
NVIDIA GPU 技術最新情報
 
20181212 - PGconf.ASIA - LT
20181212 - PGconf.ASIA - LT20181212 - PGconf.ASIA - LT
20181212 - PGconf.ASIA - LT
 
Prometech Particleworks on Rescale
Prometech Particleworks on RescalePrometech Particleworks on Rescale
Prometech Particleworks on Rescale
 
[db tech showcase Tokyo 2017] B35: 地図用データを高速処理!オープンソースGPUデータベースMapDの魅力に迫る!!by...
[db tech showcase Tokyo 2017] B35: 地図用データを高速処理!オープンソースGPUデータベースMapDの魅力に迫る!!by...[db tech showcase Tokyo 2017] B35: 地図用データを高速処理!オープンソースGPUデータベースMapDの魅力に迫る!!by...
[db tech showcase Tokyo 2017] B35: 地図用データを高速処理!オープンソースGPUデータベースMapDの魅力に迫る!!by...
 
Cmc cmd slim
Cmc cmd slimCmc cmd slim
Cmc cmd slim
 
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
 
20221116_DBTS_PGStrom_History
20221116_DBTS_PGStrom_History20221116_DBTS_PGStrom_History
20221116_DBTS_PGStrom_History
 
オープンソースのIoT向けスケールアウト型データベース GridDB 〜性能ベンチマーク結果とOSSを利用したビッグデータ分析環境〜
オープンソースのIoT向けスケールアウト型データベース GridDB 〜性能ベンチマーク結果とOSSを利用したビッグデータ分析環境〜オープンソースのIoT向けスケールアウト型データベース GridDB 〜性能ベンチマーク結果とOSSを利用したビッグデータ分析環境〜
オープンソースのIoT向けスケールアウト型データベース GridDB 〜性能ベンチマーク結果とOSSを利用したビッグデータ分析環境〜
 
FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化FPGAによる大規模データ処理の高速化
FPGAによる大規模データ処理の高速化
 
NVIDIA deep learning最新情報in沖縄
NVIDIA deep learning最新情報in沖縄NVIDIA deep learning最新情報in沖縄
NVIDIA deep learning最新情報in沖縄
 

More from Kohei KaiGai

20221111_JPUG_CustomScan_API
20221111_JPUG_CustomScan_API20221111_JPUG_CustomScan_API
20221111_JPUG_CustomScan_API
Kohei KaiGai
 
20210928_pgunconf_hll_count
20210928_pgunconf_hll_count20210928_pgunconf_hll_count
20210928_pgunconf_hll_count
Kohei KaiGai
 
20210301_PGconf_Online_GPU_PostGIS_GiST_Index
20210301_PGconf_Online_GPU_PostGIS_GiST_Index20210301_PGconf_Online_GPU_PostGIS_GiST_Index
20210301_PGconf_Online_GPU_PostGIS_GiST_Index
Kohei KaiGai
 
20201128_OSC_Fukuoka_Online_GPUPostGIS
20201128_OSC_Fukuoka_Online_GPUPostGIS20201128_OSC_Fukuoka_Online_GPUPostGIS
20201128_OSC_Fukuoka_Online_GPUPostGIS
Kohei KaiGai
 
20201006_PGconf_Online_Large_Data_Processing
20201006_PGconf_Online_Large_Data_Processing20201006_PGconf_Online_Large_Data_Processing
20201006_PGconf_Online_Large_Data_Processing
Kohei KaiGai
 
20200424_Writable_Arrow_Fdw
20200424_Writable_Arrow_Fdw20200424_Writable_Arrow_Fdw
20200424_Writable_Arrow_Fdw
Kohei KaiGai
 
20190926_Try_RHEL8_NVMEoF_Beta
20190926_Try_RHEL8_NVMEoF_Beta20190926_Try_RHEL8_NVMEoF_Beta
20190926_Try_RHEL8_NVMEoF_Beta
Kohei KaiGai
 
20190909_PGconf.ASIA_KaiGai
20190909_PGconf.ASIA_KaiGai20190909_PGconf.ASIA_KaiGai
20190909_PGconf.ASIA_KaiGai
Kohei KaiGai
 
20190314 PGStrom Arrow_Fdw
20190314 PGStrom Arrow_Fdw20190314 PGStrom Arrow_Fdw
20190314 PGStrom Arrow_Fdw
Kohei KaiGai
 
20181212 - PGconfASIA - LT - English
20181212 - PGconfASIA - LT - English20181212 - PGconfASIA - LT - English
20181212 - PGconfASIA - LT - English
Kohei KaiGai
 
20181210 - PGconf.ASIA Unconference
20181210 - PGconf.ASIA Unconference20181210 - PGconf.ASIA Unconference
20181210 - PGconf.ASIA Unconference
Kohei KaiGai
 
20181116 Massive Log Processing using I/O optimized PostgreSQL
20181116 Massive Log Processing using I/O optimized PostgreSQL20181116 Massive Log Processing using I/O optimized PostgreSQL
20181116 Massive Log Processing using I/O optimized PostgreSQL
Kohei KaiGai
 
20181016_pgconfeu_ssd2gpu_multi
20181016_pgconfeu_ssd2gpu_multi20181016_pgconfeu_ssd2gpu_multi
20181016_pgconfeu_ssd2gpu_multi
Kohei KaiGai
 
20181025_pgconfeu_lt_gstorefdw
20181025_pgconfeu_lt_gstorefdw20181025_pgconfeu_lt_gstorefdw
20181025_pgconfeu_lt_gstorefdw
Kohei KaiGai
 
20180920_DBTS_PGStrom_EN
20180920_DBTS_PGStrom_EN20180920_DBTS_PGStrom_EN
20180920_DBTS_PGStrom_EN
Kohei KaiGai
 

More from Kohei KaiGai (15)

20221111_JPUG_CustomScan_API
20221111_JPUG_CustomScan_API20221111_JPUG_CustomScan_API
20221111_JPUG_CustomScan_API
 
20210928_pgunconf_hll_count
20210928_pgunconf_hll_count20210928_pgunconf_hll_count
20210928_pgunconf_hll_count
 
20210301_PGconf_Online_GPU_PostGIS_GiST_Index
20210301_PGconf_Online_GPU_PostGIS_GiST_Index20210301_PGconf_Online_GPU_PostGIS_GiST_Index
20210301_PGconf_Online_GPU_PostGIS_GiST_Index
 
20201128_OSC_Fukuoka_Online_GPUPostGIS
20201128_OSC_Fukuoka_Online_GPUPostGIS20201128_OSC_Fukuoka_Online_GPUPostGIS
20201128_OSC_Fukuoka_Online_GPUPostGIS
 
20201006_PGconf_Online_Large_Data_Processing
20201006_PGconf_Online_Large_Data_Processing20201006_PGconf_Online_Large_Data_Processing
20201006_PGconf_Online_Large_Data_Processing
 
20200424_Writable_Arrow_Fdw
20200424_Writable_Arrow_Fdw20200424_Writable_Arrow_Fdw
20200424_Writable_Arrow_Fdw
 
20190926_Try_RHEL8_NVMEoF_Beta
20190926_Try_RHEL8_NVMEoF_Beta20190926_Try_RHEL8_NVMEoF_Beta
20190926_Try_RHEL8_NVMEoF_Beta
 
20190909_PGconf.ASIA_KaiGai
20190909_PGconf.ASIA_KaiGai20190909_PGconf.ASIA_KaiGai
20190909_PGconf.ASIA_KaiGai
 
20190314 PGStrom Arrow_Fdw
20190314 PGStrom Arrow_Fdw20190314 PGStrom Arrow_Fdw
20190314 PGStrom Arrow_Fdw
 
20181212 - PGconfASIA - LT - English
20181212 - PGconfASIA - LT - English20181212 - PGconfASIA - LT - English
20181212 - PGconfASIA - LT - English
 
20181210 - PGconf.ASIA Unconference
20181210 - PGconf.ASIA Unconference20181210 - PGconf.ASIA Unconference
20181210 - PGconf.ASIA Unconference
 
20181116 Massive Log Processing using I/O optimized PostgreSQL
20181116 Massive Log Processing using I/O optimized PostgreSQL20181116 Massive Log Processing using I/O optimized PostgreSQL
20181116 Massive Log Processing using I/O optimized PostgreSQL
 
20181016_pgconfeu_ssd2gpu_multi
20181016_pgconfeu_ssd2gpu_multi20181016_pgconfeu_ssd2gpu_multi
20181016_pgconfeu_ssd2gpu_multi
 
20181025_pgconfeu_lt_gstorefdw
20181025_pgconfeu_lt_gstorefdw20181025_pgconfeu_lt_gstorefdw
20181025_pgconfeu_lt_gstorefdw
 
20180920_DBTS_PGStrom_EN
20180920_DBTS_PGStrom_EN20180920_DBTS_PGStrom_EN
20180920_DBTS_PGStrom_EN
 

Recently uploaded

受発注バスターズ説明資料  株式会社batton Saleshub掲載用.pdf
受発注バスターズ説明資料  株式会社batton Saleshub掲載用.pdf受発注バスターズ説明資料  株式会社batton Saleshub掲載用.pdf
受発注バスターズ説明資料  株式会社batton Saleshub掲載用.pdf
ooishi1
 
CO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdf
CO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdfCO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdf
CO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdf
yamamotominami
 
アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)
アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)
アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)
You&I
 
20240603_SD輪読&座談会#57_kitazaki_______.pdf
20240603_SD輪読&座談会#57_kitazaki_______.pdf20240603_SD輪読&座談会#57_kitazaki_______.pdf
20240603_SD輪読&座談会#57_kitazaki_______.pdf
Ayachika Kitazaki
 
FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)
FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)
FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)
fisuda
 
Grokking Simplicity探訪
Grokking Simplicity探訪Grokking Simplicity探訪
Grokking Simplicity探訪
Yoshitaka Kawashima
 
NIST Cybersecurity Framework 2.0の変更点整理をしよう
NIST Cybersecurity Framework 2.0の変更点整理をしようNIST Cybersecurity Framework 2.0の変更点整理をしよう
NIST Cybersecurity Framework 2.0の変更点整理をしよう
You&I
 

Recently uploaded (7)

受発注バスターズ説明資料  株式会社batton Saleshub掲載用.pdf
受発注バスターズ説明資料  株式会社batton Saleshub掲載用.pdf受発注バスターズ説明資料  株式会社batton Saleshub掲載用.pdf
受発注バスターズ説明資料  株式会社batton Saleshub掲載用.pdf
 
CO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdf
CO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdfCO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdf
CO2排出量見える化・削減・報告クラウド「アスエネ」サービス紹介_Saleshub.pdf
 
アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)
アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)
アジャイルの30年(Tree Decades of Agileというブログ記事に関する要約)
 
20240603_SD輪読&座談会#57_kitazaki_______.pdf
20240603_SD輪読&座談会#57_kitazaki_______.pdf20240603_SD輪読&座談会#57_kitazaki_______.pdf
20240603_SD輪読&座談会#57_kitazaki_______.pdf
 
FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)
FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)
FIWARE Orion Context Broker コンテキスト情報管理 (Orion 4.0.0対応)
 
Grokking Simplicity探訪
Grokking Simplicity探訪Grokking Simplicity探訪
Grokking Simplicity探訪
 
NIST Cybersecurity Framework 2.0の変更点整理をしよう
NIST Cybersecurity Framework 2.0の変更点整理をしようNIST Cybersecurity Framework 2.0の変更点整理をしよう
NIST Cybersecurity Framework 2.0の変更点整理をしよう
 

20190418_PGStrom_on_ArrowFdw