20200806_PGStrom_PostGIS_GstoreFdw

地理情報を爆速で処理するPG-Stromの新機能
～GPU版PostGISとそれを支えるGPUメモリストア～
HeteroDB,Inc
Chief Architect & CEO
KaiGai Kohei <kaigai@heterodb.com>

HeteroDB社について
爆速Webinar#01 －地理情報を爆速で処理する PG-Strom の新機能2
会社概要
 商号ヘテロDB株式会社
 創業 2017年7月4日
 拠点品川区北品川5-13-15
 事業内容高速データベース製品の販売
GPU＆DB領域の技術コンサルティング
ヘテロジニアスコンピューティング技術を
データベース領域に適用し、
誰もが使いやすく、安価で高速なデータ解析基盤を提供する。
代表者プロフィール
 海外浩平（KaiGai Kohei）
 OSS開発者コミュニティにおいて、PostgreSQLやLinux kernelの
開発に10年以上従事。主にセキュリティ・FDW等の分野でアッ
プストリームへの貢献。
 IPA未踏ソフト事業において“天才プログラマー”認定 (2006)
 GPU Technology Conference Japan 2017でInception Awardを受賞

PG-Stromとは？
【機能】
 集計／解析ワークロードの透過的なGPU高速化
 SQLからGPUプログラムを自動生成し並列実行
 SSD-to-GPU Direct SQLによるPCIeバスレベルの最適化
 GPUメモリにデータを常駐。OLTPワークロードとの共存
 一部PostGIS関数のサポート。位置情報分析を高速化
PG-Strom: GPUとNVME/PMEMの能力を最大限に引き出し、
テラバイト級のデータを高速処理するPostgreSQL向け拡張モジュール
App
GPU
off-loading
for IoT/Big-Data
for ML/Analytics
➢ SSD-to-GPU Direct SQL
➢ Columnar Store (Arrow_Fdw)
➢ GPU Memory Store (Gstore_Fdw)
➢ Asymmetric Partition-wise
JOIN/GROUP BY
➢ BRIN-Index Support
➢ NVME-over-Fabric Support
➢ Inter-process Data Frame
for Python scripts
➢ Procedural Language for
GPU native code (w/ cuPy)
➢ PostGIS Support
NEW
NEW

ログ収集デーモン：
ターゲット：IoT/M2Mログの集計・解析処理
Manufacturing Logistics Mobile Home electronics
なぜPostgreSQLか？
 シングルノードで処理できるならそっちの方が運用が楽
 エンジニアが慣れ親しんが技術で、運用ノウハウの蓄積が豊富
JBoF: Just Bunch of Flash
NVME-over-Fabric
(RDMA)
DB管理者
BIツール（可視化）
機械学習アプリケーション
（E.g, 異常検知など）
共通データ
フレーム PG-Strom

PostGISについて

PostGISって？（1/2）
▌概要
 点（Point）、線（LineString）、多角形（Polygon）等のジオメトリ要素、
およびそれらの間の演算を PostgreSQL で実行するための拡張モジュール
 演算の例 … 包含（Contains）、交差（Crosses）、接合（Touch）など
 GiSTインデックスに対応して高速な検索を実現
 2005年に PostGIS 1.0 がリリース。以降、15年にわたって継続的開発。
© GAIA RESOURCES
地理情報マスタセンサーデータ
位置情報（座標）を
含むデータを大量に生成
都道府県・市区町村などを単位とするデータの集計や絞り込み
【IoT/M2Mデータに対しての想定利用シーン】

PostGISって？（2/2）
▌データ型
 Geometry（投影座標系）、Geography（地理座標系）
▌ジオメトリ生成の例
 geometry ST_MakePoint(float8 x, float8 y[, float8 z])
 geometry ST_MakeLine(geometry point1, geometry point2)
…など
▌空間関係演算の例
 float8 ST_Distance(geometry g1, geometry g2)
 float8 ST_Distance(geography gg1, geography gg2)
 bool ST_DWithin(geometry g1, geometry g2, float8 distance)
 float8 ST_Area(geometry g1)
 bool ST_Contains(geometry g1, geometry g2)
 bool ST_Crosses(geometry g1, geometry g2)
…など

Geometry型と空間関係演算の例
St_Distance(a,b)
ジオメトリ間の距離
St_Crosses(a,b)
ジオメトリの交差判定
St_Contains(a,b)
ジオメトリの包含判定

高速化手法（1/3）- Bounding Box
▌Bounding Boxとは
 複雑な形状のポリゴンを包摂する最も小さな矩形領域
 (x1,y1) - (x2,y2) で表現できるのでデータ量が少ない
 PostgreSQL / PostGISが geometry 型を保存する時に自動的に生成される。
▌Bounding Boxの効果
 空間関係演算を行う前に、『明らかに接していない』ものを識別できる。
➔ 重なりを含むジオメトリのみ判定を行う事で、計算リソースを節約。
明らかに接していない
共通部分を持つ可能性

高速化手法（3/3）- CPU並列
▌CPU並列とは
 PostgreSQL v9.6の新機能で、テーブルのスキャン（+ 条件句の評価）を複数プロ
セスで並列実行するもの。
 SQL関数・演算子が副作用を伴わず、ある程度の絞り込みが期待できる場合。
▌PostGISのCPU並列対応
 PostGIS 3.0で対応。ほとんどの関数・演算子が “parallel safe” として定義
PostgreSQL v9.5以前 PostgreSQL v9.6以降
Leader Worker-1 Worker-2

新機能①
GPU版PostGIS

なぜGPUでSQLを高速化できるのか？
▌GPUの特徴
 ワンチップに数千演算コアを搭載する計算能力
 1.0TB/sに迫るメモリバンド
➔ 「同じ演算を多量のデータに対して実行する」ために作られたプロセッサ
（e.g 行列演算）
▌SQLワークロードの特性
 「同じ処理を大量の行に対して実行する」
（例：WHERE句の評価、JOINやGROUP BY処理）
SQL処理の中でも、全件スキャンを伴うようなワークロードに強い
GPUに実装された数千コアの
実行ユニットが、個々の行を
並列に評価する。

PG-StromにおけるPostGIS対応（Jul-2020現在）
▌ジオメトリ生成
 geometry st_makepoint(float8,float8,...)
2点から Point ジオメトリを生成する
▌空間関係演算
 float8 st_distance(geometry,geometry)
2つのジオメトリ間の距離を導出する
 bool st_dwithin(geometry,geometry,float8)
ジオメトリが、指定したジオメトリから
指定した距離内にある場合に真を返す。
 bool st_contains(geometry,geometry)
ジオメトリ１がジオメトリ２を完全に包含
する場合に真を返す。
 bool st_crosses(geometry,geometry)
与えられたジオメトリが共通の内部の点を持ち、
かつそうでない点を持つ場合に真を返す。

GPUでPostGIS関数を実行する（1/2）
postgres=# ¥d _gistest
Table "public._gistest"
Column | Type | Collation | Nullable | Default
--------+----------+-----------+----------+--------------------------------------
id | integer | | not null | nextval('_gistest_id_seq'::regclass)
a | geometry | | |
b | geometry | | |
postgres=# explain verbose select * from _gistest where st_contains(a,b);
QUERY PLAN
------------------------------------------------------------------------------------
Custom Scan (GpuScan) on public._gistest (cost=4251.50..4251.50 rows=1 width=196)
Output: id, a, b
GPU Filter: st_contains(_gistest.a, _gistest.b)
GPU Preference: None
Kernel Source: /var/lib/pgdata/pgsql_tmp/pgsql_tmp_strom_21028.4.gpu
Kernel Binary: /var/lib/pgdata/pgsql_tmp/pgsql_tmp_strom_21028.5.ptx
(6 rows)

GPUでPostGIS関数を実行する（2/2）
$ less /var/lib/pgdata/pgsql_tmp/pgsql_tmp_strom_21028.4.gpu
:
#include "cuda_postgis.h"
#include "cuda_gpuscan.h"
DEVICE_FUNCTION(cl_bool)
gpuscan_quals_eval(kern_context *kcxt,
kern_data_store *kds,
ItemPointerData *t_self,
HeapTupleHeaderData *htup)
{
void *addr __attribute__((unused));
pg_geometry_t KVAR_2;
pg_geometry_t KVAR_3;
assert(htup != NULL);
EXTRACT_HEAP_TUPLE_BEGIN(addr, kds, htup);
EXTRACT_HEAP_TUPLE_NEXT(addr);
pg_datum_ref(kcxt,KVAR_2,addr); // pg_geometry_t
EXTRACT_HEAP_TUPLE_NEXT(addr);
pg_datum_ref(kcxt,KVAR_3,addr); // pg_geometry_t
EXTRACT_HEAP_TUPLE_END();
return EVAL(pgfn_st_contains(kcxt, KVAR_2, KVAR_3));
}
:
列A、列Bから
ジオメトリ型の
データをロード
ロードしたデータで
GPU版 st_contains() 関数を
呼出し
SQLのWHERE句を
評価するために
自動生成された関数

他にもサポートするPostGIS関数は？
 float St_Area(geometry)
✓ ポリゴンの面積を返す。面積単位はSRIDに基づく。
 geometry St_Centroid(geometry)
✓ ジオメトリの幾何学的重心を返す。
 float St_Length(geometry)
✓ LineStringの二次元長を返す。
 bool St_Overlaps(geometry, geometry)
✓ ジオメトリが共有空間を持つかどうかを判定する。
 bool St_Touches(geometry, geometry)
✓ ジオメトリが外周で接触しているかどうかを判定する。
 bool St_Within(geometry, geometry)
✓ ジオメトリAが完全にジオメトリBの内側にあるかどうかを判定する。
.... など。
 その他、よく使う関数に関しては “Fast Path” ロジックの実装も
✓ 例えば、Polygon対PointのSt_Contains()など、汎用ロジック（St_Relate()関数）ではなく
専用の実装を設ける事で、高速に結果を返せるようになっている。
基本はユーザさんの要望ベースで順次機能拡張

GiSTインデックスへの対応
▌前提
 ポリゴン定義の数は、ポイント（GPSデータ等）に比べると数が少ない。
 GiST(R木)インデックスはBounding Boxだけを保持するので、ポリゴン定義データ
に比べると、通常は圧倒的にコンパクトなサイズとなる。
➔ GPUメモリに十分載せうるサイズである事が一般的
▌GPUでGiST(R木)インデックスを参照できれば
 数十万ポリゴン × 数億ポイントの突合といった規模のワークロードを、
一般的なWHERE句の評価と同程度の負荷で処理できる公算が高い。
 現在、技術課題を検討中
ポリゴン×ポイントの突合を圧倒的に高速化する（予定）
WIP
GiST(R木)インデックス
ポリゴン定義
点データを含む
テーブル
数千スレッドが
並列に
インデックスを
探索

新機能②
GPUメモリストア（Gstore_Fdw）

IoT/M2MデータのライフサイクルとPG-Stromの機能
時系列データ
（数TB～）
前処理済みデータ
リアルタイムデータ
ETL・
前処理
課題：
大容量データの保存・読出し
課題：
高頻度な更新と高速な解析処理の両立
Apache Arrow対応
（Arrow_Fdw）
SSD-to-GPU
Direct SQL
BRIN-Index
GPU Memory Store
（Gstore_Fdw）
RuntimeGPUCodeGeneration
PostGIS/JSONdatasupport
NEWNEW
PG-Strom機能群
データ量：大
データ量：小
従来のスコープ

背景と課題
▌GPUとホストメモリは“遠い”
 通常、GPUはPCI-Eバスを介してホストシステムと接続する。
 PCI-E Gen 3.0 x16レーンだと、片方向 16GB/s 「しかない」
行って帰ってのレイテンシは数十マイクロ秒単位。
 DRAMの転送速度は140GB/sでレイテンシは100ns程度。
もしL1/L2に載っていれば数ns単位でアクセス可能
出展：https://gist.github.com/eshelman/343a1c46cb3fba142c1afdcdeec17646
▌高い更新頻度
 もし100万デバイスが10秒に一度、
現在位置を更新するなら？
➔ 単純 UPDATE を毎秒10万回実行。
➔ 1.0sec / 10万 = 10us
▌リアルタイム性に対する要請
 利用者が検索、解析したいのは、
「その時点での最新の状態」
➔ 後でまとめてバッチ、では通用しない。
GPU
Device
RAM
RAMCPU
900GB/s
140GB/s
16GB/s
PCI-E
Gen3.0

Gstore_Fdwアーキテクチャ
REDOログを利用してGPUメモリ側を非同期に更新する。
検索クエリの実行前に更新を適用すれば辻褄は合う！
Host Memory
Store
REDO Log
Buffer
Base File Redo File
Host
Memory
Storage
GPU
Device
Memory
Store
PostgreSQL Backend
（OLTP系）
PostgreSQL Backend
（OLTP系）
PostgreSQL Backend
（OLTP系）
INSERT
UPDATE
DELETE
ログ追記
更新系処理では
一切GPUにタッチしない

Host Memory
Store
REDO Log
Buffer
Base File Redo File
Host
Memory
Storage
GPU
Device
Memory
Store
PostgreSQL
BG-Worker
（GPUバッファ管理）
①未適用分のログ転送
GPU Kernel
to apply
REDO Log
数千スレッドで動作
ほぼ一瞬で適用できる
②GPUカーネルの起動

Host Memory
Store
REDO Log
Buffer
Base File Redo File
Host
Memory
Storage
GPU
Device
Memory
Store
PostgreSQL
Backend
（解析系SQL）
①未適用分のログ転送
GPU Kernel
to apply
REDO Log
SQL処理の前に REDO ログを
適用すれば、辻褄はあう
（一貫性が保たれる）
GPU Kernel
to execute
SQL
②GPUカーネルの起動

Gstore_Fdw外部テーブルの定義
CREATE FOREIGN TABLE ft (
id int,
x float,
y float,
z text
) server gstore_fdw
options (gpu_device_id '1',
base_file '/opt/pgdata-dev/ft.base',
redo_log_file '/opt/pmem-dev/ft.redo’,
max_num_rows '4000000',
primary_key 'id');
（補足）
 base_fileはNVMEストレージ上に配置するのが望ましい。
✓ mmap(2)してバイト単位のランダムアクセスが多発するため、
PMEMの微妙なアクセスの遅さが性能差として見えてしまう。
 redo_log_fileはPMEM上に配置するのが望ましい。
✓ トランザクションのコミット時にREDOログを永続化する必要があるため。
追記書き出しのみだが、細かい単位でCPUキャッシュをフラッシュする。
（逆にブロックデバイスのようなfsyncは必要ないが）

更新処理のパフォーマンス（1/2）
--- 200万行を投入
INSERT INTO ft (SELECT x, 100*random(),
100*random(),
md5(x::text)
FROM generate_series(1,2000000) x);
--- 以下のクエリを pgbench で投入
--- (クライアント数：20を想定）
UPDATE ft SET x = 100*random(),
y = 100*random()
WHERE id = (SELECT 20*(100000.0*random())::int + :client_id);
--- 実行計画
EXPLAIN ....;
QUERY PLAN
-------------------------------------------------------------------
Update on ft (cost=0.02..100.03 rows=10000 width=58)
InitPlan 1 (returns $0)
-> Result (cost=0.00..0.02 rows=1 width=4)
-> Foreign Scan on ft (cost=0.00..100.01 rows=10000 width=58)
Filter: (id = $0)
Index Cond: id = $0
(6 rows)

更新処理のパフォーマンス（2/2）
$ pgbench -p 6543 postgres -n -f test.sql -c 20 -j 10 -T 10
transaction type: test.sql
scaling factor: 1
query mode: simple
number of clients: 20
number of threads: 10
duration: 10 s
number of transactions actually processed: 1236401
latency average = 0.162 ms
tps = 123631.393482 (including connections establishing)
tps = 123674.819689 (excluding connections establishing)
（補足）
 まだ排他ロックで実装している箇所があり、クライアント数が20を越えた辺りで
サチり始める。
➔ Row-Idの払い出しや、REDOログの書き込み位置などロックレス化できるハズ。
 PostgreSQLの通常テーブル（on NVME-SSD）：
20クライアント 65k TPS、80クライアント160k TPS程度
 通常テーブルと外部テーブルの内部ロジックの違いに起因する差異は未検証

検索処理のパフォーマンス（1/2）
--- GpuScan (GPU版PostGIS) + Gstore_Fdw
=# SELECT count(*) FROM ft
WHERE st_contains('polygon ((10 10,90 10,90 12,12 12,12 88,90 88,90 90,¥
10 90,10 10))’, st_makepoint(x,y));
count
-------
94440
(1 row)
Time: 75.466 ms
--- 通常版PostGIS + PostgreSQLテーブル
=# SET pg_strom.enabled = off;
SET
=# SELECT count(*) FROM tt
WHERE st_contains('polygon ((10 10,90 10,90 12,12 12,12 88,90 88,90 90,¥
10 90,10 10))', st_makepoint(x,y));
count
-------
94440
(1 row)
Time: 332.300 ms
200万個のPointから、
指定領域内の数をカウント

検索処理のパフォーマンス（2/2）
(100,100)
(0,0)
(90,90)
(90,10)
(90,12)(12,12)
(12,88) (90,88)
(10,90)
(10,10)
この領域内に含まれる
点（Point）を抽出した
テーブル ft および tt には
(0,0)～(100,100)の範囲内に
ランダムに 200万個の点を格納

検索＋更新処理のパフォーマンス
--- 裏で更新処理を実行
$ pgbench -p 6543 postgres -n -f test.sql -c 15 -T 60
:
duration: 60 s
number of transactions actually processed: 9188638
latency average = 0.098 ms
tps = 153143.595549 (including connections establishing)
tps = 153148.363454 (excluding connections establishing)
--- ヘビーな更新処理中に GPU での集計クエリを実行
=# SELECT count(*) FROM ft
WHERE st_contains('polygon ((10 10,90 10,90 12,12 12,12 88,90 88,90 90, ¥
10 90,10 10))', st_makepoint(x,y));
2020-07-26 17:26:12.283 JST [261916] LOG: gstore_fdw: Log applied (nitems=635787,
length=54396576, pos 750323824 => 787623328)
count
-------
94629
(1 row)
Time: 136.456 ms
ヘビーな更新処理中であっても、若干の処理速度低下で応答
集計処理の開始時点で、GPU側ストアを
最新の状態にリフレッシュするため、
未適用のREDOログを 63.5 万件適用している

実行環境
従来と異なり、NVMEは必須ではないのでH/W要件が緩い。
WIP
モデル名 p3.2xlarge p3.8xlarge p3.16xlarge NC6s v NC12s v3 NC24s v3
vCPU 8 core 32 core 64 core 6 core 12 core 24 core
RAM 61GB 244GB 488GB 112 GB 224 GB 448 GB
GPU 1 x Tesla V100
(16GB; 5120C)
4 x Tesla V100
(16GB; 5120C)
8 x Tesla V100
(16GB; 5120C)
1 x Tesla V100
(16GB; 5120C)
2 x Tesla V100
(16GB; 5120C)
4 x Tesla V100
(16GB; 5120C)
オンデマンド
料金 4.324USD/h 16.906USD/h 32.682USD/h ¥299.22/h ¥782.91/h ¥711.74/h
※ オンデマンド料金は、各社東京リージョンの本体のみ単価（2020/7/26現在）で記載。
今後のマイルストーン
 マシンイメージの提供（2020-4Q頃？）
 AWS Marketplace / Azure Marketplace への登録
 ドキュメント、ガイダンスの整備

PG-Strom v3.0に向けて
▌PostGIS関連
 サポート対象 PostGIS 関数・演算子の拡充
 GiSTインデックスの対応
▌Gstore_Fdw関連
 マルチGPU対応
 バックアップ・レプリケーション機能の実装
 スケーラビリティ改善（ロックレス化）
 可変長データの持ち方改良
▌その他
 AWS/Azure向けの動作検証、マシンイメージ作成
 ドキュメント作成
2020年内の正式リリースに向けて開発・テスト実施中

トランザクションの対応
 SAVEPOINT, ROLLBACK TO SAVEPOINT も使用可能
 トランザクション分離レベルは Read-Committed のみ
 他の GPU-DB では（INSERT/UPDATE/DELETE対応していても）非対応
✓ OmniSCI, Kinetica, SQreamDB, Brytlyt のドキュメントを調査
GPU-DBでは珍しく、トランザクションのRollbackにも対応
=# BEGIN;
BEGIN;
=# INSERT INTO ft VALUES (9999999, random(), random(), 'this is test record');
INSERT 0 1
postgres=# SELECT * FROM ft WHERE id > 9000000;
id | x | y | z
---------+--------------------+--------------------+---------------------
9999999 | 0.4181428498515025 | 0.5861937164356661 | this is test record
(1 row)
postgres=# ABORT;
ROLLBACK
postgres=# SELECT * FROM ft WHERE id > 9000000;
id | x | y | z
----+---+---+---
(0 rows)

バックアップ＆レプリケーション
REDO Log Buffer
Redo File
GSTORE_TX_LOG__INSERT
GSTORE_TX_LOG__DELETE
GSTORE_TX_LOG__COMMIT
GSTORE_TX_LOG__INSERT
GSTORE_TX_LOG__COMMIT
PostgreSQL
Backend
PostgreSQL
Backend
追記
追記
WIP
専用SQL関数
pgstrom.gstore_fdw_replication() Backup Tool
（開発中）
Backup File
Master Server
Base File
Replication Client
（SQL関数; WIP）
Online read-only replica
REDOログの転送

20200806_PGStrom_PostGIS_GstoreFdw

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 20200806_PGStrom_PostGIS_GstoreFdw

Similar to 20200806_PGStrom_PostGIS_GstoreFdw (20)

More from Kohei KaiGai

More from Kohei KaiGai (14)

20200806_PGStrom_PostGIS_GstoreFdw