PostgreSQL で列データ”ファイル”を利用する ～Arrow/Parquet を統合したデータベースの作成～

2025-11-21 PostgreSQL Conference Japan 2025での発表資料です。

1. Apache Arrow/Parquet形式の概要
2. FDWと外部テーブル
3. GPU並列処理とPG-Strom
4. 想定利用シナリオとベンチマーク
5. クラウドGPUの利用
6. 先進的な機能
7. 今後のロードマップ

https://www.postgresql.jp/jpug-pgcon2025

Transcript

1. PostgreSQL で列データ”ファイル”を利用する ～Arrow/Parquet を統合したデータベースの作成～ ヘテロＤＢ株式会社 チーフアーキテクト 兼 CEO 海外 浩平 <kaigai@heterodb.com> ハッシュタグ：#pgcon25j
2. 自己紹介 講師略歴 ✓ 海外 浩平（KaiGai Kohei） ✓ ヘテロＤＢ株式会社 チーフアーキテクト兼CEO ✓ 筑波大学情報学類卒、同大学院 経営・政策科学研究科修了 ✓ 2003年よりNEC勤務。主にLinux kernelやPostgreSQLのコア機能開発に 従事。主にセキュリティやFDW/CSPに関する機能強化で、本家の 開発者コミュニティにも数多くの貢献。 （2007年 未踏ソフトにて「天才プログラマ―」認定、など） ✓ 2012年頃より、GPUを用いたPostgreSQL高速化モジュールである PG-Stromを開発。以降、GPUとは10年以上の付き合い。 ✓ 2017年、HeteroDB社を設立しPG-Stromの事業化に取り組む。 HeteroDB社について  設立： 2017年7月  所在地： 東京都品川区  ミッション： ヘテロジニアスコンピューティング技術を データベース領域に適用し、誰もが使いやすく、 安価で高速なデータ分析基盤を提供する。  PG-Stromエンタープライズ版の開発＆販売のほか、 関連技術領域での技術サービスを行っております。 PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 2
3. 本日のアジェンダ 1. Apache Arrow/Parquet形式の概要 2. FDWと外部テーブル 3. GPU並列処理とPG-Strom 4. 想定利用シナリオとベンチマーク 5. クラウドGPUの利用 6. 先進的な機能 7. 今後のロードマップ PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 3
4. Apache Arrowとは（1/5） PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 4 ▌特徴  構造型・列指向で分析用途向けに設計されたデータ形式  アプリケーションによらず、共通のデータ交換形式として利用可能  整数、実数、日付時刻、文字列など基本的なデータ型を定義 NVIDIA GPU PostgreSQL / PG-Strom
5. Apache Arrowとは（2/5） $ psql postgres : postgres=# IMPORT FOREIGN SCHEMA f_part FROM SERVER arrow_fdw INTO public OPTIONS (file '/opt/arrow/ssbm_part.arrow'); IMPORT FOREIGN SCHEMA postgres=# SELECT * FROM f_part LIMIT 5; p_partkey | p_name | p_mfgr | p_category | p_brand1 | p_color | p_type | p_size | p_container -----------+----------------+--------+------------+-----------+-----------+-------------------------+--------+------------- 1 | lace spring | MFGR#1 | MFGR#11 | MFGR#1121 | goldenrod | PROMO BURNISHED COPPER | 7 | JUMBO PKG 2 | rosy metallic | MFGR#4 | MFGR#43 | MFGR#4318 | blush | LARGE BRUSHED BRASS | 1 | LG CASE 3 | green antique | MFGR#3 | MFGR#32 | MFGR#3210 | dark | STANDARD POLISHED BRASS | 21 | WRAP CASE 4 | metallic smoke | MFGR#1 | MFGR#14 | MFGR#1426 | chocolate | SMALL PLATED BRASS | 14 | MED DRUM 5 | blush chiffon | MFGR#4 | MFGR#45 | MFGR#4510 | forest | STANDARD POLISHED TIN | 15 | SM PKG (5 rows) $ python >>> import pyarrow as pa >>> X = pa.RecordBatchFileReader("/opt/arrow/ssbm_part.arrow") >>> Y = X.get_batch(0) >>> Y.slice(0,5) : ---- p_partkey: [1,2,3,4,5] p_name: ["lace spring","rosy metallic","green antique","metallic smoke","blush chiffon"] p_mfgr: ["MFGR#1","MFGR#4","MFGR#3","MFGR#1","MFGR#4"] p_category: ["MFGR#11","MFGR#43","MFGR#32","MFGR#14","MFGR#45"] p_brand1: ["MFGR#1121","MFGR#4318","MFGR#3210","MFGR#1426","MFGR#4510"] p_color: ["goldenrod","blush","dark","chocolate","forest"] p_type: ["PROMO BURNISHED COPPER","LARGE BRUSHED BRASS","STANDARD POLISHED BRASS","SMALL PLATED BRASS","STANDARD POLISHE...] p_size: [7,1,21,14,15] p_container: ["JUMBO PKG","LG CASE","WRAP CASE","MED DRUM","SM PKG"] 同じデータをゼロコピーで別々のアプリケーションから参照できる PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 5
6. Apache Arrowとは（3/5） Header “ARROW1¥0¥0” Schema Definition Footer Schema Definition Custom Metadata Apache Arrow File RecordBatch-1 RecordBatch-k RecordBatch-N Terminator “ARROW1” RecordBatch: 長さの同じ配列を 列ごとに寄せ集め たもの。 Schema Definition: 列名やデータ型、属性が 列の数だけ列挙されている。 テーブル定義に相当する。 A列 B列 C列 D列 物理的な（ファイル上の）レイアウト A列 NULL-Bitmap A列 Values-array B列 NULL-Bitmap B列 Values-index B列 Values-body C列 NULL-Bitmap C列 Values-array D列 NULL-Bitmap D列 Values-array Record Batch-k SELECT SUM(D) FROM f_arrow_tbl WHERE B LIKE ‘%abc%’; 被参照列のみの ロードが容易 PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 6
7. Apache Arrowとは（4/5） 補足：可変長データについて B[0] = ‘dog’ B[1] = ‘panda’ B[2] = NULL B[3] = ‘capybara’ B[4] = ‘cat’ B列 Null-Bitmap B列 Values-Index B列 Values-Body 1 1 0 3 ‘d’ ‘o’ ‘g’ ‘p’ ‘a’ ‘n’ ‘d’ ‘a’ ‘c’ ‘a’ ‘p’ ‘y’ ‘b’ ‘a’ ‘r’ ‘a’ 8 8 ‘c’ ‘a’ ‘t’ 0 1 1 16 19 文字列長 3-0=3 文字列長 8-3=5 文字列長 16-8=8 文字列長 19-16=3 PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 7
8. Apache Arrowとは（5/5） データ型のマッピング Apache Arrowデータ型 PostgreSQLデータ型 補足説明 Int int1, int2, int4, int8 int1 is an enhancement of PG-Strom 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 timestamptz adjusted to unitsz = MicroSecond Interval interval List array types Only 1-dimensional array is supportable Struct composite types FixedSizeBinary char(n) 大半のデータ型はApache Arrow  PostgreSQLの間で変換可能 PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 8
9. ArrowとParquetの比較（1/2） Arrow形式 Parquet形式 カテゴリ 列指向構造化データ 列指向構造化データ データ編成の単位 RecordBatch RowGroups 基本データ型 IntやStringなど21種類 IntやStringなど14種類 配列・複合型 ✓ ✓ 更新処理 追記のみ 追記のみ データ圧縮 基本的に無圧縮 ※Record Batch単位の圧縮オプションが あるにはあるが…。 圧縮マニア ※zstd, gzipなど多様な圧縮オプション ※RowGroups単位でデータ圧縮 適したストレージ RAMやNVMEなど高速ストレージ ※ データコピーや解凍時間が許容できない ケースで有用。 帯域がボトルネックとなるような低速 ストレージ 利用シーン ✓ とにかく高速にCPU/GPUへデータ を供給したい。 ✓ ストレージを潤沢に利用する事が できる。 ✓ ストレージとCPU/GPU間の帯域を 節約したい。 ✓ ストレージの利用量を抑えたい PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 9
10. ArrowとParquetの比較（2/2） ssbm=# ¥d+ List of relations Schema | Name | Type | Owner | Persistence | Access method | Size | Description --------+------------------+-------+--------+-------------+---------------+---------+------------- public | customer | table | kaigai | permanent | heap | 4061 MB | public | date1 | table | kaigai | permanent | heap | 416 kB | public | lineorder | table | kaigai | permanent | heap | 876 GB | <-- ★ public | part | table | kaigai | permanent | heap | 229 MB | public | supplier | table | kaigai | permanent | heap | 1318 MB | ✓ SSBMのlineorderテーブルを Arrow/Parquet 両形式でダンプしてみる。 $ ls -lh *as_is* -rw-r--r--. 1 kaigai users 1.2T Nov 2 01:04 f_lineorder.as_is.arrow -rw-r--r--. 1 kaigai users 193G Nov 2 01:21 f_lineorder.as_is.parquet ➔ Parquet圧縮の効果で、Arrowの1/6のサイズにまで小さく。 ただし、Arrowの肥大化は numeric ➔ Arrow::Decimal128 型変換の影響も大きい。 大きな値の必要のないデータをInt32に切り詰めれば…。 $ ls -lh *cast* -rw-r--r--. 1 kaigai users 503G Nov 2 10:28 f_lineorder.cast.arrow -rw-r--r--. 1 kaigai users 139G Nov 2 10:31 f_lineorder.cast.parquet データ圧縮による効果 PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 10
11. Arrow/Parquetを使ってやりたい事（1/3） PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 11 大量のIoT/M2MログデータをPostgreSQLを用いて検索・集計したい。 Manufacturing Home electronics Logistics Mobile Log collector DB Server DB Admin BI Tools (Visualization) AL/ML (異常検知など) 外部ツールからのデータ インポートが非常にシンプル ✓ 使い慣れたSQLによる検索・集計 ✓ TBを越える大量のログデータと、 DB管理されたマスタデータの突合・検索
12. 本日のアジェンダ 1. Apache Arrow/Parquet形式の概要 2. FDWと外部テーブル 3. GPU並列処理とPG-Strom 4. 想定利用シナリオとベンチマーク 5. クラウドGPUの利用 6. 先進的な機能 7. 今後のロードマップ PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 12
13. FDW（Foreign Data Wrapper）とは PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 13  文字通り、外部のデータを読み（書き）するためのAPI群  PostgreSQL v8.4の頃から存在する由緒正しい機能  形式の異なる外部データを、PostgreSQLの内部データ形式に変換する ことで、あたかもテーブルがそこに存在するかのように扱うための機能 SQLパーサ オプティマイザ エグゼキュータ クエリ木 （内部形式） 実行計画 SQL構文 問い合わせ結果 buffer manager transaction control metadata cache IPC & Lock index access transaction logs GetForeignPaths() GetForeignPlan() FDW モジュール • 実行計画を作成 • 実行開始 • 次の１行を返す • 実行終了 BeginForeignScan() IterateForeignScan() EndForeignScan() External RDBMS CSV Files PostgreSQLの 共通インフラ
14. Arrow_Fdw（1/4） Arrow_Fdwを介してPostgreSQLでも Arrow / Parquet の読み出しが可能 postgres=# CREATE FOREIGN TABLE f_mytest ( id int, ts timestamp, x float8, y text, z numeric ) SERVER arrow_fdw OPTIONS (file '/tmp/mytest.arrow'); CREATE FOREIGN TABLE postgres=# SELECT * FROM f_mytest; id | ts | x | y | z ----+----------------------------+--------------------+--------------+--------- 1 | 2022-08-02 00:34:44.210589 | 77.4344383633856 | 65ac7f6 | 38.6218 2 | 2019-05-11 03:06:16.353798 | 95.33235230265761 | 9105319395 | 51.8267 3 | 2015-01-04 11:02:25.66779 | 93.67415248121794 | b56930f7834 | 84.9033 : : : : : 24 | 2022-09-24 06:26:02.058316 | 17.668632938372266 | c5e35 | 55.9739 25 | 2016-08-08 18:16:12.248363 | 92.2211769466387 | fa889dd51692 | 19.246 (25 rows) PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 14
15. Arrow_Fdw（2/4） ▌構文 CREATE FOREIGN TABLE table_name ( colname_1 type_1, colname_2 type_2 OPTIONS (field ‘field_name’), : : ) SERVER arrow_fdw OPTIONS (file ‘/path/to/arrow_or_parquet_file’); ▌オプション  file 1個の Arrow/Parquet 形式ファイルを指定する  files 1個以上の Arrow/Parquet形式ファイルをカンマ区切りで指定する  dir 指定したディレクトリ配下のファイル全てをマップする。  pattern dirと併用し、ワイルドカードを含むファイル名のパターンを指定する。 （Virtual Column機能については後述）  parallel_workers パラレルクエリを使用する際の並列度を指定する。  field 列をマップする Arrow ファイルのフィールド名を指定する。 何も指定しないと、列名と同じフィールドをマップする。 ※ データ型はArrowのフィールドと互換性のある型でなければならない。 PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 15
16. Arrow_Fdw（3/4） ▌構文 IMPORT FOREIGN SCHEMA table_name FROM SERVER arrow_fdw INTO public OPTIONS (file ‘/path/to/arrow_or_parquet_file’);  Arrow/Parquetのスキーマ定義情報から、PostgreSQLのテーブル定義を自動生成する。 postgres=# IMPORT FOREIGN SCHEMA f_mytest FROM SERVER arrow_fdw INTO public OPTIONS (file '/opt/arrow/mytest.arrow'); IMPORT FOREIGN SCHEMA postgres=# ¥d f_mytest Foreign table "public.f_mytest" Column | Type | Collation | Nullable | Default | FDW options --------+-----------------------------+-----------+----------+---------+------------- id | integer | | | | ts | timestamp without time zone | | | | x | double precision | | | | y | text | | | | z | numeric | | | | Server: arrow_fdw FDW options: (file '/opt/arrow/mytest.arrow’) PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 16
17. Arrow_Fdw（4/4） Parquetファイルを指定する時は、単にParquetファイルを指定すればよい。 postgres=# IMPORT FOREIGN SCHEMA f_small_lineorder FROM SERVER arrow_fdw INTO public OPTIONS (dir '/tmp/mydata'); IMPORT FOREIGN SCHEMA postgres=# explain select count(*),sum(lo_revenue),lo_shipmode from f_small_lineorder group by lo_shipmode; QUERY PLAN ------------------------------------------------------------------------------------ HashAggregate (cost=8750.00..8752.00 rows=200 width=48) Group Key: lo_shipmode -> Foreign Scan on f_small_lineorder (cost=0.00..5000.00 rows=500000 width=36) referenced: lo_revenue, lo_shipmode file0: /tmp/mydata/small_lineorder_1996.parquet (read: 0B, size: 983.01KB) file1: /tmp/mydata/small_lineorder_1995.parquet (read: 0B, size: 982.03KB) file2: /tmp/mydata/small_lineorder_1997.parquet (read: 0B, size: 983.05KB) file3: /tmp/mydata/small_lineorder_1993.parquet (read: 0B, size: 982.85KB) file4: /tmp/mydata/small_lineorder_1994.parquet (read: 0B, size: 982.79KB) (9 rows) postgres=# select count(*),sum(lo_revenue),lo_shipmode from f_small_lineorder group by lo_shipmode; count | sum | lo_shipmode -------+--------------+------------- 71645 | 260500947351 | SHIP 71851 | 261493010885 | REG AIR 71216 | 260099033301 | FOB 70923 | 257677021122 | RAIL 71610 | 259668751117 | AIR 71326 | 258375517386 | TRUCK 71429 | 258348920853 | MAIL (7 rows) PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 17
18. Arrow/Parquetを使ってやりたい事（2/3） パーティションを用いて、古いデータをArrow/Parquetに移行 Manufacturing Home electronics Logistics arrow_fdw 外部テーブル heap テーブル 時々刻々 蓄積する ログデータの 書込み 日次・週次などのタイミングで、 heapテーブルのデータを Arrowや Parquetに移行 パーティション 直近のデータも 過去のデータも 一気通貫に検索 PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 18
19. 本日のアジェンダ 1. Apache Arrow/Parquet形式の概要 2. FDWと外部テーブル 3. GPU並列処理とPG-Strom 4. 想定利用シナリオとベンチマーク 5. クラウドGPUの利用 6. 先進的な機能 7. 今後のロードマップ PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 19
20. Arrow/Parquetと並列処理 ▌Arrow/Parquetは列指向の構造化データ形式 ➔ 被参照列だけをロードすれば良いので、ストレージ帯域を節約できる。 ．．．だけではなく ▌Arrowのメモリレイアウト  値同士が隣接したメモリ領域に配置されるようになっている。  512bitでアライメントされている。（AVX512向けの最適化） ➔ CPU SIMD命令や、GPU演算コア向けのレイアウトとなっている。 85 100 65 123 98 45 C列 配列 WHERE c >= 100 xPU core xPU core xPU core xPU core xPU core xPU core xPU core 繰り返し処理（ループ）よりも、 多数の演算コアを用いた並列処理に向いた構造 PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 20
21. 《補足》なぜGPUには列指向のデータが向いているか？ PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 21 ▌行データ形式 – 不連続なデータアクセス (random memory access) ➔ メモリトランザクションの回数が増え、データバスの使用率が低下 ▌列データ形式 – 隣接領域に対するデータアクセス (coalesced memory access) ➔ 最小限のメモリトランザクション回数、データバスの使用率を最大化 32bit Memory transaction width: 256bit 32bit 32bit 32bit 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コア
22. Custom-Scan APIとPG-Strom（1/4） PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 22 CustomScan: PostgreSQLのテーブルを Scan/Join する代替の方法を追加する SQLパーサ オプティマイザ エグゼキュータ クエリ木 （内部形式） 実行計画 SQL構文 問い合わせ結果 buffer manager transaction control metadata cache IPC & Lock index access transaction logs 拡張モジュール • 実行計画を作成・登録 • 実行開始 • 次の１行を返す • 実行終了 set_rel_pathlist_hook set_join_pathlist_hook create_upper_paths_hook それぞれPostgreSQLのテーブルを Scan/Join/Group-byするタイミングで 呼び出されるフックを追加 ExecCustomScan() どう実装するかは 拡張モジュールが 任意に決める事が できる。
23. Custom-Scan APIとPG-Strom（2/4） PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 23 PG-Strom: SQL処理の一部をGPUを用いて実行するPostgreSQL拡張モジュール SQLパーサ オプティマイザ エグゼキュータ クエリ木 （内部形式） 実行計画 SQL構文 問い合わせ結果 buffer manager transaction control metadata cache IPC & Lock index access transaction logs set_rel_pathlist_hook set_join_pathlist_hook create_upper_paths_hook GPUでの実行が可能な処理であれば、 CustomPath(GpuXXXX)を追加して オプティマイザの判断を待つ。 ExecCustomScan() GPU実行の可否 チェック GPU命令コード 動的生成 テーブル内容を GPUへ転送 GPUでScan, Join, Group-Byを並列実行 処理結果を PostgreSQLへ返送 PG-Strom
24. Custom-Scan APIとPG-Strom（3/4） PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 24 現在では、PG-Strom以外にもかなりのDBエンジンで利用されている Noriyuki Shinoda『列指向アクセスメソッド徹底比較』, PostgreSQL Conference Japan 2004 https://speakerdeck.com/nori_shinoda/postgresql-conference-japan-2024-a4-comparison-of-column-oriented-access-methods
25. Custom-Scan APIとPG-Strom（4/4） PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 25 テーブルを一定サイズ毎に切り分けてGPUに転送、1万行程度を並列処理 大規模テーブル（数億件～、 数TB以上～）のスキャン 処理単位（64MB） ※数十万～百万行 File Read (GPU-Direct Storage) lo_shipmode=‘AIR’ 条件句をGPUで並列に評価 parts, supplier表と 結合条件に従って GPUで並列にJOIN処理 p_brand1列ごとに、 行数、lo_revenueの総和を GPUへ並列に集計 PG-Strom 動作をコントロール CPUへデータが渡る頃には、 数億件のデータが数千件に 縮減されていることも。 問い合わせ（SQL）の例 SELECT sum(lo_revenue), p_brand1 FROM lineorder, part, supplier WHERE lo_partkey = p_partkey AND lo_suppkey = s_suppkey AND lo_shipmode = ‘AIR’ AND s_region = 'AMERICA’ GROUP BY p_brand1 File Read (GPU-Direct Storage)
26. GPU-Direct SQLによる高速読み出し（1/4） PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 26 ホストシステム 物理アドレス空間 オペレーティングシステム 仮想アドレス空間 CUDA Managed Memory CUDA Device Memory PCI-E Bar1 領域 PCI-Eバス NVME-READ要求 • 読出し開始・ブロック番号 • 読み出すブロック数 • 転送先アドレス （ホスト物理アドレス）
27. GPU-Direct SQLによる高速読み出し（2/4） PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 27 $ sudo lspci -vv | less : 01:00.0 3D controller: NVIDIA Corporation GA100 [A100 PCIe 40GB] (rev a1) Subsystem: NVIDIA Corporation Device 145f Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 264 Region 0: Memory at f6000000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at 37000000000 (64-bit, prefetchable) [size=64G] Region 3: Memory at 38000000000 (64-bit, prefetchable) [size=32M] Capabilities: [60] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-) : $ nvidia-smi -q | less : GPU 00000000:01:00.0 Product Name : NVIDIA A100-PCIE-40GB Product Brand : NVIDIA Product Architecture : Ampere : FB Memory Usage Total : 40960 MiB Reserved : 514 MiB Used : 2309 MiB Free : 38138 MiB BAR1 Memory Usage Total : 65536 MiB Used : 1068 MiB Free : 64468 MiB :
28. GPU-Direct SQLによる高速読み出し（3/4） PCI-E Bus Buffer Copy Buffer Copy SCAN JOIN GROUP BY Storage Block Read 大量の”ゴミデータ”を含む PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 28
29. GPU-Direct SQLによる高速読み出し（4/4） P2P-DMAによるNVME-SSDからGPUへの直接データ読み出し PCI-E Bus SCAN JOIN GROUP BY Storage Block Read by NVIDIA GPUDirect Storage P2P-DMA P2P-DMA : Peer-to-Peer Direct Memory Access PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 29
30. GPU-Direct SQLの性能測定（1/2） ▌SSBMとは  TPC-Hデータセットの簡易版を使用  一個の巨大なファクトテーブル （lineorder）と、～数GB程度の マスターテーブルとの結合・集計  並列SQL処理系の性能測定によく 利用され、並列クエリ処理が容易。 ➔ 今回はSF=1000でデータセットを構築。 lineorderは875GB、60億行 例）SSBM Q2_2 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; Star Schema Benchmark (SSBM)を利用してSQL処理スループットを計測 ▌ベンチマーク環境 モデル：Supermicro AS2015CS-TNR CPU： AMD EPYC9254 (24C, 2.9GHz) x1 RAM： 16GB DDR5-4800[ECC] x 12 GPU： NVIDIA H100 [PCI-E; 80GB] x1 SSD： Intel (当時) D7-P5510 [3.84TB; PCIe 4.0] x8 OS： Red Hat Enterprise Linux 10.0 (kernel: 6.12.0-55.41.1.el10_0.x86_64) CUDA Toolkit 13.0 (driver: 580.95.05) DBMS： PostgreSQL v18.0 + PG-Strom v6.1 PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 30
31. GPU-Direct SQLの性能測定（2/2） PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 31 Query Execution with GPU-Direct SQL nvme7 nvme5 nvme2 nvme0 Query Execution with Filesystem on PostgreSQL Heap Tables nvme6 nvme4 nvme3 nvme1
32. 本日のアジェンダ 1. Apache Arrow/Parquet形式の概要 2. FDWと外部テーブル 3. GPU並列処理とPG-Strom 4. 想定利用シナリオとベンチマーク 5. クラウドGPUの利用 6. 先進的な機能 7. 今後のロードマップ PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 32
33. 想定利用シナリオ：Arrow/Parquetで保存したログデータの検索 heapテーブル ＜ Arrow/Parquetファイル なので、 巨大lineorderを含むSSBMでクエリでワークロード特性を測れる Manufacturing Home electronics Logistics arrow_fdw 外部テーブル heap テーブル 日次・週次でheapテーブルの データを ArrowやParquetに移行 （pg2arrow） パーティション 直近のデータは heapテーブルに 書込み 数日～数週分 数ヶ月～数年分 PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 33
34. Arrow/Parquetを含むSSBM ✓ Arrowの場合、NVME-SSD ➔ GPUへ直接データを流し込んでおり、むしろ GPUの計算能力の方がネックとなっている。 ✓ Parquetの場合、圧縮データをCPU上のlibparquetで展開せねばならない分、 （マルチスレッド処理とはいえ）CPUネックになっていると考えられる。 無圧縮の列データをフルスピードで並列演算器に流し込めば、速い。 PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 34
35. ボトルネックの考察 ▌Parquetが遅かったのはなぜ？  NVME-SSDを8本も束ねて使うような サーバはそうそう多くない。 ➔ ストレージがボトルネックではなかった。 ▌ボトルネックの考察  ストレージ帯域 ✓ 伝統的な性能ネック。NVME-SSDや列データの 利用によって解消しやすい。  圧縮データの展開 ✓ CPUサイクルを犠牲にしてストレージ帯域を ケチる。Parquetのアプローチ。  PCI-Eバス帯域 ✓ 細かな単位でCPUGPUのページ移動が発生 すると、GPUまでストールするので、地味に 注意が必要。  SQL処理（並列計算） ✓ GPU処理能力以上のペースでデータが入力さ れると、当然、GPUも処理ボトルネックに。 データのロード （ストレージ帯域） データのロード （PCI-Eバス帯域） SQL処理 （並列計算） 圧縮データの 展開 PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 35
36. 本日のアジェンダ 1. Apache Arrow/Parquet形式の概要 2. FDWと外部テーブル 3. GPU並列処理とPG-Strom 4. 想定利用シナリオとベンチマーク 5. クラウドGPUの利用 6. 先進的な機能 7. 今後のロードマップ PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 36
37. クラウドGPUはストレージが遅いのが玉に傷、、、 ✓ リーズナブルなところで、NVIDIA L40S GPU搭載インスタンスで試してみる。 NVIDIA L40S Generation: CC7.5 (Ada Lovelace) CUDA Cores: 18,176 (SM: 142) DRAM: 48GB (GDDR6) Bus: PCI-E 4.0 x16 lanes TDP: 300W PCI-E 4.0 x16 lanesだと、 理論値は32GB/s（約16GT/s x16） なので、GPUの帯域に見合った ストレージを用意するのは中々 大変。 ➔ GPU1台あたり、 NVME-SSD 4台程度が目安。 PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 37
38. GPUインスタンス上のArrow/Parquet（1/2） ▌PostgreSQL vs PG-Strom [heap]  ほとんど速度差なし。EBSの帯域上限8Gbps（1GB/s）に抑えられている。 ▌PG-Strom [heap] vs 列指向  被参照列のみのロードで済む分、列指向データがより顕著な高速化を達成している。 ▌PG-Strom [arrow] vs PG-Strom [parquet]  CPUでの圧縮データ展開というペナルティがあっても、なお高速なほどストレージが遅い。 （当然だが）I/Oネックの環境で列指向・圧縮は強い PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 38
39. GPUインスタンス上のArrow/Parquet（2/2）  無圧縮のArrowでは、GPUを十分に回せるほどのデータを供給できない。  この程度（1GB/s）の帯域なら、CPUで解凍したとしてもメリットの方が勝つ。  ただしGPU消費電力はやや控え目なので、仮想メモリ周りの動作は要調査。 GPU利用率にも注目 PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 39
40. 本日のアジェンダ 1. Apache Arrow/Parquet形式の概要 2. FDWと外部テーブル 3. GPU並列処理とPG-Strom 4. 想定利用シナリオとベンチマーク 5. クラウドGPUの利用 6. 先進的な機能 7. 今後のロードマップ PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 40
41. Arrow/Parquetファイルを作成する（1/4） $ python >>> import pandas >>> X = pandas.read_csv("datafile.csv") >>> X.dtypes 氏名 object 年齢 int64 生年月日 object メールアドレス object dtype: object >>> X.to_parquet("datafile.parquet", engine="pyarrow") $ psql postgres postgres=# IMPORT FOREIGN SCHEMA mydata FROM SERVER arrow_fdw INTO public OPTIONS (file '/home/kaigai/datafile.parquet'); IMPORT FOREIGN SCHEMA postgres=# ¥d mydata Foreign table "public.mydata" Column | Type | Collation | Nullable | Default | FDW options ----------------+--------+-----------+----------+---------+------------- 氏名 | text | | | | 年齢 | bigint | | | | 生年月日 | text | | | | メールアドレス | text | | | | Server: arrow_fdw FDW options: (file '/home/kaigai/datafile.parquet')  Python (Pandas + PyArrow) を使う例 PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 41
42. Arrow/Parquetファイルを作成する（2/4） PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 42 ▌pg2arrow を利用する ✓ PostgreSQLに投げたクエリの処理結果を Arrow / Parquet ファイルとして保存する。 ✓ PostgreSQLのテーブル構造を利用した効率的な並列処理（後述） ✓ （Parquetだけでなく）Arrowにもmin/max統計情報を埋め込む事ができる ✓ libpqバイナリプロトコルを用いた高速なデータ変換 $ pg2arrow -d postgres -c 'select * from lineorder where lo_discount = 0 order by lo_orderdate’ ¥ -o /opt/arrow/lineorder_nodiscount.arrow --progress worker-0: QUERY=[select * from lineorder where lo_discount = 0 order by lo_orderdate] pg2arrow: opened the output file '/opt/arrow/lineorder_nodiscount.arrow' 2025-11-11 22:03:41 Record Batch[0] nitems=1542729, length=268437720 at file offset=0 2025-11-11 22:03:46 Record Batch[1] nitems=1542729, length=268435808 at file offset=268437720 2025-11-11 22:03:51 Record Batch[2] nitems=1542729, length=268435808 at file offset=536873528 2025-11-11 22:03:55 Record Batch[3] nitems=1542729, length=268435808 at file offset=805309336 2025-11-11 22:04:00 Record Batch[4] nitems=1542729, length=268435808 at file offset=1073745144 2025-11-11 22:04:05 Record Batch[5] nitems=1375938, length=239414152 at file offset=1342180952 pg2arrow: wrote on '/opt/arrow/lineorder_nodiscount.arrow' total 6 record-batches, 9089583 items postgres=# IMPORT FOREIGN SCHEMA mytest FROM SERVER arrow_fdw INTO public OPTIONS (file '/opt/arrow/lineorder_nodiscount.arrow'); IMPORT FOREIGN SCHEMA
43. Arrow/Parquetファイルを作成する（3/4） PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 43 ▌pg2arrowの並列ダンプモード  Tid Range Scanを利用して、テーブルの一定範囲を特定のワーカに紐づける。  各ワーカーのスキャン範囲は相互に干渉しないため、ほぼリニアに処理性能が 伸びる。 $ ./pg2arrow -d postgres -t lineorder -n 4 -o /opt/arrow/lineorder_para.arrow --progress worker-0: QUERY=[SELECT * FROM lineorder WHERE lineorder.ctid < '(344827,0)'::tid] pg2arrow: opened the output file '/opt/arrow/lineorder_para.arrow' worker-3: QUERY=[SELECT * FROM lineorder WHERE lineorder.ctid >= '(344827,0)’ AND lineorder.ctid < '(689654,0)'] worker-1: QUERY=[SELECT * FROM lineorder WHERE lineorder.ctid >= '(689654,0)’ AND lineorder.ctid < '(1034481,0)'] worker-2: QUERY=[SELECT * FROM lineorder WHERE lineorder.ctid >= '(1034481,0)’ AND lineorder.ctid < '(1379308,0)'] worker-4: QUERY=[SELECT * FROM lineorder WHERE lineorder.ctid >= '(1379308,0)'] 2025-11-11 23:29:21 Record Batch[0] nitems=1542729, length=268437720 at file offset=0 2025-11-11 23:29:21 Record Batch[1] nitems=1542729, length=268435808 at file offset=268437720 : : : 2025-11-11 23:30:31 Record Batch[63] nitems=1542729, length=268435808 at file offset=16911457816 2025-11-11 23:30:33 Record Batch[64] nitems=1265344, length=220170784 at file offset=17179893624 pg2arrow: wrote on '/opt/arrow/lineorder_para.arrow' total 65 record-batches, 100000000 items
44. Arrow/Parquetファイルを作成する（4/4） Tid Range Scan Tid Range Scan Tid Range Scan (3000,0) (4500,0) (6000,0) (7500,0) pg2arrow worker worker select * from table where ctid >= ‘(3000,0)’ and ctid < ‘(4500)’ select * from table where ctid >= ‘(6000,0)’ and ctid < ‘(7500,0)’ select * from table where ctid >= ‘(4500,0)’ and ctid < ‘(6000,0)’ PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 44
45. RecordBatch: 長さの同じ配列を 列ごとに寄せ集め たもの。 Arrow/Parquetにおけるmin/max統計情報（1/3） PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 45 中身を読むまでもなく、明らかに検索条件にマッチしないブロックを読み飛ばす。 Header “ARROW1¥0¥0” Schema Definition Footer Schema Definition Custom Metadata Apache Arrow File RecordBatch-1 RecordBatch-k RecordBatch-N Terminator “ARROW1” Custom Metadata min_max_stats.ymd = “20210321,20210415” 各レコードバッチ毎に 最小値・最大値を カスタムメタデータと して埋め込む事ができる。 SELECT ymd, count(*) FROM arrow_table WHERE ymd <= 202103; RecordBatch-1 RecordBatch-k RecordBatch-N ymd最小値 <= 202103 ➔ true ymd最小値 <= 202103 ➔ false ymd最小値 <= 202103 ➔ false 独自機能 min/max統計情報に基づいて、 検索条件にマッチする行を含む ブロック（RecordBatch）だけを 読み出すよう最適化が可能。
46. Arrow/Parquetにおけるmin/max統計情報（2/3） ssbm=# EXPLAIN (analyze, costs off) SELECT count(*), sum(lo_revenue) FROM f_lineorder_sorted WHERE lo_orderdate BETWEEN 19940401 AND 19940630 AND lo_orderpriority = '2-HIGH’; QUERY PLAN --------------------------------------------------------------------------------------------------- Aggregate (actual time=334.706..334.708 rows=1 loops=1) -> Custom Scan (GpuPreAgg) on f_lineorder_sorted (actual time=334.691..334.694 rows=2 loops=1) GPU Projection: pgstrom.nrows(), pgstrom.psum((lo_revenue)::bigint) GPU Scan Quals: ((lo_orderdate >= 19940401) AND (lo_orderdate <= 19940630) AND (lo_orderpriority = '2-HIGH'::text)) ¥ [plan: 5999990000 -> 150000, exec: 232539843 -> 45396726] referenced: lo_orderdate, lo_orderpriority, lo_revenue Stats-Hint: (lo_orderdate >= 19940401), ¥ (lo_orderdate <= 19940630) [loaded: 77, skipped: 1910] file0: /opt/arrow/f_lineorder_sorted.arrow (read: 109.52GB, size: 496.69GB) GPU-Direct SQL: enabled (N=2,GPU0,1; direct=556444, ntuples=232539843) Planning Time: 2.028 ms Execution Time: 336.700 ms (10 rows) 明らかに検索条件に合致しない RecordBatch を読み飛ばしているのが分かる 検索条件にマッチしない事が明らかなら、 そもそも読み出す必要もない。 PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 46
47. Arrow/Parquetにおけるmin/max統計情報（3/3） ▌ArrowのCustomMetadata機能を用いて、各フィールドのメタデータ中に、レコードバッチ毎の最小値、 最大値を埋め込んでいる。 ▌これらの値を参照する事で、実際にデータをロードする前に、そのレコードバッチをロードすべきか どうか、判別する事ができる。 統計情報を含む Arrow ファイルの作成方法（--statオプション） $ pg2arrow -d ssbm -o /opt/arrow/f_lineorder_sorted.arrow --progress ¥ -c ‘SELECT * FROM lineorder ORDER BY lo_orderdate’ ¥ --stat=lo_orderdate : $ pg2arrow --dump /opt/arrow/f_lineorder_sorted.arrow [Footer] {Footer: version=V4, schema={Schema: endianness=little, fields=[ {Field: name="lo_orderkey", nullable=true, type={Int64}, children=[], custom_metadata=[]}, {Field: name="lo_linenumber", nullable=true, type={Int32}, children=[], custom_metadata=[]}, {Field: name="lo_custkey", nullable=true, type={Int32}, children=[], custom_metadata=[]}, {Field: name="lo_partkey", nullable=true, type={Int32}, children=[], custom_metadata=[]}, {Field: name="lo_suppkey", nullable=true, type={Int32}, children=[], custom_metadata=[]}, {Field: name="lo_orderdate", nullable=true, type={Int32}, children=[], custom_metadata=[{KeyValue: key="min_values" value="19920101,19920102,19920103,19920104, 19920105,19920107,19920108,...”}, {KeyValue: key="max_values" value="19920102,19920103,19920104,19920105, 19920107,19920108,19920109,...”}]}, {Field: name="lo_orderpriority", nullable=true, type={Utf8}, children=[], custom_metadata=[]}, : : : PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 47
48. Arrow_FdwのVirtual Column機構（1/5） ログデータ トランザクションデータ （PostgreSQL Heap形式） 肥大化 古いデータを Arrow形式に変換 pg2arrow: SELECT * FROM my_table WHERE ymd >= ‘2023-01-01’ AND ymd < ‘2024-01-01’ すごく古いデータは、gzipなどで固めて バックアップ用ストレージへ テーブルパーティション mytable_2022.arrow mytable_2023.arrow PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 48
49. Arrow_FdwのVirtual Column機構（2/5） $ ls -l /opt/arrow/monthly/ total 337074788 -rw-r--r--. 1 kaigai kaigai 967199318 Dec 14 00:17 f_lineorder_199301_AIR.arrow -rw-r--r--. 1 kaigai kaigai 966790870 Dec 14 00:18 f_lineorder_199301_FOB.arrow -rw-r--r--. 1 kaigai kaigai 978921494 Dec 14 00:19 f_lineorder_199301_MAIL.arrow -rw-r--r--. 1 kaigai kaigai 978374102 Dec 14 00:20 f_lineorder_199301_RAIL.arrow -rw-r--r--. 1 kaigai kaigai 978857494 Dec 14 00:22 f_lineorder_199301_SHIP.arrow -rw-r--r--. 1 kaigai kaigai 989774806 Dec 14 00:23 f_lineorder_199301_TRUCK.arrow -rw-r--r--. 1 kaigai kaigai 873871318 Dec 14 00:24 f_lineorder_199302_AIR.arrow -rw-r--r--. 1 kaigai kaigai 873760598 Dec 14 00:25 f_lineorder_199302_FOB.arrow -rw-r--r--. 1 kaigai kaigai 883919318 Dec 14 00:26 f_lineorder_199302_MAIL.arrow -rw-r--r--. 1 kaigai kaigai 884077078 Dec 14 00:27 f_lineorder_199302_RAIL.arrow -rw-r--r--. 1 kaigai kaigai 883877142 Dec 14 00:28 f_lineorder_199302_SHIP.arrow -rw-r--r--. 1 kaigai kaigai 893281622 Dec 14 00:30 f_lineorder_199302_TRUCK.arrow -rw-r--r--. 1 kaigai kaigai 967705878 Dec 14 00:31 f_lineorder_199303_AIR.arrow -rw-r--r--. 1 kaigai kaigai 967453078 Dec 14 00:32 f_lineorder_199303_FOB.arrow -rw-r--r--. 1 kaigai kaigai 978963094 Dec 14 00:33 f_lineorder_199303_MAIL.arrow -rw-r--r--. 1 kaigai kaigai 978954454 Dec 14 00:34 f_lineorder_199303_RAIL.arrow -rw-r--r--. 1 kaigai kaigai 978754966 Dec 14 00:36 f_lineorder_199303_SHIP.arrow -rw-r--r--. 1 kaigai kaigai 989493718 Dec 14 00:37 f_lineorder_199303_TRUCK.arrow -rw-r--r--. 1 kaigai kaigai 936397334 Dec 14 00:38 f_lineorder_199304_AIR.arrow -rw-r--r--. 1 kaigai kaigai 936229014 Dec 14 00:39 f_lineorder_199304_FOB.arrow -rw-r--r--. 1 kaigai kaigai 946560726 Dec 14 00:40 f_lineorder_199304_MAIL.arrow -rw-r--r--. 1 kaigai kaigai 947162198 Dec 14 00:42 f_lineorder_199304_RAIL.arrow -rw-r--r--. 1 kaigai kaigai 946814166 Dec 14 00:43 f_lineorder_199304_SHIP.arrow -rw-r--r--. 1 kaigai kaigai 957260310 Dec 14 00:44 f_lineorder_199304_TRUCK.arrow -rw-r--r--. 1 kaigai kaigai 967627350 Dec 14 00:45 f_lineorder_199305_AIR.arrow -rw-r--r--. 1 kaigai kaigai 967433046 Dec 14 00:46 f_lineorder_199305_FOB.arrow 習慣的に、ファイル名に “yyyymmdd” を付加したりしますよね？ PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 49
50. Arrow_FdwのVirtual Column機構（3/5） ssbm=# IMPORT FOREIGN SCHEMA f_lineorder_vcol FROM SERVER arrow_fdw INTO public OPTIONS (dir '/opt/arrow/monthly', pattern 'f_lineorder_@{year_month}_${shipmode}.arrow'); IMPORT FOREIGN SCHEMA ssbm=# ¥d f_lineorder_vcol Foreign table "public.f_lineorder_vcol" Column | Type | Collation | Nullable | Default | FDW options --------------------+--------------+-----------+----------+---------+------------------------ lo_orderkey | bigint | | | | lo_linenumber | integer | | | | lo_custkey | integer | | | | lo_partkey | integer | | | | lo_suppkey | integer | | | | lo_orderdate | integer | | | | lo_orderpriority | text | | | | lo_shippriority | character(1) | | | | lo_quantity | integer | | | | lo_extendedprice | integer | | | | lo_ordertotalprice | integer | | | | lo_discount | integer | | | | lo_revenue | integer | | | | lo_supplycost | integer | | | | lo_tax | integer | | | | lo_commit_date | text | | | | lo_shipmode | text | | | | year_month | bigint | | | | (virtual 'year_month') shipmode | text | | | | (virtual 'shipmode') Server: arrow_fdw FDW options: (dir '/opt/arrow/monthly', pattern 'f_lineorder_@{year_month}_${shipmode}.arrow') 実はArrowファイル上には存在していない列。 ファイル名の一部を列の値として読み出す 事ができる。 @{xxxx} … 数値列（bigint） ${xxxx} … 文字列（text） PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 50
51. Arrow_FdwのVirtual Column機構（4/5） ssbm=# explain (analyze, costs off) select sum(lo_extendedprice*lo_discount) from f_lineorder_vcol where year_month = 199401 and lo_discount between 4 and 6 and lo_quantity between 26 and 35; QUERY PLAN -------------------------------------------------------------------------------------------------- Aggregate (actual time=123.326..123.328 rows=1 loops=1) -> Custom Scan (GpuPreAgg) on f_lineorder_vcol (actual time=123.315..123.317 rows=2 loops=1) GPU Projection: pgstrom.psum(((lo_extendedprice * lo_discount))::bigint) GPU Scan Quals: ((lo_discount >= 4) AND (lo_discount <= 6) AND (lo_quantity >= 26) AND (lo_quantity <= 35) AND (year_month = 199401)) [plan: 3914078000 -> 489, exec: 77300885 -> 4217587] referenced: lo_quantity, lo_extendedprice, lo_discount, year_month Stats-Hint: (year_month = 199401) [loaded: 28, skipped: 1416] file0: /opt/arrow/monthly/f_lineorder_199411_FOB.arrow (read: 122.30MB, size: 892.79MB) file1: /opt/arrow/monthly/f_lineorder_199406_AIR.arrow (read: 122.28MB, size: 892.68MB) file2: /opt/arrow/monthly/f_lineorder_199709_FOB.arrow (read: 122.38MB, size: 893.37MB) file3: /opt/arrow/monthly/f_lineorder_199401_RAIL.arrow (read: 126.33MB, size: 932.76MB) file4: /opt/arrow/monthly/f_lineorder_199508_TRUCK.arrow (read: 126.39MB, size: 943.73MB) : : : : file360: /opt/arrow/monthly/f_lineorder_199405_SHIP.arrow (read: 126.43MB, size: 933.48MB) GPU-Direct SQL: enabled (N=2,GPU0,1; direct=113261, ntuples=77300885) Planning Time: 4.772 ms Execution Time: 128.046 ms min/max統計情報と同じ仕組みで、明らかにマッチしないRecord Batchを読み飛ばし PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 51
52. Arrow_FdwのVirtual Column機構（5/5） ▌どういった条件句で利用できるか  『仮想列 > 定数』のような大小比較演算  『仮想列 = 定数』のような等価演算 ※ min/max統計情報、virtual columnで共通 ※ 文字列（text型）の場合は等価演算のみ ▌今後、対応を拡大したいユースケース  仮想列 IN (値1, 値2, 値3, …) ➔ PostgreSQL内部的には、仮想列 = 値1 OR 仮想列 = 値2 OR 仮想列 = 値3 OR … と等価  Custom Metadataの特定のキー値を virtual column 扱いにする ➔ 例えば、Arrowファイルを生成したツールやデータソースなど PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 52
53. 本日のアジェンダ 1. Apache Arrow/Parquet形式の概要 2. FDWと外部テーブル 3. GPU並列処理とPG-Strom 4. 想定利用シナリオとベンチマーク 5. クラウドGPUの利用 6. 先進的な機能 7. 今後のロードマップ PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 53
54. オブジェクトストレージへの対応 クラウド向け機能強化：S3ストレージからの直接読み出し S3を使う事を考える。 性能を律速するのはN/W帯域幅 ↓ GPU1台あたり4GB/s (16xlarge) GPU4台あたり25GB/s (24xlarge) オンプレミス環境に比べれば 心許ないが、密度の高い列データ であれば、そこそこのバランス。 EBS帯域幅で律速 N/W帯域幅で律速 EBSストレージ （読み書き双方） S3オブジェクトストレージ （読み込みのみ） PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 54
55. リモートGPUの利用（1/2） GPU-Serviceがリモートマシンでも支障はないのでは？ 55 PostgreSQL Backend PG-Strom v5.0 GPU PG-Strom PostgreSQL Backend Background Worker CUDA Context GPU Service (multi- threads) Postmaster Process working memory fork(2) PG-Strom Local connection to GPU Service ✓ CUDA Context初期化時間、およびワーキング メモリ（数百MB～1GB）の節約。 ✓ CUDA Contextスイッチの削減とGPU使用率改善 PostgreSQL Backend PG-Strom PostgreSQL Backend Postmaster Process fork(2) PG-Strom PG-Strom v7.0(?) Remote Process GPU Service GPU NVME Cache Remote Process GPU Service GPU NVME Cache 共有ファイル システム (NFS, Lusterなど) コンテナなど利用して、 バッチ処理の時間帯だけ GPUサーバ上で稼働。 TCP/IPで接続 遠隔サーバも可能 PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～
56. リモートGPUの利用（2/2） PostgreSQL RDSサービスからpostgres_fdw経由で接続 PostgreSQL RDS インスタンス こちらは手出しできない GPUサーバ PG-Strom コンテナ バッチ実行中だけ GPUを使えばよい。 S3オブジェクト ストレージ pg2arrow PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 56
57. Arrow/Parquetを使ってやりたい事（3/3） Arrow/ParquetのシンプルさとGPUの処理能力を組み合わせ、 使い慣れたPostgreSQLから自然な大量データ処理を可能にする。 PostgreSQL RDS インスタンス GPUサーバ PG-Strom コンテナ オンデマンドでの GPU利用で、 コストを抑える S3オブジェクト ストレージ PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 57 Manufacturing Home electronics 使い慣れたPostgreSQLで、 楽々大量データ処理 Log collector ファイルとして 保存された 大量のログデータ
58. PostgreSQL Conference Japan 2025 ～PostgreSQL で列データ”ファイル”を利用する～ 58 Ｑ＆Ａ
59. オモシロ技術を、カタチにする。