すべてのプロダクト
Search
ドキュメントセンター

PolarDB:先読みと事前拡張

最終更新日:Jun 27, 2024

このトピックでは、ヒープテーブルの先読み、ヒープテーブルの事前拡張、およびインデックス作成の事前拡張について説明します。

前提条件

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つのステップで実装されます。

    1. バッファプールからN個のバッファを申請します。

    2. pallocを使用して、サイズがN × ページサイズのメモリ内のスペースを申請し、スペースにpという名前を付けます。

    3. PFSを使用して、ヒープテーブルからN × Pageサイズのデータを読み取り、そのデータをpにコピーします。

    4. pのNページを、バッファプールから申請するN個のバッファにコピーします。

    後続の読み出し動作は、バッファに直接ヒットする。 次の図は、データの流れを示しています。堆表预读

  • ヒープテーブルの事前拡張

    ヒープテーブルの事前拡張は3つのステップで実装されます。

    1. ファイルシステムのページ拡張をトリガーせずに、バッファプールからN個のバッファを申請します。

    2. PFSファイル書き込みインターフェイスを使用してバッチページ拡張を実行し、オールゼロページを書き込みます。

    3. ページを1つずつ初期化し、ページの利用可能なスペースを特定し、拡張前プロセスを終了します。

  • インデックス作成前の拡張

    インデックス作成の事前拡張は、ヒープテーブルの事前拡張と同様に実装されますが、バッファに適用する必要はありません。 以下の手順を実行します。

    1. PFSファイル書き込みインターフェイスを使用してバッチページ拡張を実行し、オールゼロページを書き込みます。

    2. バッファプールに構築されているインデックスページをファイルシステムに書き込みます。

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テーブルでの真空のパフォーマンス比較: vacuum性能对比

    • 400 GBテーブルでのシーケンシャルスキャンのパフォーマンス比較: seqscan性能对比

    結論:

    • ヒープテーブルの先読みは、真空およびシーケンシャルスキャンのパフォーマンスを2倍または3倍にします。

    • 先読みサイズがデフォルト値の128 KBを超えると、パフォーマンスの大幅な改善は発生しません。

  • ヒープテーブルの事前拡張

    400 GBテーブルでのデータ読み込みのパフォーマンス比較: 数据装载性能对比

    結論:

    • ヒープテーブルの拡張前は、データ読み込みのパフォーマンスが2倍になります。

    • 拡張前のサイズがデフォルト値の4 MBを超えると、パフォーマンスの大幅な改善は発生しません。

  • インデックス作成前の拡張

    400 GBテーブルにインデックスを作成する場合のパフォーマンス比較: 创建索引性能对比

    結論:

    • インデックス作成前の拡張により、インデックス作成のパフォーマンスが30% 向上します。

    • 拡張前のサイズがデフォルト値の4 MBを超えると、パフォーマンスの大幅な改善は発生しません。