PolarDB:一括インポートインフラストラクチャ

バッファ管理のバイパス

新しく作成されたオブジェクトにインポートされたデータは、トランザクションがコミットされ、ページ構築フェーズ中にプロセスプライベートメモリに直接書き込まれるまで、他のプロセスには見えません。これにより、共有 バッファープール がバイパスされ、バッファープール ロックの競合が回避され、ページ構築効率が大幅に向上します。

ページの一括拡張

従来の一括インポートメカニズムは、通常、ページごとの書き込みモードを使用します。ページがいっぱいになるたびに、システムはストレージ管理レイヤーインターフェイスを介して単一ページの拡張をトリガーします。クラウドストレージの待ち時間が長いため、このようなページごとの拡張操作は、メインの実行パスに大きな I/O 待機オーバーヘッドをもたらす可能性があります。この問題に対処するために、PolarDB for PostgreSQL は、プロセスのプライベートメモリ内の複数ページのデータを事前に集約することでプロセスを最適化します。事前に集約されたページ数が事前定義されたしきい値に達すると、システムはストレージ管理レイヤーインターフェイスを介してバッチページ拡張を実行します。これにより、頻繁な単一ページ拡張によるオーバーヘッドが削減されます。

WAL の一括ロギング

従来の一括インポートメカニズムは、テーブルとインデックスのインポートに、行ごとのロギングモードを使用します。挿入されるデータの各行に対して、個別の WAL エントリが生成されます。この方法では、I/O 操作が頻繁に発生し、メタデータのオーバーヘッドが高くなります。PolarDB for PostgreSQL は、いくつかの重要な最適化を導入しています。プライベートメモリでページを構築するプロセス中に、複数のデータ行が単一のページに統合され、永続化を保留中の複数のページがプライベートメモリに事前に集約されます。プライベートメモリでページのバッチが構築された後、PolarDB for PostgreSQL は XLOG_FPI タイプの WAL ログを使用してデータを一括で記録します。このタイプのログは、ページへの増分変更ではなく、ページデータ全体を直接キャプチャします。従来の行ごとのロギングアプローチと比較して、この方法はよりコンパクトであり、WAL ログに関連するメタデータのオーバーヘッドを大幅に削減します。

同期操作の非同期操作への変換

トランザクションがコミットされた後、プライベートメモリに構築されたページは、他のプロセスから見える必要があります。理論的には、トランザクションをコミットする前に、構築されたすべてのページをストレージに完全に永続化する必要があります。ただし、この同期永続化は、メインの実行パスの待ち時間を大幅に増加させます。この問題に対処するために、PolarDB for PostgreSQL は非同期アプローチを使用します。バッチページの構築が完了すると、システムはすぐにこれらのページを共有 バッファープール にコピーし、ダーティページとしてマークします。これにより、ページがディスクに物理的に書き込まれるのを待たずに、トランザクションをコミットして返すことができます。ダーティページの永続ストレージへの実際の書き込みは、バックグラウンドの並列ダーティページフラッシュプロセスによって非同期的に実行されます。このアプローチは、PolarDB の高スループットダーティページフラッシュ機能を使用して、ページ構築とバックグラウンドダーティページフラッシュの並列処理を実現します。

システムクラッシュが発生した場合でも、このメカニズムはデータ整合性を確保します。FPI タイプの WAL ログはページ構築中に事前に記録されるため、これらのログはリカバリ中に使用して、コミットされたデータの整合性を保証できます。