このトピックでは、ヒープテーブルの先読み、ヒープテーブルの事前拡張、およびインデックス作成の事前拡張について説明します。
前提条件
PolarDB for PostgreSQL (Compatible with Oracle) クラスターは、次のエンジンを実行します。
Oracle 2.0 (バージョン2.0.14.1.0以降)
次のステートメントを実行して、 PolarDB for PostgreSQL (Compatible with Oracle) クラスターのマイナーバージョンを照会できます。
SHOW polar_version;
背景情報
PolarDB for PostgreSQL (Compatible with Oracle) は、ファイルシステムとしてPolarFileSystem (PFS) を使用します。 ext4などのスタンドアロンファイルシステムとは異なり、PFSはページ拡張中のメタデータ更新のオーバーヘッドが高くなります。 PFSでは、ページ拡張の最小サイズは4 MBの倍数である必要があります。 ただし、PostgreSQLでは、ページ拡張の最小サイズは8 MBの倍数である必要があります。 これはPFSには適しておらず、テーブルの書き込みやインデックスの作成のパフォーマンスが低下します。 PFSは、大きなページを読み取るためのI/O効率が高い。
上記の特性に基づいて、 PolarDB for PostgreSQL (Compatible with Oracle) は、ヒープテーブルの先読み、ヒープテーブルの事前拡張、およびインデックス作成の事前拡張の機能を提供するため、 PolarDB for PostgreSQL (Compatible with Oracle) はPFSのパフォーマンスを向上させます。
概要
ヒープテーブルの先読み
PostgreSQLがヒープテーブルを読み取るとき、ファイルシステムからメモリバッファプールに8 KBの単位でページを読み取ります。 PFSは、少量のデータを有するI/O動作に対して効率的ではない。 したがって、 PolarDB for PostgreSQL (Compatible with Oracle) は、ヒープテーブルの先読みを使用してPFSに適応します。
2つ以上のページが読み取られる場合、バッチ先読みがトリガされ、128 KBのデータがバッファプールへの各I/Oにおいて読み取られる。 一括先読みにより、シーケンシャルスキャンとバキュームのパフォーマンスが2倍になり、インデックス作成のパフォーマンスが18% に向上します。
ヒープテーブルの事前拡張
PostgreSQLでは、テーブルスペースの拡張中に8 KBのページが1つずつ適用および拡張されます。 PostgreSQLがバッチページ拡張をサポートしている場合でも、Nページを拡張するタスクではN個のI/O操作が必要です。 これは、4 MBの最小ページ拡張サイズを使用するPFSには適していません。 したがって、 PolarDB for PostgreSQL (Compatible with Oracle) はヒープテーブルの拡張前を使用します。
ヒープテーブル拡張では、I/Oは毎回4 MBのページを拡張します。 テーブルが頻繁に書き込まれるシナリオ (データのロード時など) では、パフォーマンスを2倍にすることができます。
インデックス作成前の拡張
インデックス作成の事前拡張は、ヒープテーブルの事前拡張に似ています。 インデックス作成前拡張は、特にPFSのインデックス作成プロセスを最適化します。 インデックス作成前の拡張では、I/Oは毎回4 MBのページを拡張します。 これにより、30% によるインデックス作成のパフォーマンスが向上します。
説明インデックス作成前拡張は、Bツリーインデックスのみをサポートします。 他のインデックスタイプはサポートされていません。
制御ポリシー機能の動作
ヒープテーブルの先読み
ヒープテーブルの先読みは4つのステップで実装されます。
バッファプールからN個のバッファを申請します。
palloc
を使用して、サイズがN × ページサイズ
のメモリ内のスペースを申請し、スペースにp
という名前を付けます。PFSを使用して、ヒープテーブルから
N × Pageサイズ
のデータを読み取り、そのデータをp
にコピーします。p
のNページを、バッファプールから申請するN個のバッファにコピーします。
後続の読み出し動作は、バッファに直接ヒットする。 次の図は、データの流れを示しています。
ヒープテーブルの事前拡張
ヒープテーブルの事前拡張は3つのステップで実装されます。
ファイルシステムのページ拡張をトリガーせずに、バッファプールからN個のバッファを申請します。
PFSファイル書き込みインターフェイスを使用してバッチページ拡張を実行し、オールゼロページを書き込みます。
ページを1つずつ初期化し、ページの利用可能なスペースを特定し、拡張前プロセスを終了します。
インデックス作成前の拡張
インデックス作成の事前拡張は、ヒープテーブルの事前拡張と同様に実装されますが、バッファに適用する必要はありません。 以下の手順を実行します。
PFSファイル書き込みインターフェイスを使用してバッチページ拡張を実行し、オールゼロページを書き込みます。
バッファプールに構築されているインデックスページをファイルシステムに書き込みます。
Usage
ヒープテーブルの先読み
polar_bulk_read_size
パラメーターは、ヒープテーブルの先読みに関連しています。 ヒープテーブルの先読みはデフォルトで有効になっています。 パラメーターのデフォルト値は128 KBです。説明パラメーター値を変更しないことを推奨します。 128 KBはPFSの最適値です。
ヒープテーブルの先読みを無効にします。
ALTER SYSTEM SET polar_bulk_read_size = 0; SELECT pg_reload_conf();
ヒープテーブルの先読みを有効にし、先読みサイズを128 KBに設定します。
ALTER SYSTEM SET polar_bulk_read_size = '128 KB'; SELECT pg_reload_conf();
ヒープテーブルの事前拡張
polar_bulk_extend_size
パラメーターは、ヒープテーブルの拡張前に関連しています。 ヒープテーブルの事前拡張はデフォルトで有効になっています。 パラメータのデフォルト値は4 MBです。説明パラメーター値を変更しないことを推奨します。 PFSの最適値は4 MBです。
拡張前のヒープテーブルを無効にします。
ALTER SYSTEM SET polar_bulk_extend_size = 0; SELECT pg_reload_conf();
ヒープテーブルの事前拡張を有効にし、事前拡張サイズを4 MBに設定します。
ALTER SYSTEM SET polar_bulk_extend_size='4MB'; SELECT pg_reload_conf();
インデックス作成前の拡張
polar_index_create_bulk_extend_size
パラメーターは、インデックス作成前の拡張に関連しています。 インデックス作成前拡張はデフォルトで有効になっています。 パラメータのデフォルト値は4 MBです。説明パラメーター値を変更しないことを推奨します。 PFSの最適値は4 MBです。
インデックス作成前の拡張機能を無効にします。
ALTER SYSTEM SET polar_index_create_bulk_extend_size = 0; SELECT pg_reload_conf();
インデックス作成前拡張を有効にし、拡張前サイズを4 MBに設定します。
ALTER SYSTEM SET polar_index_create_bulk_extend_size='4MB'; SELECT pg_reload_conf();
性能比較
ヒープテーブルの先読み、ヒープテーブルの事前拡張、およびインデックス作成の事前拡張のパフォーマンス改善結果を示すために、PostgreSQL 14を実行する PolarDB for PostgreSQL (Compatible with Oracle) クラスターでパフォーマンステストが実行されます。
クラスター仕様: 8コアと32 GBのメモリ。
テスト環境: 400 GB pgbench。
ヒープテーブルの先読み
400 GBテーブルでの真空のパフォーマンス比較:
400 GBテーブルでのシーケンシャルスキャンのパフォーマンス比較:
結論:
ヒープテーブルの先読みは、真空およびシーケンシャルスキャンのパフォーマンスを2倍または3倍にします。
先読みサイズがデフォルト値の128 KBを超えると、パフォーマンスの大幅な改善は発生しません。
ヒープテーブルの事前拡張
400 GBテーブルでのデータ読み込みのパフォーマンス比較:
結論:
ヒープテーブルの拡張前は、データ読み込みのパフォーマンスが2倍になります。
拡張前のサイズがデフォルト値の4 MBを超えると、パフォーマンスの大幅な改善は発生しません。
インデックス作成前の拡張
400 GBテーブルにインデックスを作成する場合のパフォーマンス比較:
結論:
インデックス作成前の拡張により、インデックス作成のパフォーマンスが30% 向上します。
拡張前のサイズがデフォルト値の4 MBを超えると、パフォーマンスの大幅な改善は発生しません。