PolarDB クラウドネイティブ データベースは、過去 5 年間でどのようにパフォーマンスが最適化されてきましたか?

著者 |ジェユ、バオティアオ

クラウド データベースは、コンピューティングとストレージを分離し、コンピューティングとストレージの独立した拡張をサポートし、ユーザーは従量課金制などの機能も利用できます。これにより、クラウド データベース ベースのシステムの効率と柔軟性が向上します。その結果、クラウドネイティブ データベースを構築して使用する機運が高まっています。一方、クラウドストレージサービスはクラウドの標準機能となっています。ストレージ側では互換性のあるユニバーサル ファイル インターフェイスが提供され、永続性やフォールト トレランス処理などの複雑な詳細は公開されません。使いやすさと規模による高いコスト効率により、クラウド ストレージはクラウド システムの第一選択肢となっています。一般的なクラウド ストレージ サービス上にクラウド データベースを構築することは、大規模なクラウド ストレージのメリットを享受できるだけでなく、信頼性の高いクラウド ストレージ サービスを通じてメンテナンス コストを削減し、データベース開発サイクルを加速できるソリューションであることは間違いありません。

しかし、クラウドストレージとローカルストレージの特性の違いを考慮すると、ローカルデータベースをクラウドに移行してクラウドデータベースを構築する場合、クラウドストレージをいかに効果的に活用するかという点には多くの課題があります。この点に関して、私たちの論文では、クラウド ストレージに展開されたときに B ツリーおよび LSM ツリー ベースのストレージ エンジンが直面する課題を分析し、クラウド ストレージに基づいてデータベースを構築する際にデータベース開発者がシステムをより効率的にするのに役立つことを期待して、最適化フレームワーク CloudJump を提案します。一連のターゲット最適化を実証するために、クラウドネイティブ データベース PolarDB を例として使用し、一部の作業をクラウド ストレージ ベースの RocksDB に拡張して、CloudJump の可用性を実証しました。

詳細については、論文「PolarDB-CloudJump: クラウド ストレージ向けのクラウド データベースの最適化」を参照してください。

背景

ここで説明するクラウド ストレージは、主に弾力性のある分散ブロック ストレージに基づいています。オブジェクトベースのストレージなど、クラウド内の他の種類のストレージ サービスについては、この記事では取り上げません。共有クラウド ストレージ (分散ブロック ストレージ サービスと分散ファイル システムなど) は、複数のコンピューティング ノードの共有ストレージ レイヤーとして機能し、QoS (サービス品質) 保証、大容量、弾力性、従量課金制の価格モデルを提供します。ほとんどのクラウド ベンダーとクラウド ユーザーにとって、ベアメタル SSD クラスターを構築して維持するよりも、クラウド ストレージ サービスの方が魅力的です。したがって、クラウド ネイティブ データベース専用のストレージ サービスを構築して最適化する代わりに、既存のクラウド ストレージ サービスを活用してクラウド ネイティブ データベースを構築することは、非常に現実的な選択肢です。さらに、クラウドストレージサービスがほぼ標準化されたため、それに応じた開発や移行も迅速化されました。

図 1 は、ローカル データベース (バックアップなし) と共有ストレージのクラウド ネイティブ データベースのシステム構造を示しています。 AWS Aurora は、まずローカル データベースから共有ストレージのクラウドネイティブ データベースへの移行を主導しました。データベースをストレージ層とコンピューティング層に分割し、各層を個別に拡張できます。データ ページの転送で発生する大きなネットワーク オーバーヘッドを排除するために、ストレージ レイヤーをさらにカスタマイズしてデータ ページに REDO ログを適用し、2 つのレイヤー間でデータ ページを転送する必要がなくなります。この設計は、間違いなく、Aurora のコンピューティング層でのみ使用できる、クラウド内の非標準のストレージ サービスを提供します。

もう 1 つの解決策は、標準化されたインターフェースを備えたクラウド ストレージ サービスを利用してクラウド データベースを移行または構築することであり、これもこの論文の研究目標です。前述の通り、そうすることで得られる主なメリットは、迅速なシステム開発、スムーズな移行を実現し、標準化された大規模ストレージサービス本来のメリットを活かすことができることです。さらに、特に私たちのプロジェクト（PolarDB）のハードウェア環境と既存の背景では、サービスの信頼性と開発反復要件の両方を考慮して、クラウド ストレージ サービス機能のパフォーマンスを最適化することが最も緊急の第一歩です。

課題と分析

クラウド ストレージとローカル SSD ストレージには、帯域幅、レイテンシ、弾力性、容量などの点で大きな違いがあります。たとえば、図 2 は、定常状態におけるローカル SSD とクラウド ストレージの I/O レイテンシ、帯域幅、ワーカー スレッドの関係を示しており、データベースの設計などに大きな影響を与えます。さらに、共有ストレージのアーキテクチャ特性もクラウド ストレージに影響を与えます。たとえば、複数のノード間のデータの一貫性により、キャッシュの一貫性を維持するためのオーバーヘッドが増加します。

システム実験、要約、分析を通じて、CloudJump が次のような技術的課題に直面していることがわかりました。

• リモート分散ストレージ クラスターにアクセスすると、クラウド ストレージ サービスの I/O レイテンシが高くなります。
• 通常、集約された I/O 帯域幅は完全には利用されません。
• ローカル ストレージを備えた単一のマシンでは適切に動作するが、クラウド ストレージに適応する必要があり、その結果、ファイル キャッシュなどの特性が変化する従来の設計。
• リンクが長いと、さまざまなデータベース I/O 操作間の分離性が低下します (たとえば、ログのフラッシュと大量のデータ I/O 間の競合)。
• クラウド ユーザーは、データ分割なしで非常に大きな単一テーブル ファイル (数十 TB など) を使用することが許可されており、I/O の問題の影響を悪化させる可能性があります。

B ツリーや LSM ツリー ベースのストレージ エンジンなどの異なるデータ ストレージ エンジンでは、これらの機能の違いによってパフォーマンスも異なります。表 1 は、これらの課題とデータベース設計への影響をまとめたものです。一般的な問題としては、WAL パスの書き込み速度の低下や共有ストレージ (分散ファイル システム) のキャッシュ一貫性コストなどがあります。また、排他的リソース条件下での B ツリー構造のリモート I/O や、I/OLSM ツリー読み取り増幅効果のリモート悪化などの個別の問題もあります。

最適化の原則

CloudJump は、上記の課題に対処するために 7 つの最適化基準を提案しています。

• スレッドレベルの並列処理: たとえば、I/O 機能の実験に基づいて、(より多くの) マルチスレッド ログ、データ I/O スレッド、および非同期 I/O モデルを使用して、複数のストレージ ノードにデータを完全に分散します。
• タスクレベルの並列処理: たとえば、集中ログ バッファーはページ パーティションに分割され、パーティションに基づいて並列書き込みと並列回復が実装されます。
• リモート読み取りとプリフェッチを削減: たとえば、元の分散メタを収集して統合スーパーブロックに集約することにより、複数の I/O が結合され、高速な検証が実現します。事前読み取りにより、集約された読み取り帯域幅が活用され、読み取りタスクの待ち時間が短縮されます。圧縮とフィルタリングにより、読み取られるデータの量が削減されます。これらのテクニックは、ローカル SSD よりもクラウド ストレージでより効果的です。
• きめ細かいロックとロックフリーのデータ構造: クラウド ストレージの長い I/O レイテンシにより同期のオーバーヘッドが増大します。これは主に、ロックフリーのダーティ フラッシュ、ロックフリーの SMO などを実現するインプレース更新システムを対象としています。
• 分散ノード間の分散: クラウド ストレージでは、複数のノード間での分散アクセスにより、より多くのハードウェア リソースを活用できます。たとえば、単一の大きな I/O を異なるストレージ ノードに同時に分散して、合計帯域幅を最大限に活用できます。
• キャッシュのバイパス: キャッシュのバイパスを使用すると、分散ファイル システムでのキャッシュの一貫性を回避し、最適なストレージ要求形式に合わせて DB レベルで I/O 形式を最適化できます。
• 優先順位付けされた I/O タスクのスケジュール設定: アクセス リンクが長いため (たとえば、パスにキューが多い)、I/O 要求間の分離はローカル ストレージの場合よりも低くなります。そのため、WAL の優先順位付けや事前読み取りグレーディングなど、DB レベルでさまざまな I/O をマークしてスケジュールする必要があります。

実践事例

実例: PolarDB

PolarDB は、Posix 互換インターフェースを備えた分散ファイルシステムである PolarFS 上に構築されています。 Aurora と同様に、コンピューティングとストレージを分離したアーキテクチャを採用し、高速 RDMA ネットワークと最新のブロック ストレージ テクノロジを使用して、超低レイテンシと高可用性を実現します。 PolarDB では、分散ストレージの特性に合わせて CloudJump 基準に準拠した多くのパフォーマンス最適化を行っており、クラウドネイティブ データベース PolarDB のパフォーマンスが大幅に向上しています。

1. WAL書き込みの最適化

WAL (先行書き込みログ) 書き込みは一貫性と耐久性にとって重要なパスであり、トランザクションの書き込みパフォーマンスはログ I/O のレイテンシに非常に敏感です。ネイティブ InnoDB は、MTR (ミニトランザクション) の粒度でログを整理し、グローバル REDO ログ バッファを維持します。 MTR がコミットされると、そこにキャッシュされているすべてのログ レコードがグローバル ログ バッファーに追加され、その後、永続性を確保するために集中的な順序でディスクにフラッシュされます。この従来の集中ログ モードはローカル ディスクでは適切に機能しますが、クラウド ストレージを使用する場合、リモート I/O レイテンシが増加すると集中ログの書き込みパフォーマンスが低下し、トランザクションの書き込みパフォーマンスに影響します。クラウド ストレージの特性に基づいて、WAL の書き込みパフォーマンスを向上させるための 2 つの最適化、ログ シャーディングと (大規模な) I/O タスクの並列化を提案しました。

Redo ログ シャーディング: InnoDB の redo では生理学的ログが使用されます。ほとんどの MTR は単一のデータ ページ (一部の特殊なものを除く) を対象としており、ページは基本的に互いに独立しています。図 5 (左) に示すように、REDO ログ、REDO バッファなどを、変更するページに応じて分割し、それらを異なるファイルに書き込むことで、同時ログ書き込み (および同時リカバリ、同時物理レプリケーションなど) をサポートし、同時書き込みに適した分散ファイル システムで書き込みパフォーマンスの利点を実現します。

並列 I/O タスクの分解: クラウド ストレージでは、ファイルは複数のチャンクで構成されます。チャンク割り当て戦略に応じて、異なるチャンクが異なるストレージ ノードに配置される可能性が高くなります。図 5 (右) に示すように、各 REDO パーティションのファイルをさらに複数の物理的な分割に分割します。単一の大きなログ I/O タスク (グループ コミット、BLOB レコードなど) の場合、ログ ライターは I/O を LSN でスライスし、I/O 要求を異なる分割に同時に分散します。このようにして、待ち時間の長いログ I/O タスクを分割し、分散ストレージの高分散書き込み機能を使用して全体的な I/O 時間を短縮できます。

2. 迅速な回復

高速リカバリを実現するために、高速 (起動) 検証と完全並列リカバリという 2 つの最適化を提案します。

InnoDB の元のリカバリ プロセスでは、InnoDB はまず起動時にすべてのファイルを開いてメタ情報 (ファイル名、テーブル ID など) を読み取って正確性を確認し、次に ARIES スタイルのリカバリ アルゴリズムを使用してチェックポイントが設定されていないデータをやり直します。起動を高速化するために、高速検証方式では、すべてのファイルをスキャンするのではなく、データベースのライフサイクル中に必要なメタ情報を記録して一元管理し、ファイルの作成および変更時に必要なメタ情報をスーパーブロックに記録し、起動時にはメタデータ ブロック ファイルのみをスキャンします。したがって、起動スキャン プロセス中のリモート I/O アクセスのオーバーヘッドが削減されます。次に、Redo ログ シャーディングを利用して、ログ ファイルをページごとに複数のファイルに分割します。リカバリフェーズ（さらに解析、やり直し、元に戻すの 3 つのフェーズに分けられます）では、並行解析とやり直し（元に戻すフェーズはバックグラウンドで実行されます）を自然にサポートし、並行タスクを通じて CPU と I/O リソースを最大限に活用してリカバリを高速化できます。

3. 事前読書

クラウド ストレージ環境では、ユーザー タスクがデータにアクセスするときにキャッシュ ミスが発生すると、読み取り I/O レイテンシが大幅に増加します。効果的な事前読み取りにより、集約された読み取り帯域幅を最大限に活用して、読み取りタスクの待ち時間を短縮できます。 InnoDB には、線形先読みと非線形先読みという 2 つのネイティブ物理先読み方式があります。さらに、論理的な先読み戦略を導入しました (順序付けられていない挿入と更新のため、インデックスは必ずしも物理的に連続しているわけではありません)。たとえば、プライマリ インデックス スキャンの場合、タスク スレッドが開始キーからインデックスを順番にスキャンして特定のしきい値を超えると、論理先読みによってプライマリ インデックスの非同期先読みが論理順序でトリガーされ、一定量の連続ページが事前に読み取られます。たとえば、セカンダリ インデックスと非インデックス列のバック テーブル操作を使用したスキャンの場合、セカンダリ インデックスをスキャンしながら、関連するヒット プライマリ キーがバッチで収集されます。特定のデータ バッチが蓄積されると、対応するプライマリ インデックス データを事前読み取りするための非同期タスクがトリガーされます (この時点では、残りのセカンダリ インデックス スキャンがまだ進行中である可能性があります)。

4. 同期（ロック）の最適化

詳細については、「InnoDB btreeラッチ最適化プロセス」[1]の記事を参照してください。ロックフリーのダーティ フラッシュ: ネイティブ InnoDB は、ダーティ データをフラッシュするときに現在のページの sx ロックを保持する必要があり、これにより、I/O 中に現在のページの書き込みが完全にブロックされます。一方、クラウド ストレージでは I/O レイテンシが高く、ブロック時間が長くなります。まず、シャドウ ページ メソッドを使用して現在のページのメモリ コピーを構築します。メモリ コピーが構築された後、元のページの sx ロックが解放され、シャドウ ページの内容を使用してダーティおよび関連するフラッシュ情報の更新がフラッシュされます。

SMO ロックの最適化: InnoDB には、グローバル インデックス ラッチがまだ存在します。グローバル インデックス ラッチのため、Btree 内で同時に発生できる SMO は 1 つだけです。インデックス ラッチは依然としてグローバルなボトルネックになります。上記のインデックス ラッチはコンピューティングのボトルネックになるだけでなく、ロック同期期間中にインデックス上の他の可能な I/O 操作を並列に実行できず、ストレージ帯域幅の使用率も低くなります。関連する実装については、「今後の道：BTreeからPolar Indexへ」[2]の記事を参照してください。

5. 複数のI/Oタスクキューの適応

クラウド ストレージの I/O 分離が低いという課題を考慮し、クラウド ストレージが DB 層ストレージ カーネルの I/O セマンティクスを認識できず、優先度の低い I/O 要求 (ページ フラッシュや優先度の低い事前読み取りなど) が主要な I/O パスのパフォーマンスに影響することを回避するために、データベース カーネルで適切な I/O スケジューリング モデルを提供することが重要です。 PolarDB では、現在の I/O 負荷に基づいて最適なデータベース パフォーマンスを実現するために、データベース カーネル層でさまざまな種類の I/O 要求をスケジュールします。各 I/O 要求には、WAL 読み取り/書き込み、ページ読み取り/書き込みなど、DB レイヤーでのセマンティック ラベルがあります。

データベースの非同期 I/O 要求に対する同時書き込みをサポートする複数のプロデューサー/コンシューマー キューを確立しており、プライベート キュー、優先キュー、一般キューという特性の異なる 3 つのキューがあります。異なるキューの数は、現在のクラウド ストレージの I/O 機能に応じて決まります。

通常の状況では、WAL はプライベート キューを通じてのみ書き込まれます。書き込み量が増加すると、その I/O 要求も優先キューに転送されます。このとき、優先キューは WAL 書き込みを優先し、後続のページ書き込み I/O は優先キューに入りません。この I/O モデルに基づいて、I/O リソースの一定部分が WAL 書き込み用に予約され、トランザクション送信の書き込みパフォーマンスが確保され、クラウド ストレージの高集約帯域幅が最大限に活用されます。さらに、クラウド ストレージの高スループット、広帯域幅、高レイテンシ、大きな変動特性に合わせて、I/O タスク キューの長さと数も拡張されました。

6. I/O 要求のフォーマット

クラウド ストレージとローカル ストレージでは、ブロック サイズや I/O 要求の開始方法など、I/O 形式に大きな違いがあります。ほとんどの分散クラウド ストレージでは、複数のコンピューティング ノードを共有する場合、コンピューティング ノードのキャッシュ一貫性を維持する問題を回避するためのページ キャッシュはありません。このとき、クラウド上で元のローカルストレージ I/O 形式を使用すると、読み取り時書き込みや論理と物理的な場所のマッピングなどの問題が発生し、パフォーマンスが低下します。 PolarDB では、WAL I/O とページ I/O をクラウド ストレージに適したリクエスト I/O 形式と一致させることで、単一の I/O のレイテンシを最小限に抑えます。

WAL I/O アライメント: ファイルは固定サイズのブロックで読み書きされます。クラウド ストレージのブロック サイズは大きく (4 ～ 128 KB)、従来のログ配置戦略はクラウド ストレージのストライプ境界には適していません。ログ データを送信する際、I/O 要求の長さとオフセットをクラウド ストレージのブロック サイズに合わせます。

データ I/O アライメント: たとえば、現在、データ ページには通常ページと圧縮ページの 2 種類があります。通常のページは 16 KB で、クラウド ストレージのブロック サイズに簡単に合わせることができますが、圧縮されたページでは、その後に多数の不整合 I/O が発生します。 PolarDB の圧縮ページの配置を例に挙げます。まず、データが最小単位 (PolarFS では 4 KB など) で読み取られることを確認します。書き込み時には、最小アクセス単位より小さいすべての圧縮ページ データについては、ストレージ上のページ データが最小単位に揃えられるように、書き込み前に最小単位に拡張します。

データ I/O のマージを排除: ローカル データベースでは、データ ページ I/O がマージされ、連続した順次書き込みのための大きな I/O が形成されます。クラウド ストレージでは、異なるストレージ ノードへの同時書き込みの方がパフォーマンスが高いため、クラウド ストレージ データベースでは、データ ページでの I/O マージ操作は必要ありません。

スペースの制限により、この記事では提案された最適化方法の一般的な実装ロジックについてのみ簡単に紹介します。具体的な実装の詳細については、論文および関連記事を参照してください。

最適化の効果を確認するために、PolarStore と Local Disk で実行されているクラウド ストレージ用に最適化された MySQL と、最適化された PolarDB を比較しました。下の図から、PolarDB は CPU バウンド、IO バウンドの sysbench、TPCC などのさまざまなシナリオで明らかなパフォーマンス上の利点があることがわかります。

同時に、当社の最適化効果が自社のクラウドストレージ PolarStore だけでなく、すべてのクラウドストレージに有益であることを証明するために、クラウドストレージ向けに最適化された PolarDB を StorageX や ESSD などの他のクラウドストレージ上で実行しています。いずれも非常に優れたパフォーマンスの向上を達成できることがわかり、これは当社の最適化がほとんどのクラウド ストレージに非常に有益であることを示しています。

実例: RocksDB

また、CloudJump の分析フレームワークといくつかの最適化手法をクラウド ストレージ ベースの RocksDB に拡張し、期待どおりのパフォーマンス上の利点も実現しました。

1. ログI/Oタスクは並列に分散される

RocksDB はクラッシュの一貫性を確保するために集中型の WAL も使用します。集中ログは、複数の列ファミリからログ レコードを収集し、単一のログ ファイルに保存します。 LSM-Tree は最後に追加専用データ ブロックのみを回復する必要があることを考慮して、前のケースで説明したログ I/O 並列分散方式を使用して、ログ ライター内のバッチ ログを分割し、異なるファイル シャードに並列に分散します。

2. データアクセスを高速化する

RocksDB には、主にプリフェッチ、フィルタリング、圧縮メカニズムなど、データ アクセスを高速化するためのテクノロジが多数あります。クラウド ストレージの特性を考慮すると、これらのテクノロジ (適切な適応) はクラウド ストレージ環境でより価値が高まります。分析と実験の結果、次の提案を行いました。1) 事前読み取りメカニズムにより、一部のクエリと圧縮操作を高速化できます。圧縮操作の事前読み取りを有効にし、適切な事前読み取り I/O タスクの優先度を設定し、単一の事前読み取り操作のサイズをストレージの粒度に合わせることをお勧めします。クエリ操作の事前読み取りは、ユーザー シナリオによって決定する必要があります。 2) クラウド ストレージでブルーム フィルターを有効にし、フィルターのメタデータと通常のデータを分離し、フィルター情報を一元管理することをお勧めします。 3) ブロック圧縮を使用して、データアクセスにかかる全体的な時間を短縮します。次の表は、データ量と PolarFS アクセスの遅延を示しています。テーブル内のストレージは RDMA に基づいています。レイテンシが高いストレージ環境では、圧縮の利点が高くなります。圧縮を導入すると、データ アクセスの全体的なレイテンシ (特に読み取りレイテンシ) が短縮されます。

3. 複数のI/Oタスクキューと適応

マルチコア ハードウェア環境では、マルチキュー I/O モデルを導入し、RocksDB で I/O タスクと作業タスク (圧縮ジョブやフラッシュ ジョブなど) を分割しました。これは、I/O スレッドの数を調整して、スループットとレイテンシの関係をより適切に制御できるためです。 I/O タスクはバックグラウンドのフラッシュ ジョブから分離されているため、フラッシュ スレッドの数をさらに増やす必要はありません。フラッシュ スレッドは、I/O 要求を調整してスケジュールするだけです。 RocksDB 自体はスレッド ロールに基づいた優先度スケジューリング スキームを提供しており、ここでのスケジューリング方法は I/O タグに基づいています。

クラウド ストレージに応じて I/O 要求のサイズとデータ構成 (ブロックや SST など) を調整し、SST ファイル フィルターのブロック サイズも正しく調整されるように、より正確な制御を実現します。 PolarFS を例にとると、最小のストレージ要求サイズは 4 KB (最小の処理単位を示します)、理想的な要求サイズは 16 KB の倍数 (読み取りオン書き込みが発生しない)、メタデータ ストレージの粒度は 4 MB です。 SST サイズとブロック サイズは、それぞれストレージ粒度と理想的な要求サイズの倍数に厳密に調整されます。ネイティブ RocksDB にもアライメント戦略があります。ストレージ パラメータを調整し、圧縮されたデータ ブロックを整列させる必要があります。

最小要求サイズよりも小さい I/O 要求をマルチキュー I/O モデルに渡す代わりに、最小 I/O サイズに揃え、その後の揃えのために揃えられていないサフィックスをメモリにキャッシュします。次に、ストレージの粒度より大きい単一の I/O 要求を発行するのではなく、マルチキュー I/O モデルを通じて並列タスクを実行します (たとえば、6 MB の I/O は 4 MB と 1 MB の 2 つのタスクに分割されます)。これにより、データが可能な限り異なるストレージ ノードに分散されるだけでなく、並列処理が最大化され、帯域幅が最大限に活用されます。

4. I/Oアライメント

すべてのログおよびデータ I/O 要求は、キューに入れられる前にサイズと開始オフセットが調整されます。 WAL 書き込みパスの場合、PolarDB のログ I/O アライメントに似ています。データ書き込みパスでは、データ圧縮を使用すると、LSM ツリー構造に不整合なデータ ブロックが多数存在する可能性があります。たとえば、1 KB から始まる 2 KB のログ データをフラッシュする場合、メモリ キャッシュ内のデータから最初の 1 KB を埋め (追加専用構造の場合、これは末尾のデータ キャッシュを保存することによって実現されます。これは、ネイティブ ページを最小単位に直接拡張するインプレース更新構造とは異なります)、3 ～ 4 KB にゼロを追加してから、0 KB から始まる 4 KB I/O を送信します。

要約する

この論文では、クラウド ストレージのパフォーマンス特性を分析し、ローカル SSD ストレージと比較し、B ツリーおよび LSM ツリー データベース ストレージ エンジンの設計への影響をまとめ、クラウド ストレージに移行するローカル ストレージ エンジンの適応と最適化をガイドするフレームワーク CloudJump を導き出します。最適化の利点は、PolarDB と RocksDB という 2 つの具体的なケースを通じて実証されています。