Upgrade to Pro — share decks privately, control downloads, hide ads and more …

GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~PG-Stromで作るデータ処理基盤~

 GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~PG-Stromで作るデータ処理基盤~

GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界
~PG-Stromで作るデータ処理基盤~

OSC/Kyoto 2020発表資料

Avatar for KaiGai Kohei

KaiGai Kohei

August 28, 2020
Tweet

More Decks by KaiGai Kohei

Other Decks in Technology

Transcript

  1. HeteroDB社について OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 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を受賞
  2. GPUとはどんなプロセッサなのか? OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 3 主にHPC分野で実績があり、機械学習用途で爆発的に普及 NVIDIA Tesla V100 スーパーコンピュータ

    (東京工業大学 TSUBAME3.0) CG(Computer Graphics) 機械学習 数千コアの並列処理ユニット、TB/sに達する広帯域メモリを ワンチップに実装した半導体デバイス ➔ “同じ計算を大量のデータに並列実行” を最も得意とする シミュレーション
  3. PG-Stromとは? OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 4 【機能】  集計/解析ワークロードの透過的なGPU高速化  SSD-to-GPU

    Direct SQLによるPCIeバスレベルの最適化  Apache Arrow対応によるデータ交換、インポート時間をほぼゼロに  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ログの集計・解析処理 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 5 Manufacturing Logistics Mobile Home

    electronics なぜPostgreSQLか?  DBMSとしての十分な基本機能(例:トランザクションなど)  豊富な周辺ソフトウェアや拡張モジュールが存在する  エンジニアが慣れ親しんだ技術で、運用ノウハウの蓄積が豊富 JBoF: Just Bunch of Flash NVME-over-Fabric (RDMA) DB管理者 BIツール(可視化) 機械学習アプリケーション (E.g, 異常検知など) 共通データ フレーム PG-Strom
  5. IoT/M2MデータのライフサイクルとPG-Stromの機能 時系列データ (数TB~) 前処理済みデータ リアルタイムデータ ETL・ 前処理 課題: 大容量データの保存・読出し 課題:

    高頻度な更新と高速な解析処理の両立 Apache Arrow対応 (Arrow_Fdw) SSD-to-GPU Direct SQL BRIN-Index GPU Memory Store (Gstore_Fdw) Runtime GPU Code Generation PostGIS / JSONB data support PG-Strom機能群 データ量:大 データ量:小 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 6 Asymmetric Partition-wise JOIN PG-Strom 共通機能 PG-Strom ストレージ機能
  6. 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列 複数の処理アルゴリズムを競わせ、“コスト値”で評価 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 8
  7. SQLからGPUコードを自動生成(WHERE句の例) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 9 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 コンパイラ (nvrtc) Parallel Execution
  8. 実行計画を確認する OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 10 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) どういう事か?
  9. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (1/3) 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%’ 実行結果 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 11 GpuScan GpuJoin Agg + GpuPreAgg SeqScan HashJoin Agg
  10. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (2/3) GpuScan kernel

    GpuJoin kernel GpuPreAgg kernel Host Buffer GPU CPU Storage 単純にロジックを置き換えるだけでは、CPU<->GPU間で データ転送のピンポンが発生してしまう。 Host Buffer Host Buffer 実行結果 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 12 Host Buffer Agg (PostgreSQL)
  11. GpuScan + GpuJoin + GpuPreAgg Combined Kernel (3/3) GpuScan kernel

    GpuJoin kernel GpuPreAgg kernel Host Buffer GPU CPU Storage GPU上でデータ交換を行い、無用なDMAを発行しないようにする。 GPU Buffer GPU Buffer 実行結果 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 13 Host Buffer Agg (PostgreSQL) SCAN + JOIN + GROUP BYを実行するGPUカーネル data size = large data size = small 通常、GPUから書き戻されるデータサイズは、 GPUへ転送するデータサイズよりもずっと小さい。
  12. 一般的な x86_64 サーバの構成 GPU SSD CPU RAM HDD N/W OSC.Kyoto

    Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 15
  13. 大量データを処理する時のデータの流れ CPU RAM SSD GPU PCIe PostgreSQL データブロック 通常のデータフロー 本来は不要なレコードであっても、

    一度CPU/RAMへロードしなければ 要・不要を判断できないため、 データサイズは大きくなりがち。 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 16 一度CPU/RAMへロードしなければ、 “ゴミデータ” であってもその要否を判断できない。
  14. SSD-to-GPUダイレクトSQL(1/4) CPU RAM SSD GPU PCIe PostgreSQL データブロック NVIDIA GPUDirect

    RDMA CPU/RAMを介することなく、 Peer-to-PeerのDMAを用いて SSD上のデータブロックを直接 GPUに転送する機能。 WHERE句 JOIN GROUP BY GPUでSQLを処理し、 データ量を削減する データ量:小 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 17
  15. SSD-to-GPUダイレクトSQL(2/4)- ソフトウェアスタック OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 18 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セクタ番号を変換 NVMEoF Target (JBOF) NVMe Request ▪ Other software component ▪ Our developed software ▪ Hardware NVME over Fabric on RoCE network ローカルSSDだけでなく、 NVME-oFデバイスからの RDMAにも対応
  16. SSD-to-GPUダイレクトSQL(3/4)– システム構成とワークロード OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 19 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 (striping configuration by md-raid0) HDD 2.0TB(SATA; 72krpm) x6 Network 10Gb Ethernet 2ports OS CentOS 7.7 (kernel-3.10.0-1062.1.2.el7) CUDA 10.1 + NVIDIA Driver 418.87.01 DB PostgreSQL v11.5 PG-Strom v2.2 ▪ Query Example (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 15M rows (2.0GB) date1 2.5K rows (400KB) part 1.8M rows (206MB) supplier 5.0M rows (659MB) lineorder 6.0B rows (876GB) シンプルな1Uサーバで、大量データの集計処理を実行 Star Schema Benchmark
  17. SSD-to-GPUダイレクトSQL(4/4)– ベンチマーク結果  クエリ実行スループット = (879GB DB-size) / (クエリ応答時間 [sec])

     SSD-to-GPU Direct SQLの場合、ハードウェア限界(8.5GB/s)に近い性能を記録  CPU+Filesystemベースの構成と比べて約3倍強の高速化 ➔ 従来のDWH専用機並みの性能を、1Uサーバ上のPostgreSQLで実現 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 20 2,443 2,406 2,400 2,348 2,325 2,337 2,346 2,383 2,355 2,356 2,327 2,333 2,313 8,252 8,266 8,266 8,154 8,158 8,186 7,933 8,094 8,240 8,225 7,975 7,969 8,107 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,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 Query Execution Throughput [MB/s] Star Schema Benchmark (s=1000, DBsize: 879GB) on Tesla V100 x1 + DC P4600 x3 PostgreSQL 11.5 PG-Strom 2.2 (Row data)
  18. SSD-to-GPU Direct SQLの今後 NVIDIAが2020Q4にリリース予定のGPUDirect Storageドライバに対応 ➔ 機能的には同等で、SDSや圧縮SSDソリューション等も利用可能に NVIDIA GPUDirect Storage

    HeteroDB NVME-Strom 対応OS RHEL8, Ubuntu 18.04 RHEL7, RHEL8 ローカルSSD 〇 (MOFED + patch) 〇 (INBOX + patch) NVME-oF対応 〇 (MOFED + patch) 〇 (INBOX + patch) ファイル システム対応 NFS, Ext4 一部商用分散FS Ext4 RAID対応 md-raid (RAID0) md-raid (RAID0) ワークロード Read, Write Read その他制約 O_DIRECT必須 I/Oサイズは PAGE_SIZEの倍数のみ 周辺システム Excelero (SDS製品) ScaleFlux (圧縮SSD製品) サードパーティなし OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 21
  19. 背景① データはどこで生成されるのか? ETL OLTP OLAP 伝統的なOLTP&OLAPシステム - データはDBシステムの内側で生成される Data Creation

    IoT/M2M時代 - データはDBシステムの外側で生成される Log processing BI Tools BI Tools Gateway Server Data Creation Data Creation Many Devices OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 23 DBシステムへのデータのインポートが、集計処理以上に時間のかかる処理に! Data Import Import!
  20. Apache Arrowとは(1/2) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 25 ▌特徴  列指向で分析用途向けに設計されたデータ形式 

    アプリケーションによらず、共通のデータ交換形式として利用可能  整数、実数、日付時刻、文字列など基本的なデータ型を定義 NVIDIA GPU PostgreSQL / PG-Strom
  21. Apache Arrowとは(2/2)– データ型のマッピング Apache Arrowデータ型 PostgreSQLデータ型 補足説明 Int int2, int4,

    int8 FloatingPoint float2, float4, float8 float2 is an enhancement of PG-Strom Binary bytea Utf8 text Bool bool Decimal numeric Date date adjusted to unitsz = Day Time time adjusted to unitsz = MicroSecond Timestamp timestamp adjusted to unitsz = MicroSecond Interval interval List array types Only 1-dimensional array is supportable Struct composite types Union ------ FixedSizeBinary char(n) FixedSizeList array types? Map ------ 大半のデータ型はApache Arrow  PostgreSQLの間で変換可能 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 26
  22. FDW (Foreign Data Wrapper) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 27  FDWモジュールは、外部データ

     PostgreSQLの相互変換に責任を持つ。  Arrow_Fdwの場合、ファイルシステム上の Arrow 形式ファイルを Foreign Table という形で参照できるようにマップする(≠ インポートする)。 ➔ 改めてデータをDBシステムにインポートする必要がない。 外部テーブル(Foreign Table)- PostgreSQL管理外のデータソースを、 あたかもテーブルであるかのように取り扱うための機能 PostgreSQL Table Foreign Table postgres_fdw Foreign Table file_fdw Foreign Table twitter_fdw Foreign Table Arrow_fdw External RDBMS CSV Files Twitter (Web API) Arrow Files
  23. SSD-to-GPU Direct SQL on Arrow_Fdw(1/3) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 28 ▌なぜApache

    Arrow形式が優れているのか?  被参照列のみ読み出すため、I/O量が少なくて済む  GPUメモリバスの特性から、プロセッサ実行効率が高い  Read-onlyデータなので、実行時のMVCC検査を行う必要がない SSD-to-GPU Direct SQL機構を使って、被参照列だけを転送する。 PCIe Bus NVMe SSD GPU SSD-to-GPU P2P DMA WHERE-clause JOIN GROUP BY クエリの被参照列のみ、 ダイレクトデータ転送 Apache Arrow形式を解釈し、 データを取り出せるよう GPUコード側での対応。 小規模の処理結果だけを PostgreSQLデータ形式で返す Results metadata
  24. SSD-to-GPU Direct SQL on Arrow_Fdw(2/3)– ベンチマーク結果①  クエリ実行スループット = (879GB;

    DB or 685GB; arrow) / (クエリ応答時間 [sec])  SSD-to-GPU Direct SQLとArrow_Fdwの併用により、16GB~58GB/sのクエリ実行 スループット(被参照列の数による)を達成。  サーバ構成は前述のものと同様;1Uラックマウント構成(1CPU, 1GPU, 3SSD) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 29 2,443 2,406 2,400 2,348 2,325 2,337 2,346 2,383 2,355 2,356 2,327 2,333 2,313 8,252 8,266 8,266 8,154 8,158 8,186 7,933 8,094 8,240 8,225 7,975 7,969 8,107 56,228 57,780 58,409 28,832 30,597 32,963 18,255 20,924 21,460 21,632 16,172 16,262 17,835 0 10,000 20,000 30,000 40,000 50,000 60,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 Query Execution Throughput [MB/s] Star Schema Benchmark (s=1000, DBsize: 879GB) on Tesla V100 x1 + DC P4600 x3 PostgreSQL 11.5 PG-Strom 2.2 (Row data) PG-Strom 2.2 + Arrow_Fdw
  25. SSD-to-GPU Direct SQL on Arrow_Fdw(3/3)– 結果の検証 Foreign table "public.flineorder" Column

    | Type | Size --------------------+---------------+-------------------------------- lo_orderkey | numeric | 89.42GB lo_linenumber | integer | 22.37GB lo_custkey | numeric | 89.42GB lo_partkey | integer | 22.37GB <-- ★Referenced by Q2_1 lo_suppkey | numeric | 89.42GB <-- ★Referenced by Q2_1 lo_orderdate | integer | 22.37GB <-- ★Referenced by Q2_1 lo_orderpriority | character(15) | 83.82GB lo_shippriority | character(1) | 5.7GB lo_quantity | integer | 22.37GB lo_extendedprice | integer | 22.37GB lo_ordertotalprice | integer | 22.37GB lo_discount | integer | 22.37GB lo_revenue | integer | 22.37GB <-- ★Referenced by Q2_1 lo_supplycost | integer | 22.37GB lo_tax | integer | 22.37GB lo_commit_date | character(8) | 44.71GB lo_shipmode | character(10) | 55.88GB FDW options: (file '/opt/nvme/lineorder_s401.arrow') ... file size = 310GB ▌Q2_1では、681GB中157GB (23.0%) だけをNVME-SSDから実際に読み出している。 ▌Q2_1の実行時間は24.3sなので、157GB / 24.3s = 6.46GB/s ➔ 3x Intel DC P4600 (2.0TB; HHHL) のストライプ構成としては穏当な性能。 物理的なデータ転送速度は変わらないが、被参照列のみを読み出す事で効率化 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 30
  26. 《補足》PostgreSQLデータベースからArrowファイルを生成する ✓ 基本的な使い方は、-cで指定したSQLの実行結果を、 -oで指定したファイルに書き出す。 $ pg2arrow --help Usage: pg2arrow [OPTION]

    [database] [username] General options: -d, --dbname=DBNAME Database name to connect to -c, --command=COMMAND SQL command to run -t, --table=TABLENAME Table name to be dumped (-c and -t are exclusive, either of them must be given) -o, --output=FILENAME result file in Apache Arrow format --append=FILENAME result Apache Arrow file to be appended (--output and --append are exclusive. If neither of them are given, it creates a temporary file.) Arrow format options: -s, --segment-size=SIZE size of record batch for each Connection options: -h, --host=HOSTNAME database server host -p, --port=PORT database server port -u, --user=USERNAME database user name -w, --no-password never prompt for password -W, --password force password prompt Other options: --dump=FILENAME dump information of arrow file --progress shows progress of the job --set=NAME:VALUE config option to set before SQL execution --help shows this message Pg2Arrow により、SQL実行結果をArrow形式で書き出す事ができる。 Apache Arrow Data Files Arrow_Fdw Pg2Arrow OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 31
  27. 《補足》PostgreSQLデータベースからArrowファイルを生成する OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 32 postgres=# SELECT * FROM hoge

    LIMIT 5; id | a | b | c | d ----+---------+------------------+----------------------------------+---------------------------- 1 | 912.185 | 115.101983824327 | c4ca4238a0b923820dcc509a6f75849b | 2018-05-03 06:34:22.699732 2 | 443.359 | 838.238199631794 | c81e728d9d4c2f636f067f89cc14862c | 2023-04-15 20:32:04.849892 3 | 724.745 | 151.214333787195 | eccbc87e4b5ce2fe28308fd9f2a7baf3 | 2020-09-09 08:36:16.945115 4 | 945.821 | 679.363269675227 | a87ff679a2f3e71d9181a67b7542122c | 2024-09-01 02:23:25.905831 5 | 866.806 | 936.137223120843 | e4da3b7fbbce2345d7772b0674a318d5 | 2019-02-27 16:48:00.914714 (5 rows) $ ./pg2arrow -h localhost -d postgres -c "SELECT * FROM hoge" -o /tmp/hoge.arrow --progress RecordBatch 0: offset=400 length=60840 (meta=360, body=60480) $ python3 >>> import pyarrow as pa >>> f = pa.ipc.open_file('/tmp/hoge.arrow') >>> f.schema id: int32 a: float b: double c: string d: timestamp[us] >>> f.get_record_batch(0).to_pandas()
  28. 《補足》PostgreSQLデータベースからArrowファイルを生成する OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 33 postgres=# SELECT * FROM hoge

    LIMIT 5; id | a | b | c | d ----+---------+------------------+----------------------------------+---------------------------- 1 | 912.185 | 115.101983824327 | c4ca4238a0b923820dcc509a6f75849b | 2018-05-03 06:34:22.699732 2 | 443.359 | 838.238199631794 | c81e728d9d4c2f636f067f89cc14862c | 2023-04-15 20:32:04.849892 3 | 724.745 | 151.214333787195 | eccbc87e4b5ce2fe28308fd9f2a7baf3 | 2020-09-09 08:36:16.945115 4 | 945.821 | 679.363269675227 | a87ff679a2f3e71d9181a67b7542122c | 2024-09-01 02:23:25.905831 5 | 866.806 | 936.137223120843 | e4da3b7fbbce2345d7772b0674a318d5 | 2019-02-27 16:48:00.914714 (5 rows) >>> f.get_record_batch(0).to_pandas() id a b c d 0 1 912.185303 115.101984 c4ca4238a0b923820dcc509a6f75849b 2018-05-03 06:34:22.699732 1 2 443.358643 838.238200 c81e728d9d4c2f636f067f89cc14862c 2023-04-15 20:32:04.849892 2 3 724.744934 151.214334 eccbc87e4b5ce2fe28308fd9f2a7baf3 2020-09-09 08:36:16.945115 3 4 945.820862 679.363270 a87ff679a2f3e71d9181a67b7542122c 2024-09-01 02:23:25.905831 4 5 866.806213 936.137223 e4da3b7fbbce2345d7772b0674a318d5 2019-02-27 16:48:00.914714 .. ... ... ... ... ... 995 996 775.208069 650.437260 0b8aff0438617c055eb55f0ba5d226fa 2020-10-20 22:25:12.552472 996 997 307.992249 632.720383 ec5aa0b7846082a2415f0902f0da88f2 2023-05-21 01:51:49.750671 997 998 351.875305 228.426710 9ab0d88431732957a618d4a469a0d4c3 2023-10-10 01:00:49.554332 998 999 446.303772 506.119982 b706835de79a2b4e80506f582af3676a 2024-04-07 16:46:46.459525 999 1000 700.981323 704.731527 a9b7ba70783b617e9998dc4dd82eb3c5 2020-01-31 03:02:39.859514 [1000 rows x 5 columns]
  29. ~100TB程度の ログデータを シングルノードで 処理可能に 4ユニットの並列動作で、 100~120GB/sの 実効データ処理能力 列データ構造により ユニット毎25~30GB/sの 実効データ転送性能

    大規模構成による検証(1/3) QPI SSD-to-GPU Direct SQL、Arrow_Fdw、マルチGPU処理の全てを投入 CPU2 CPU1 RAM RAM PCIe-SW PCIe-SW NVME0 NVME1 NVME2 NVME3 NVME4 NVME5 NVME6 NVME7 NVME8 NVME9 NVME10 NVME11 NVME12 NVME13 NVME14 NVME15 GPU0 GPU1 GPU2 GPU3 HBA0 HBA1 HBA2 HBA3 GPU+4xSSDユニット あたり8.0~10GB/sの 物理データ転送性能 35 PCIe-SW PCIe-SW JBOF unit-0 JBOF unit-1 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~
  30. 大規模構成による検証(3/3) UPI 879GBx4 = 3.5TBのテストデータを4つのパーティションに分散 CPU2 CPU1 RAM RAM PCIe-SW

    PCIe-SW NVME0 NVME1 NVME2 NVME3 NVME4 NVME5 NVME6 NVME7 NVME8 NVME9 NVME10 NVME11 NVME12 NVME13 NVME14 NVME15 GPU0 GPU1 GPU2 GPU3 HBA0 HBA1 HBA2 HBA3 37 PCIe-SW PCIe-SW OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ lineorder_p0 (879GB) lineorder_p1 (879GB) lineorder_p2 (879GB) lineorder_p3 (879GB) lineorder (---GB) Hash-Partition (N=4)
  31. ベンチマーク結果(1/2) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 38 毎秒10億レコードの処理性能をシングルノードで実現 64.0 65.0 65.2 58.8

    58.0 67.3 43.9 58.7 61.0 60.8 52.9 53.0 59.1 255.2 255.6 256.9 257.6 258.0 257.5 248.5 254.9 253.3 253.3 249.3 249.4 249.6 1,681 1,714 1,719 1,058 1,090 1,127 753 801 816 812 658 664 675 0 200 400 600 800 1,000 1,200 1,400 1,600 1,800 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 単位時間あたり処理レコード数 [million rows / sec] Results of Star Schema Benchmark [SF=4,000 (3.5TB; 24B rows), 4xGPU, 16xNVME-SSD] PostgreSQL 11.5 PG-Strom 2.2 PG-Strom 2.2 + Arrow_Fdw more than billion rows per second
  32. ベンチマーク結果(2/2) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 39 SQL実行中は40GB/s前後(HW限界の95%)でデータを読み出し 0 5,000 10,000 15,000

    20,000 25,000 30,000 35,000 40,000 0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300 320 340 NVME-SSD Read Throughput [MB/s] 経過時間 [sec] /dev/md0 (GPU0) /dev/md1 (GPU1) /dev/md2 (GPU2) /dev/md3 (GPU3)
  33. Asymmetric Partition-wise JOIN(1/4) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 40 lineorder lineorder_p0 lineorder_p1

    lineorder_p2 reminder=0 reminder=1 reminder=2 customer date supplier parts tablespace: nvme0 tablespace: nvme1 tablespace: nvme2 課題:パーティション子テーブルのスキャン結果を先に ”CPUで” 結合 Scan Scan Scan Append Join Agg Query Results Scan 大量のレコードを CPUで処理する羽目に!
  34. Asymmetric Partition-wise JOIN(2/4) postgres=# explain select * from ptable p,

    t1 where p.a = t1.aid; QUERY PLAN ---------------------------------------------------------------------------------- Hash Join (cost=2.12..24658.62 rows=49950 width=49) Hash Cond: (p.a = t1.aid) -> Append (cost=0.00..20407.00 rows=1000000 width=12) -> Seq Scan on ptable_p0 p (cost=0.00..5134.63 rows=333263 width=12) -> Seq Scan on ptable_p1 p_1 (cost=0.00..5137.97 rows=333497 width=12) -> Seq Scan on ptable_p2 p_2 (cost=0.00..5134.40 rows=333240 width=12) -> Hash (cost=1.50..1.50 rows=50 width=37) -> Seq Scan on t1 (cost=0.00..1.50 rows=50 width=37) (8 rows) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 41
  35. Asymmetric Partition-wise JOIN(3/4) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 42 lineorder lineorder_p0 lineorder_p1

    lineorder_p2 reminder=0 reminder=1 reminder=2 customer date supplier parts 非パーティション側テーブルとのJOINを各子テーブルへ分配し、 先にJOIN/GROUP BYを実行することでCPUが処理すべき行数を減らす。 Join Append Agg Query Results Scan Scan PreAgg Join Scan PreAgg Join Scan PreAgg tablespace: nvme0 tablespace: nvme1 tablespace: nvme2 各子テーブル毎に JOIN/GROUP BY済み。 処理すべき行数は僅か。 ※ 本機能はPostgreSQL v13向けに、 開発者コミュニティへ提案中です。
  36. Asymmetric Partition-wise JOIN(4/4) postgres=# set enable_partitionwise_join = on; SET postgres=#

    explain select * from ptable p, t1 where p.a = t1.aid; QUERY PLAN ---------------------------------------------------------------------------------- Append (cost=2.12..19912.62 rows=49950 width=49) -> Hash Join (cost=2.12..6552.96 rows=16647 width=49) Hash Cond: (p.a = t1.aid) -> Seq Scan on ptable_p0 p (cost=0.00..5134.63 rows=333263 width=12) -> Hash (cost=1.50..1.50 rows=50 width=37) -> Seq Scan on t1 (cost=0.00..1.50 rows=50 width=37) -> Hash Join (cost=2.12..6557.29 rows=16658 width=49) Hash Cond: (p_1.a = t1.aid) -> Seq Scan on ptable_p1 p_1 (cost=0.00..5137.97 rows=333497 width=12) -> Hash (cost=1.50..1.50 rows=50 width=37) -> Seq Scan on t1 (cost=0.00..1.50 rows=50 width=37) -> Hash Join (cost=2.12..6552.62 rows=16645 width=49) Hash Cond: (p_2.a = t1.aid) -> Seq Scan on ptable_p2 p_2 (cost=0.00..5134.40 rows=333240 width=12) -> Hash (cost=1.50..1.50 rows=50 width=37) -> Seq Scan on t1 (cost=0.00..1.50 rows=50 width=37) (16 rows) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 43
  37. PostGISって?(1/2) ▌概要  点(Point)、線(LineString)、多角形(Polygon)等のジオメトリ要素、 およびそれらの間の演算を PostgreSQL で実行するための拡張モジュール  演算の例 …

    包含(Contains)、交差(Crosses)、接合(Touch)など  GiSTインデックスに対応して高速な検索を実現  2005年に PostGIS 1.0 がリリース。以降、15年にわたって継続的開発。 © GAIA RESOURCES OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 45 地理情報マスタ センサーデータ 位置情報(座標)を 含むデータを大量に生成 都道府県・市区町村などを単位とするデータの集計や絞り込み 【IoT/M2Mデータに対しての想定利用シーン】
  38. PostGISの高速化手法(1/2)- Bounding Box OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 47 ▌Bounding Boxとは 

    複雑な形状のポリゴンを包摂する最も小さな矩形領域  (x1 ,y1 ) - (x2 ,y2 ) で表現できるのでデータ量が少ない  PostgreSQL / PostGISが geometry 型を保存する時に自動的に生成される。 ▌Bounding Boxの効果  空間関係演算を行う前に、『明らかに接していない』ものを識別できる。 ➔ 重なりを含むジオメトリのみ判定を行う事で、計算リソースを節約。 明らかに接していない 共通部分を持つ可能性 滋賀県 東京都 岐阜県
  39. PostGISの高速化手法(2/2)- GiSTインデックス OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 48 ▌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 |
  40. 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) ジオメトリ1がジオメトリ2を完全に包含 する場合に真を返す。  bool st_crosses(geometry,geometry) 与えられたジオメトリが共通の内部の点を持ち、 かつそうでない点を持つ場合に真を返す。 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 49 GPUに実装された数千コアの 実行ユニットが、個々の行を 並列に評価する。
  41. GiSTインデックスへの対応(1/2) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 50 ▌前提  ポリゴン定義の数は、ポイント(GPSデータ等)に比べると数が少ない。  GiST(R木)インデックスはBounding

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

    WHERE n03_001 = '茨城県' and st_dwithin(j.geom, st_makepoint(p.x, p.y), 0.02) GROUP BY gid; QUERY PLAN ---------------------------------------------------------------------------------------------------- HashAggregate (cost=572080.29..572082.55 rows=226 width=12) Group Key: j.gid -> Custom Scan (GpuPreAgg) (cost=572075.77..572078.60 rows=226 width=12) Reduction: Local Combined GpuJoin: enabled -> Custom Scan (GpuJoin) on geopoint p (cost=71788.46..593630.11 rows=2260026 width=4) Outer Scan: geopoint p (cost=0.00..163696.15 rows=10000115 width=16) Depth 1: GpuHashJoin+GiST Index (heap-size: 115.95KB, nrows 10000115...2260026) IndexFilter: (j.geom && st_expand(st_makepoint(p.x, p.y), '0.02'::double precision)) ¥ on geo_japan_geom_idx (index-size: 13.50MB) JoinQuals: st_dwithin(j.geom, st_makepoint(p.x, p.y), '0.02'::double precision) -> Seq Scan on geo_japan j (cost=0.00..8929.24 rows=226 width=2042) Filter: ((n03_001)::text = '茨城県'::text) (12 rows)  IndexFilter(depth=1)に注目 st_makepoint(p.x, p.y)の結果をst_expand()で上下左右に 0.02 ずつ 拡張した長方形領域と、j.geomのBoundary Boxに重複があるかをチェック。 ➔ この関係性を用いてGiSTインデックス(R木)降下していく。  もし少しでも重なり合う可能性があれば、実際に st_dwithin()を実行して JoinQualsが成立するかをチェックする。 WIP OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 51
  43. IoT/M2MデータのライフサイクルとPG-Stromの機能 時系列データ (数TB~) 前処理済みデータ リアルタイムデータ ETL・ 前処理 課題: 大容量データの保存・読出し 課題:

    高頻度な更新と高速な解析処理の両立 Apache Arrow対応 (Arrow_Fdw) SSD-to-GPU Direct SQL BRIN-Index GPU Memory Store (Gstore_Fdw) Runtime GPU Code Generation PostGIS / JSONB data support PG-Strom機能群 データ量:大 データ量:小 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 53 Asymmetric Partition-wise JOIN PG-Strom 共通機能 PG-Strom ストレージ機能 最新の位置情報だけなら、 (時系列で持たなければ) 意外とデータ量は小さい。
  44. 背景と課題 ▌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 RAM CPU 900GB/s 140GB/s 16GB/s PCI-E Gen3.0 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 54
  45. Gstore_Fdwアーキテクチャ REDOログを利用してGPUメモリ側を非同期に更新する。 検索クエリの実行前に更新を適用すれば辻褄は合う! Host Memory Store REDO Log Buffer Base

    File Redo File Host Memory Storage GPU Device Memory Store PostgreSQL Backend (OLTP系) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 55 PostgreSQL Backend (OLTP系) PostgreSQL Backend (OLTP系) INSERT UPDATE DELETE ログ追記 更新系処理では 一切GPUにタッチしない
  46. 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バッファ管理) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 56 ①未適用分のログ転送 GPU Kernel to apply REDO Log 数千スレッドで動作 ほぼ一瞬で適用できる ②GPUカーネルの起動
  47. Gstore_Fdwアーキテクチャ REDOログを利用してGPUメモリ側を非同期に更新する。 検索クエリの実行前に更新を適用すれば辻褄は合う! Host Memory Store REDO Log Buffer Base

    File Redo File Host Memory Storage GPU Device Memory Store PostgreSQL Backend (解析系SQL) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 57 ①未適用分のログ転送 GPU Kernel to apply REDO Log SQL処理の前に REDO ログを 適用すれば、辻褄はあう (一貫性が保たれる) GPU Kernel to execute SQL ②GPUカーネルの起動
  48. 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は必要ないが) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 58
  49. 更新処理のパフォーマンス(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) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 59
  50. 更新処理のパフォーマンス(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程度  通常テーブルと外部テーブルの内部ロジックの違いに起因する差異は未検証 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 60
  51. 検索処理のパフォーマンス(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から、 指定領域内の数をカウント OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 61
  52. 検索処理のパフォーマンス(2/2) OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 62 (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万個の点を格納
  53. 検索+更新処理のパフォーマンス --- 裏で更新処理を実行 $ 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 万件適用している OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 63
  54. 実行環境の一例 GPUメモリストアが前提なら、NVMEは不要でH/W要件が緩い。 ➔ メジャークラウドのGPUインスタンスでも実行可能に 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現在)で記載。 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 64
  55. まとめ ▌PG-StromはGPUを用いてSQLを高速化する拡張モジュールです。 が、GPUの並列処理性能を引き出すには、GPUにデータを供給する ストレージ機能を適切に設定する必要があります。 ▌データサイズが非常に大きい場合  SSD-to-GPU Direct SQL機能 ▌データが静的である/他の処理系からインポートする場合

     Apache Arrow対応(Arrow_Fdw機能) ▌データサイズが十分に小さい場合  GPUメモリストア機能 ▌地理情報データの分析を行う場合  GPU版PostGIS機能  GPU版GiSTインデックス(R木)機能 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 66
  56. PG-Strom v3.0のリリースに向けて ▌新機能の予定  NVIDIA GPUDirect Storageへの対応 ✓ Ubuntu 18.04でのSSD-to-GPU

    Direct SQLや、 サードパーティによるSDSへの対応も含意  GPU版 PostGIS の提供  GPUメモリストアの提供  CUDA 11/Ampere世代GPUへの対応  PostgreSQL v13への対応  AWS/Azureクラウドでの対応 ▌リリース時期  2020年12月頃 OSC.Kyoto Online ~GPUが拓くIoT/M2Mデータ処理と地理情報分析の世界~ 67