爆速Webinar#01 GPU版PostGISとGPUメモリストア

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

2. 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を受賞

3. PG-Stromとは？
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能3
【機能】
 集計／解析ワークロードの透過的な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

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

5. 爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能5
PostGISについて

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

7. 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)
…など
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能7

8. Geometry型と空間関係演算の例
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能8
St_Distance(a,b)
ジオメトリ間の距離
St_Crosses(a,b)
ジオメトリの交差判定
St_Contains(a,b)
ジオメトリの包含判定

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

10. 高速化手法（2/3）- GiSTインデックス
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能10
▌GiSTインデックスとは
 GiST（Generalized Search Tree）は、ツリー構造を持つインデックスを一般化
したフレームワーク。
 PostGISのGeometry型は、GiST上にR木を実装したもの
▌GiSTのR木でできること
 包含（@演算子）や重なり（&&演算子）判定で、インデックスを用いた絞込み
 特に多数のポリゴン×ポイントの重なり判定で計算量が増大しやすい
➔ 事前の絞り込みで計算量を抑え込む
# 国土地理院の市町村形状データをインポート
$ shp2pgsql N03-20_200101.shp | psql gistest
gistest=# ¥d+
List of relations
Schema | Name | Type | Owner | Size |
--------+-------------+----------+--------+------------+
public | geo_japan | table | kaigai | 243 MB |
gistest=# ¥di+
List of relations
Schema | Name | Type | Owner | Table | Size |
--------+--------------------+-------+--------+-----------+---------+
public | geo_japan_pkey | index | kaigai | geo_japan | 2616 kB |
public | geo_japan_geom_idx | index | kaigai | geo_japan | 14 MB |

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

12. 新機能①
GPU版PostGIS
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能12

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

14. 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)
与えられたジオメトリが共通の内部の点を持ち、
かつそうでない点を持つ場合に真を返す。
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能14

15. 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)
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能15

16. 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));
}
:
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能16
列A、列Bから
ジオメトリ型の
データをロード
ロードしたデータで
GPU版 st_contains() 関数を
呼出し
SQLのWHERE句を
評価するために
自動生成された関数

17. 他にもサポートする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()関数）ではなく
専用の実装を設ける事で、高速に結果を返せるようになっている。
基本はユーザさんの要望ベースで順次機能拡張
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能17

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

19. 新機能②
GPUメモリストア（Gstore_Fdw）
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能19

20. 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機能群
データ量：大
データ量：小
従来のスコープ
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能20

21. 背景と課題
▌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
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能21

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

23. Gstore_Fdwアーキテクチャ
REDOログを利用してGPUメモリ側を非同期に更新する。
検索クエリの実行前に更新を適用すれば辻褄は合う！
Host Memory
Store
REDO Log
Buffer
Base File Redo File
Host
Memory
Storage
GPU
Device
Memory
Store
PostgreSQL
BG-Worker
（GPUバッファ管理）
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能23
①未適用分のログ転送
GPU Kernel
to apply
REDO Log
数千スレッドで動作
ほぼ一瞬で適用できる
②GPUカーネルの起動

24. Gstore_Fdwアーキテクチャ
REDOログを利用してGPUメモリ側を非同期に更新する。
検索クエリの実行前に更新を適用すれば辻褄は合う！
Host Memory
Store
REDO Log
Buffer
Base File Redo File
Host
Memory
Storage
GPU
Device
Memory
Store
PostgreSQL
Backend
（解析系SQL）
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能24
①未適用分のログ転送
GPU Kernel
to apply
REDO Log
SQL処理の前に REDO ログを
適用すれば、辻褄はあう
（一貫性が保たれる）
GPU Kernel
to execute
SQL
②GPUカーネルの起動

25. 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は必要ないが）
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能25

26. 更新処理のパフォーマンス（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)
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能26

27. 更新処理のパフォーマンス（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程度
 通常テーブルと外部テーブルの内部ロジックの違いに起因する差異は未検証
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能27

28. 検索処理のパフォーマンス（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から、
指定領域内の数をカウント
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能28

29. 検索処理のパフォーマンス（2/2）
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能29
(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万個の点を格納

30. 検索＋更新処理のパフォーマンス
--- 裏で更新処理を実行
$ 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 万件適用している
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能30

31. 実行環境
従来と異なり、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 への登録
 ドキュメント、ガイダンスの整備
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能31

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

34. トランザクションの対応
 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)
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能34

35. バックアップ＆レプリケーション
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ログの転送
爆速Webinar#01 － 地理情報を爆速で処理する PG-Strom の新機能35