PG-Strom v2.2リリース
PG-Strom Development Team (1-May-2019)
概要
PG-Strom v2.2における主要な機能強化は以下の通りです。
- テーブルパーティションへの対応
- Arrow_Fdwによる列指向ストアのサポート
- ビルド済みGPUバイナリへの対応
- Jsonbデータ型の対応
- 可変長データ型を返すGPU関数の対応
- GPUメモリストア(Gstore_Fdw)のソート対応
- NVMEoFへの対応(実験的機能)
動作環境
- PostgreSQL v9.6, v10, v11
- CUDA Toolkit 10.1
- CUDA ToolkitのサポートするLinuxディストリビューション
- Intel x86 64bit アーキテクチャ(x86_64)
- NVIDIA GPU CC 6.0 以降 (Pascal以降)
新機能
- テーブルパーティションへの対応
- マルチGPU構成の場合、パーティションを構成する子テーブルの物理的なGPUとの距離に応じて最適なGPUを選択するようになりました。NVME-oF環境などPCIeバスの構成だけでは最適距離を判断できない場合は、DB管理者は
pg_strom.nvme_distance_map
パラメータを用いて対応関係を設定する事ができます。 - 非パーティションテーブルとのJOIN時、パーティション子テーブルと非パーティションテーブルとのJOINを行った後、各子テーブルの処理結果を結合するような実行計画を生成できるようになりました。本機能は Asymmetric Partition-wise JOIN という名称でPostgreSQL v13の本体機能へと提案されています。
- マルチGPU構成の場合、パーティションを構成する子テーブルの物理的なGPUとの距離に応じて最適なGPUを選択するようになりました。NVME-oF環境などPCIeバスの構成だけでは最適距離を判断できない場合は、DB管理者は
- Arrow_Fdwによる列指向ストアのサポート
- 外部テーブル経由でApache Arrow形式ファイルの読み出しに対応するようになりました。
- SSD-to-GPU Direct SQLを用いたApache Arrowの読み出しとSQL実行にも対応しています。
- ビルド済みGPUバイナリへの対応
- SQLからGPUバイナリコードを生成する際、従来は動的に変更する要素のない関数群(ライブラリ関数に酷似)も含めてCUDA Cのソースコードを生成し、それをNVRTC(NVIDIA Run-Time Compiler)を用いてビルドしていました。しかし、一部の複雑な関数の影響でビルド時間が極端に長くなるという問題がありました。
- v2.2において、静的な関数群は事前にビルドされ、SQLから動的に生成する部分のみを実行時にコンパイルするように変更されました。これにより、GPUバイナリの生成時間が大幅に減少する事となりました。
- JSONBデータ型の対応
- GPU側でJSONBオブジェクトの子要素を参照し、
numeric
やtext
値として条件句などで利用できるようになった。
- GPU側でJSONBオブジェクトの子要素を参照し、
- 可変長データ型を返すGPU関数の対応
textcat
など可変長データ型を返すSQL関数をGPU側で実装する事ができるようになった。
- GPUメモリストア(Gstore_Fdw)のソート対応
- PL/CUDAのデータソースとして利用する以外に、GPUメモリストアからデータを読み出して実行するSQLをGPUで実行する事ができるようになりました。
- 対応しているワークロードはGpuScanおよびGpuSortの2種類で、JOINおよびGROUP BYにはまだ対応していません。
- リグレッションテストの追加
- 簡易なテストのため、リグレッションテストを追加しました。
- NVME-oFへの対応(実験的機能)
- NVME-over-Fabricを用いてマウントされたリモートのNVMEディスクからのSSD-to-GPU Direct SQLに対応しました。ただし、Red Hat Enterprise Linux 7.x / CentOS 7.xでは
nvme_rdma
ドライバの入れ替えが必要となり、現在のところ実験的機能という形になっています。
- NVME-over-Fabricを用いてマウントされたリモートのNVMEディスクからのSSD-to-GPU Direct SQLに対応しました。ただし、Red Hat Enterprise Linux 7.x / CentOS 7.xでは
将来廃止予定の機能
-
PostgreSQL v9.6サポート
- PostgreSQL v9.6のCustomScan APIには、動的共有メモリ(DSM)の正しいハンドリングに必要な幾つかのAPIが欠けており、実行時統計情報の採取などが不可能でした。
- また、内部的に式表現(Expression)を保持するための方法にも変更が加えられている事から、少なくない箇所で
#if ... #endif
ブロックが必要となり、コードの保守性を損なっていました。 - これらの問題により、PostgreSQL v9.6サポートは本バージョンが最後となります。PG-StromをPostgreSQL v9.6でお使いの場合は、早期にPostgreSQL v11へと移行される事をお勧めします。
-
Gstore_Fdw外部テーブルのpgstromフォーマット
- GPUメモリストア上のデータ形式は、元々PL/CUDAのデータソースとして利用するために設計された独自の列形式で、可変長データやnumericデータ型の表現はPostgreSQLのものをそのまま利用していました。
- その後、GPU上でのデータ交換用共通形式として、Apache Arrow形式を元にしたNVIDIA RAPIDS(cuDF)が公開され、多くの機械学習ソフトウェアやPythonでのソフトウェアスタックなど対応が強化されつつあります。
- 今後、PG-StromはGstore_Fdwの内部データ形式をcuDFと共通のフォーマットに変更し、これら機械学習ソフトウェアとの相互運用性を改善します。コードの保守性を高くするため、従来の独自データ形式は廃止となります。
廃止された機能
- インメモリ列キャッシュ
- ユースケースを分析した結果、多くのケースではArrow_Fdwで十分に代替可能なワークロードである事が分かりました。重複機能であるため、インメモリ列キャッシュは削除されました。