More Related Content
Similar to 20170310_InDatabaseAnalytics_#1 (20)
More from Kohei KaiGai (15)
20170310_InDatabaseAnalytics_#1
- 2. The PG-Strom Project
DBMS as literal....
▌データベース (Database)
▌データベース管理システム (DBMS: Database Management System)
DBMSこそが最もデータに近いソフトウェア!
concept: データに近い場所で計算する
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する3
- 3. The PG-Strom Project
In-database Analyticsの利点
データベース管理システムの計算能力は
不十分で、高度なアルゴリズムの処理には、
データのエクスポートが必要であった。
データ量が多いと転送時間が無視できない。
データを手元で二重管理する事になる。
前処理/後処理でのデータ加工が難しい。
(スクリプトなどの開発が必要)
本来の作業目的である、仮説検証に
割ける時間が浪費されてしまう。
アクセラレータによってデータベース管理
システムの計算能力を増強する事で、
『データのある場所で』 高度なアルゴリズムを
実行する事が可能になる。
DBからは解析結果だけを出力すれば良い。
データは常にDBで一元管理されている。
SQLのフレキシブルなデータ操作命令により、
前処理/後処理ともDB内部で完結できる。
仮説検証とTRY&ERRORを効率化。
データの
エクスポート
Knowledge
Knowledge
解析結果の出力
統計解析
アプリケーション
データ処理 データ管理
データ管理
+
データ処理
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する
Out-database Analytics In-database Analytics
4
- 4. The PG-Strom Project
In-database Analyticsの課題
Algorithm
統計解析処理を行うための
アルゴリズム、パッケージ
Processor
JOINやGROUP BY、Sortなど
計算中心のSQLワークロード
Storage
巨大テーブルのScan
(特にRAMサイズを越えるケース)
Management
データ収集、
データ形式、
意味のある
データなのか?
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する5
- 6. The PG-Strom Project
PG-Strom
SQLアクセラレータとしてのGPU
Application
GPU
JOINや
GROUP BYなど
オフロード
SQLから
GPU命令を
自動生成
PG-Strom: GPUの持つ数百~数千コアと広帯域メモリを利用して、
SQLワークロードを高速化するPostgreSQL向け拡張モジュール
SQLクエリ
PostgreSQL
データ構造
GPU CPU
モデル
NVIDIA
Tesla P100
Intel Xeon
E5-2699v4
世代 Pascal Broadwell
発表 Q2-2016 Q1-2016
トランジスタ数 15billion 7.2billion
コア数
3584
(simple)
22
(functional)
動作クロック
1.126GHz
~1.303GHz
2.20GHz
~3.60GHz
理論性能値
(FP32)
9.3 TFLOPS
1.2 TFLOPS
(with AVX2)
RAMサイズ 16GB (HBM2) max1.5TB (DDR4)
メモリ帯域 732GB/s 76.8GB/s
消費電力 250W 145W
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する7
- 7. The PG-Strom Project
中核機能 (1/2) – SQLからGPUバイナリを動的生成
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する8
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
- 8. The PG-Strom Project
中核機能 (2/2) – 透過的なGPUアクセラレーション
▌コンセプト
共通のSQL構文
SQL構文や関数・演算子などは
全くPostgreSQLと同一で、
アプリケーションの改修が不要
共通のデータ構造
PostgreSQLのデータ構造をそのまま
用いており、データ移行や変換は不要
PostgreSQLのレコードは、必ずしも
GPUにとってベストなデータ形式では
ない。利便性とのトレードオフ。
▌Custom-Scan Interface
拡張モジュールが、クエリ実行計画の
一部を独自実装するための
共通インターフェース。
PG-Stromを実装するため、
開発者コミュニティで標準化された。
Query
Optimizer
Query
Executor
PG-Strom
Extension
Storage Manager
SQL Parser
Application
Storage
共通のSQL構文
共通のデータ形式
Custom-Scan
Interface
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する9
- 9. The PG-Strom Project
GPUによるSQL実行高速化の一例
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する10
▌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 (similar to star schema)
40.44
62.79
79.82
100.50
119.51
144.55
201.12
248.95
9.96 9.93 9.96 9.99 10.02 10.03 9.98 10.00
0
50
100
150
200
250
300
2 3 4 5 6 7 8 9
QueryResponseTime[sec]
Number of joined tables
PG-Strom microbenchmark with JOIN/GROUP BY
PostgreSQL v9.5 PG-Strom v1.0
CPU: Xeon E5-2670v3
GPU: GTX1080
RAM: 384GB
OS: CentOS 7.2
DB: PostgreSQL 9.5 +
PG-Strom v1.0
- 11. The PG-Strom Project
ワークアラウンド – 全てのデータをオンメモリに
Magnetic
Drives
RAM
CPU GPU
16GB/s
(PCIeバス)
72GB/s
(メモリバス)
pg_prewarm
(事前のロード)
~3500コア~20コア
全てのデータをオンメモリ化し、
RAM CPU/GPUに閉じた
処理にする。
データサイズの上限を
RAMサイズが決める。
“Small Big-Data” Solution :-)
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する12
- 13. The PG-Strom Project
要素技術① NVMe-SSD (1/2)
標準化されたコマンドセット
広帯域(数GB/s)
低遅延(数十万IOPS)
マルチコアCPU向けI/Oサブシステム
PCIe
SSD
コントローラ
NAND
Flash
NVMeコマンド
データブロック
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する14
- 14. The PG-Strom Project
要素技術① NVMe-SSD (2/2)
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する15
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規格に対応した製品が各社からリリースされている
- 15. The PG-Strom Project
要素技術② GPUDirect RDMA (1/2)
▌CPU/RAMを仲介する事なく、GPU他のデバイス間でデータ転送を行う機能
元々は、マルチノード環境でInfinibandを介したGPU間のデータ転送効率化技術
Linux kernel moduleを作成する事で、他のPCIeデバイスにも対応可能
Copyright (c) NVIDIA corporation, 2015
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する16
- 16. The PG-Strom Project
要素技術② GPUDirect RDMA (2/2)
物理アドレス空間
PCIe BAR1領域GPU
RAM
RAM
NVMe-SSD Infiniband
HBA
PCIe デバイス
GPUDirect RDMA
GPUデバイスメモリを
物理アドレス空間にマップする機能 “GPUデバイスメモリの物理アドレス”が
あれば、PCIeデバイスとのDMAで
Source/Destinationアドレスとして
指定できる。
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する17
- 17. The PG-Strom Project
NVMe-SSD + GPUDirect RDMA + PG-Strom = Intelligent Storage
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する18
GPU上でのSQLワークロードの処理機構(PG-Strom)と、
SSDからGPUへのダイレクトデータ転送機構(NVMe-Strom)を組み合わせ。
CPUが処理すべきデータ量を削減し、結果としてI/Oワークロードの処理スループットを引き上げる。
NVMe-SSDからGPUへPCIeバスを介してデータブロックを直接転送。
CPU/RAMへのロード前に不要データを削減し、I/Oスループットを引き上げる。
Large PostgreSQL Tables
PCIe Bus
NVMe SSD GPUSSD-to-GPU P2P DMA
(NVMe-Stromドライバ) WHERE句
JOIN
GROUP BY
PostgreSQLデータブロック
ロードすべき
データ量の削減
SSDとGPUの組合せによって、
あたかもストレージがSQLを理解し、
予め不要なデータを削除している
かのように振る舞う。
- 18. The PG-Strom Project
NVMe-Strom ソフトウェアスタック
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する19
pg-strom
NVMe-Strom
VFS
Page Cache
NVMe SSD
Driver
nvidia
driver
GPU
device
memory
GPU
device
memory
PostgreSQL
file offset
DMA
request
block number
SSD-to-GPU Peer-to-Peer DMA
cuMemAlloc()
/proc/nvme-strom
ioctl(2)
read(2)
User
Space
Kernel
Space
- 19. The PG-Strom Project
ディスクキャッシュとの一貫性
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する20
課題 ①対象ブロックがOSキャッシュに保持されている場合、ストレージブロックの内容は
最新でない可能性がある。
②8KB単位のコマ切れDMAは非常に性能が悪い
対策 キャッシュされているブロック(=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
- 20. The PG-Strom Project
ベンチマーク (1/3) – 測定環境
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する21
CPU2CPU1
SSD
x2
Tesla
K80
GPU
Tesla
K20
GPU
(未使用)
▌サーバスペック/SW構成
Model: DELL PowerEdge R730
CPU: Xeon E5-2670v3 (12C, 2.3GHz) x2
RAM: 384GB (うち128GBのみ使用)
HDD: SAS 300GB x8 (RAID5)
OS: CentOS7.2 (3.10.0-327.el7)
SW: CUDA 7.5.17
NVIDIA driver 352.99
PostgreSQL 9.6.1
PG-Strom v2.0devel
▌GPUスペック
NVIDIA Tesla K80
2x 2496 CUDA cores (560MHz)
2x 12GB GDDR5 RAM (240GB/s)
▌SSDスペック
Intel SSD 750 (400GB) x2
Interface: PCIe 3.0 x4 (NVMe 1.2)
Max SeqRead: 2.2GB/s
- 21. The PG-Strom Project
ベンチマーク (2/3) – Star Schema Benchmark
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する22
■ クエリ例
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)
Scan (WHERE句)、JOIN、GROUP
BYから成る典型的な
集計クエリを実行。
lineorderテーブルのサイズが
物理RAMサイズを越えるため、
ワークロードはI/O中心になる。
- 22. The PG-Strom Project
ベンチマーク (3/3) – データ集計SQL/処理スループット
0
500
1000
1500
2000
2500
3000
3500
4000
4500
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]
PostgreSQL SSDx1 PostgreSQL SSDx2 PG-Strom SSDx1 PG-Strom SSDx2
DBサイズ353GBに対し、WHERE句、JOIN、集約/GROUP BY処理を実行。I/Oが支配的なワークロード。
SSD2枚のケース:PostgreSQLは1.6GB/s程度で頭打ちだが、PG-Stromは現状でも3.8GB/sの処理能力を達成。
SSDドライバやSQL実装の改善で、処理スループットの理論限界値 (SSD2枚で 4.4GB/s)を目指す。
HW) CPU: Xeon E5-2670v3, GPU: NVIDIA Tesla K80, RAM: 128GB, SSD: Intel SSD 750(400GB) x2
SW) OS: CentOS7, CUDA7.5, PostgreSQL 9.6.1, PG-Strom 2.0devel
SSD x1枚構成の
理論限界値 [2.2GB/s]
SSD x2枚構成の
理論限界値 [4.4GB/s]
調査中
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する23
- 23. The PG-Strom Project
従来機能の拡張 (1/3) – GpuJoin
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する24
Inner
relation
Outer
relation
Inner
relation
Outer
relation
Hash table Hash table
Next Step Next Step
CPU側は
結果行を参照
するだけ。
CPUによる
ハッシュ表探索
CPUによる
結果行生成
GPUによる
結果行生成
GPUによる
並列Hash表探索
HashJoin by CPU GpuHashJoin
SSD-to-GPU
P2P DMAを
適用
UPDATE
- 24. The PG-Strom Project
GpuPreAgg
従来機能の拡張 (2/3) – GpuPreAgg
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する25
Aggregation by CPU Aggregation with GPU
Relation Relation
Aggregation
Aggregation
1st Step:
Parallel Hash
Reduction
2nd Step:
Atomic Merge
100万行
の読出し
CPUで100
万行を処
理
より少な
い行数
GpuPreAgg:
CPUで処理すべき行数を削減
中間結果
SSD-to-GPU
P2P DMAを適用
UPDATE
- 25. The PG-Strom Project
従来機能の拡張 (3/3) – EXPLAINで確認
nvme=# EXPLAIN
SELECT sum(lo_extendedprice*lo_discount) as revenue
FROM lineorder,date1
WHERE lo_orderdate = d_datekey
AND d_year = 1993
AND lo_discount BETWEEN 1 AND 3
AND lo_quantity < 25;
QUERY PLAN
----------------------------------------------------------------------------------------------------
Aggregate (cost=32629401.85..32629401.86 rows=1 width=32)
-> Custom Scan (GpuPreAgg) (cost=32629397.25..32629400.31 rows=204 width=32)
Reduction: NoGroup
GPU Projection: pgstrom.psum((lo_extendedprice * lo_discount))
Features: outer-bulk-exec, output-slot-format
-> Custom Scan (GpuJoin) on lineorder (cost=6569.11..32597251.98 rows=45032443 width=10)
GPU Projection: lineorder.lo_extendedprice, lineorder.lo_discount
Outer Scan: lineorder (cost=6715.83..35072613.81 rows=315350477 width=14)
Outer Scan Filter: ((lo_discount >= '1'::numeric) AND
(lo_discount <= '3'::numeric) AND
(lo_quantity < '25'::numeric))
Depth 1: GpuHashJoin (nrows 315350477...45032443)
HashKeys: lineorder.lo_orderdate
JoinQuals: (lineorder.lo_orderdate = date1.d_datekey)
KDS-Hash (size: 0B, nbatched: 1)
Features: output-row-format, nvme-strom
-> Seq Scan on date1 (cost=0.00..78.95 rows=365 width=4)
Filter: (d_year = 1993)
(16 rows)
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する26
UPDATE
- 26. The PG-Strom Project
PG-Strom v2.0 開発状況
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する27
•GPUデバイスメモリのホストマッピングと、SSD-to-GPU P2P DMA要求の発行
① NVMe-Strom: 基本機能の実証
•PostgreSQL v9.6のCPU並列 (Partial Scan) 対応
•GpuScanへのNVMe-Stromモードの追加
② PG-Strom: GpuScan + NVMe-Stromの統合
•PostgreSQL v9.6の新オプティマイザへの対応
•GpuJoin/GpuPreAggの直接スキャンモードでのNVMe-Stromの使用
③ PG-Strom: JOIN/GROUP BY対応
•ソフトウェアRAID-0区画に対するストライピングREAD機能のサポート
④ NVMe-Strom: MD RAID-0対応
•テスト、テスト、デバッグ、改善、、、
⑤ 品質改善・安定化 / Quality improvement and stabilization
⑥ PG-Strom v2.0!! (2017/2Q~3Q)
現在のステータス
- 27. The PG-Strom Project
【関連機能】 BRINインデックス対応
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する28
▌BRIN ... Block Range Index
一定範囲のブロック(8KB x 128個)における、対象列の最大値/最小値を記録するインデックス
検索条件にマッチしない事が明らかなブロックを読み飛ばす事ができる。
インデックスサイズが小さく、時系列データの格納に適したインデックス。
RAM/SSD~GPU間のデータ転送量を削減する事ができる。
時系列データ
データの発生した時刻順にレコードがINSERTされるため、
タイムスタンプが近いレコードは、物理的に近しい位置に
格納されるという特徴を持つ。
BRIN インデックス
条件句:
WHERE ymd BETWEEN ‘2016-01-01’
AND ‘2016-12-31’
False
True
True
True
False
min: ‘2015-01-01’
max: ‘2015-09-30’
min: ‘2015-10-01’
max: ‘2016-03-15’
min: ‘2016-03-15’
max: ‘2016-07-31’
min: ‘2016-08-01’
max: ‘2017-02-01’
min: ‘2017-02-01’
max: ‘2017-05-15’
必要最小限のデータだけをGPUに転送
タイムスタンプ+αの条件句を並列に評価する。
v2.0
- 28. The PG-Strom Project
【関連機能】 CPU+GPUハイブリッド並列
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する29
▌PostgreSQL v9.6以降で対応したパラレルクエリの応用
各ワーカープロセスがそれぞれにGPUを使用する。
▌GPUへのデータ供給レートの向上と、結果的にマルチGPUへの対応も可能に。
Parallel
SeqScan
GpuPreAgg
Gather
Background Worker
Parallel
SeqScan
GpuPreAgg
Parallel
SeqScan
GpuPreAgg
Finalize
Aggregate
テーブル
中間集計 中間集計 中間集計
最終結果
GPUによるGROUP BY、
集約演算の実行
~1億行
~100行
v2.0
- 29. The PG-Strom Project
目指すべきソリューション (1/3)
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する34
PCIe x8
接続SSD x2
NVIDIA
Tesla P40
CPU
RAM
DMI
SSD-1
SSD-2
GPU
1Uラックサーバあたり max 10GB/sec のデータ処理能力を目指す
PCI-E
ハードウェアブロック図
ソフトウェアスタック
Red Hat Enterprise Linux 7.3,
CentOS 7.3, Ubuntu 16.04
NVMe-Strom
CUDA 8.0
PostgreSQL
v9.6
PG-Strom 2.0
ユーザアプリケーション
標準SQLインターフェース
- 30. The PG-Strom Project
目指すべきソリューション (2/3)
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する35
PCIe x16
接続SSD x5
NVIDIA
Tesla P40 x5
ハードウェアブロック図
DMI
GPU-1
PCI-SW
PCI-SW
QPIx2
GPU-2
GPU-4
GPU-5
SSD-1
SSD-2
SSD-3
SSD-4
SSD-5
GPU-3
RAM
RAM
CPU 1
CPU 2
PCIe x16
x2 slot
PCIe
96lane
PCIe
96lane
DWH専用機とも対抗可能なデータ処理能力?
- 31. The PG-Strom Project
目指すべきソリューション (3/3)
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する36
PCIe x8
接続SSD x2
NVIDIA
Tesla P40
PostgreSQLのスケールアウト型ソリューションとの組合せ?
- 32. The PG-Strom Project
まとめ
▌In-database Analytics (技術的な) 課題
アルゴリズム
プロセッサ
ストレージ 本日のトピック
▌NVMe-Stom
コンセプト:
GPUでのSQL処理とGPUDirect RDMA機能の組合せにより、
ストレージブロックをCPU/RAMへロードするより前にデータ量を削減する。
CPUが捌かねばならないデータ量/レコード数を減らす。
プロトタイプ性能値:
NVMe-SSD (SeqRead 2.2GB/s) x2台のmd-raid0構成で、
既にクエリ処理スループット3.8GB/sまで達成。
当面の目標は、単体ノード10GB/s級スループットの実現
対応ワークロード:
WHERE句、JOIN、集約関数/GROUP BY
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する37
- 33. The PG-Strom Project
Resources
▌Repository
https://github.com/pg-strom/devel
https://github.com/pg-strom/nvme-strom
▌Documentation
http://strom.kaigai.gr.jp/manual.html
▌Ask me
Tw: @kkaigai
E-mail: kaigai@kaigai.gr.jp
In-database Analyticsの集い#1 - GPU/SSDがPostgreSQLを加速する38