PolarDB for PostgreSQL は、一括インポートインフラストラクチャを提供します。
適用範囲
この機能は、ご利用の PolarDB for PostgreSQL クラスターが以下のいずれかのマイナーエンジンバージョンを実行している場合にご利用いただけます。
PostgreSQL 18、マイナーエンジンバージョン 2.0.18.0.1.0 以降
PostgreSQL 17、マイナーエンジンバージョン 2.0.17.2.1.0 以降
PostgreSQL 16、マイナーエンジンバージョン 2.0.16.6.2.0 以降
PostgreSQL 15、マイナーエンジンバージョン 2.0.15.12.4.0 以降
PostgreSQL 14、マイナーエンジンバージョン 2.0.14.13.28.0 以降
PolarDB コンソールで、または
SHOW polardb_version;文を実行して、クラスターのマイナーエンジンバージョンを確認できます。ご利用のクラスターが古いマイナーエンジンバージョンを実行している場合は、データベースエンジンに応じて以下のいずれかのソリューションを使用してください。
PostgreSQL 15 以降： マイナーエンジンバージョンをアップグレードします。
PostgreSQL 14 以前： 一括書き込みのためにマテリアライズドビューを作成またはリフレッシュします。
背景情報
まだコミットされていないトランザクション内で新しいオブジェクトにデータを一括インポートする場合、トランザクション分離のため、そのオブジェクトは他のプロセスからは見えません。PolarDB for PostgreSQL はこの特性を活用して、一括データインポートプロセスのさまざまなレイヤーで的を絞った最適化を実装しています。
PolarDB for PostgreSQL は、現在のプロセス内でのみ可視なオブジェクトに対して、汎用的な一括インポートインフラストラクチャを提供します。このインフラストラクチャは、バッファー管理のバイパス、ページの一括構築、ストレージページの一括拡張、先行書き込みログ (WAL) レコードの一括記録、同期パスの非同期操作への変換により、一括インポートのパフォーマンスを大幅に向上させます。
注意事項
次の構文はこのインフラストラクチャを使用します：
CREATE INDEXREINDEXVACUUM FULLALTER TABLE SET TABLESPACECREATE MATERIALIZED VIEWREFRESH MATERIALIZED VIEW- 説明
CREATE TABLE AS 文または SELECT INTO 文が一括インポートインフラストラクチャを使用するかどうかは、
wal_levelパラメーターの値に依存します。このパラメーターがlogicalより低い値に設定されている場合、文はデフォルトで一括インポートを使用します。このパラメーターがlogicalに設定されている場合、文はデフォルトで Multi-Insert Table AM インフラストラクチャ の一括挿入インターフェイスを使用します。
仕組み
バッファー管理のバイパス
インポートされたデータは、トランザクションがコミットされる前に他のプロセスから見える必要がないため、ページ構築中にプロセスのプライベートメモリで直接処理できます。これにより、共有メモリのバッファープールからのページ割り当てが回避されます。バッファー管理をバイパスすることで、ロックリソースの競合を効果的に回避し、ページ構築の効率を大幅に向上させます。
ページの一括拡張
従来の一括インポートメカニズムでは、通常、データをページごとに書き込みます。ページがいっぱいになるたびに、ストレージ管理レイヤーを通じて単一ページの拡張がリクエストされます。クラウドストレージのレイテンシが高いため、これらのページごとの拡張操作は、メインパスで大きな I/O 待機オーバーヘッドを引き起こします。PolarDB for PostgreSQL は、プロセスのプライベートメモリ内で複数ページのデータを事前集約します。蓄積されたデータがしきい値に達すると、システムはストレージ管理レイヤーを通じてページの一括拡張を実行します。これにより、単一ページの拡張によるレイテンシが効果的に償却されます。
WAL ログの一括記録
従来の一括インポートメカニズムでは、ヒープテーブルとインデックスのインポート操作の両方で、通常、データを 1 行ずつ記録します。これは、各行に対して個別の WAL レコードが生成されることを意味します。プライベートメモリでのページ構築中、プロセスは複数の行を単一のページに統合し、永続化のために複数のページを事前集約します。したがって、PolarDB for PostgreSQL は、XLOG_FPI タイプの WAL レコードを使用して、構築後のこれらのページを一括で記録します。このタイプの WAL レコードには、ページ上の増分変更ではなく、ページ全体のデータが含まれます。従来の 1 行ずつの記録方法と比較して、このアプローチはよりコンパクトで、WAL のメタデータオーバーヘッドを効果的に削減します。
メインパスの非同期化
トランザクションがコミットされると、プライベートメモリで構築されたページは他のプロセスから見えるようになる必要があります。理論的には、トランザクションがコミットされる前に、構築されたすべてのページが永続化されることを保証する必要がありますが、これではメインパスのレイテンシが大幅に増加してしまいます。この問題に対処するため、PolarDB for PostgreSQL は、ページの一括構築が完了した後、すぐにページをバッファープールにコピーし、ダーティページとしてマークします。これにより、コミットが迅速にリターンできるようになります。その後、バックグラウンドの並列ダーティページフラッシュプロセスが、非同期でページをストレージに書き込みます。これにより、PolarDB の高スループットなダーティページフラッシュ機能が活用され、ページ構築とバックグラウンドフラッシュの並列処理が可能になります。
このメカニズムは、システムクラッシュが発生した場合のデータ整合性も保証します。FPI タイプの WAL レコードはすでに記録されているため、コミットされたデータのリカバリが保証されます。
使用方法
polar_bulk_write_maxpages パラメーターは、プロセスのプライベートメモリで事前集約するページの最大数を制御します。事前集約されたページの数がこの値に達すると、ページの一括拡張、WAL の一括記録、およびフラッシュのためのバッファープールへのページのコピーがトリガーされます。デフォルト値は最適化されており、通常は変更する必要はありません。
SHOW polar_bulk_write_maxpages;
polar_bulk_write_maxpages
---------------------------
1MB
(1 row)