PolarDB:インメモリ列指向インデックス (IMCI) の技術アーキテクチャ概要

MySQL との 100% の互換性の実現

すべてのクエリが IMCI で実行できるわけではありません。2つの制約がカバレッジを制限します。

• 列カバレッジ：どの列指向インデックスにも含まれていない列を参照するクエリは、それらの列に対して IMCI を使用できません。

• 演算子カバレッジ：IMCI 実行エンジンは、MySQL の行エグゼキュータの拡張ではなく、完全に書き直されたものです。一部の列タイプ、演算子、および式の形式は、まだ IMCI エンジンに実装されていません。

ホワイトリストメカニズムは、データ型、演算子、式、およびサポートされていないシナリオ (複数ステートメントなど) を、既知の正常なリストと照合します。クエリがホワイトリストを通過した場合、IMCI 実行の対象となります。そうでない場合は、MySQL のネイティブな行エグゼキュータにフォールバックします。このフォールバックにより 100% の互換性が保証されます。つまり、IMCI は高速化できるクエリを処理し、それ以外はすべて MySQL が処理します。

クエリプランの変換

プラン変換は、MySQL の抽象構文木 (AST) 表現を IMCI の論理プランに変換します。このプロセスは、実行計画ツリーをトラバースし、AST ノードを関係演算子として書き換え、MySQL の柔軟な型システムとの互換性を維持するために暗黙の型変換を処理します。

その後、論理プランは最適化されて物理プランになります。標準的な最適化 (Hash Join と Nested Loop Join の選択) に加えて、IMCI オプティマイザーは、IMCI エグゼキュータが直接処理できないサブクエリを、同等の結合操作に変換します。

3つの方式によるコストベースの選択

PolarDB のオプティマイザーは、3つの実行パスの中から選択します。

オプティマイザーは、次のプロセスに従います。

1. SQL ステートメントを解析し、論理プランを生成します。プランを MySQL のネイティブオプティマイザーと IMCI のプランコンパイラの両方に渡します。

2. 行ストアの実行コストを計算します。それがしきい値を超えた場合、クエリを IMCI にプッシュしようとします。

3. IMCI がクエリを実行できない場合、パラレルクエリプランの生成を試みます。

4. IMCI もパラレルクエリもクエリを処理できない場合、行ストアのシリアル実行にフォールバックします。

このコストモデルは、IMCI がパラレルクエリよりも、パラレルクエリがシリアル実行よりもパフォーマンスが高いことを前提としています。実際には、行ストアイデックスでのパラレルインデックス結合が、列ストアでのソートマージ結合よりもコストが低くなることがあります。オプティマイザーは、行ストアプランの方が高速である場合でも IMCI を選択することがあります。

セカンダリインデックスとしての列ストア

IMCI は、列ストアを独立したストレージエンジンとしてではなく、InnoDB のセカンダリインデックスとして実装します。この設計には、いくつかの利点があります。

• トランザクションの再利用：InnoDB はすでに、同じトランザクション内で、INSERT、UPDATE、DELETE 操作をすべてのセカンダリインデックスにアトミックに適用します。IMCI は、このトランザクションフレームワークを修正なしで継承します。

• エンコーディングの再利用：列指向インデックスは、他の行ストアイデックスと同じデータエンコーディングを使用します。フォーマット間でデータを移動する際に、文字セットや照合順序の変換は必要ありません。

• 柔軟な列選択：列の任意のサブセットに列指向インデックスを作成できます。DDL を使用して列を追加または削除します。ポイントクエリにのみ使用される大きな列 (TEXT、BLOB) を行ストアに保持しながら、カーディナリティの高い分析列 (INT、FLOAT、DOUBLE) をインデックス化します。

• リカバリの再利用：クラッシュリカバリは、InnoDB の REDO ログモジュールを再利用します。RO ノードまたはスタンバイノード上の列指向インデックスは REDO ログから再構築され、PolarDB の物理レプリケーションプロセスとクリーンに統合されます。

• ライフサイクル管理：列指向インデックスはプライマリインデックスのライフサイクルを共有するため、スキーマ管理が簡素化されます。

PolarDB では、プライマリインデックスとすべてのセカンダリインデックスは B+ ツリーです。列指向インデックスは論理的にはインデックスであり、インデックス化された列に対するすべての挿入、更新、削除をキャプチャしますが、物理的には、列を単一の行にまとめてエンコードするのではなく、独立して格納します。

上の図に示されているテーブルの場合：プライマリインデックスは 5つの列 (C1–C5) すべてを格納します。セカンダリインデックスは 2つの列 (C2, C1) を B+ ツリーにまとめてエンコードして格納します。列指向インデックスは 3つの列 (C2, C3, C4) を分割された独立した列フォーマットで格納します。

クエリに必要なすべての列が列指向インデックスでカバーされている場合、クエリ実行はそのインデックスのみを使用し、プライマリインデックスには決してアクセスしません。これは、MySQL がすでにサポートしているカバリングインデックス最適化を、列フォーマットデータに適用したものです。カバーされた列に対する分析クエリは、同等の行ストアクエリよりも数十倍から数百倍高速に実行されます。

列指向データの編成

列指向インデックスの各列は、順序付けられていない追記書き込みモードで格納されます。領域の再利用には、インプレース更新ではなく、削除ラベルとバックグラウンドでのコンパクションが使用されます。主要な設計ポイントは次のとおりです。

• 行グループ：レコードは、それぞれ 64,000 行の行グループに編成されます。行グループ内では、各列は個別のデータパックとして格納されます。

• アクティブな行グループ：常に1つの行グループがアクティブであり、新しい書き込みを受け入れます。いっぱいになるとフリーズします。そのすべてのデータパックは圧縮されてディスクにフラッシュされ、各パックのラフインデックス統計が計算されます。

• 行 ID：新しい各行には行 ID が割り当てられます。システムはこの行 ID を使用して、すべての列データパックにわたってその行のデータを見つけます。プライマリキーから行 ID へのマッピングインデックスは、その後の削除と更新をサポートします。

• 削除ラベル：削除操作は、列データをインプレースで変更するのではなく、削除ビットマップ内のビットを設定します。更新操作は、古い行に削除ラベルを付け、新しい行データをアクティブな行グループに追加書き込みすることを組み合わせます。

• バックグラウンドでのコンパクション：行グループ内の無効な (削除された) レコードがしきい値を超えると、バックグラウンドでのコンパクションが領域を再利用し、分析スキャンのためのストレージ密度を向上させます。

この設計により、書き込み操作は軽量に保たれます。書き込みは列データをメモリに追加し、削除はラベルを設定し、更新はラベルを設定して追加します。列ストアのメンテナンスは OLTP トランザクションに最小限のオーバーヘッドしか追加せず、トランザクションレベルの分離は全体を通して維持されます。

ラフインデックスの仕組み

すべてのデータパックは順序付けられておらず、追記書き込みされるため、列指向インデックスは、順序付けられた B+ ツリーインデックスのように正確な行レベルのフィルタリングをサポートできません。代わりに、IMCI は事前計算された統計情報に基づくラフインデックスの仕組みを使用して、展開前に無関係なデータパックをスキップします。

アクティブなデータパックの書き込みが完了してフリーズすると、システムは次の統計情報を計算し、データパックのメタデータに格納します。

• 最小値

• 最大値

• 値の合計

• NULL 値の数

• 総レコード数

これらの統計情報はメモリに永続化されます。削除を含むフリーズされたデータパックの場合、統計情報はバックグラウンドで更新されます。

クエリ実行時、オプティマイザーはクエリ述語とパックの統計情報に基づいて、各データパックを関連あり、関連なし、または関連の可能性ありに分類します。関連なしのパックは完全にスキップされます。COUNT や SUM などの集約操作では、関連ありのパックは事前計算された統計情報から直接回答できることが多く、展開を完全にスキップできます。

ラフインデックスは、大量のデータをスキャンするクエリ、つまり IMCI がターゲットとするまさにそのワークロードで最も効果的に機能します。少数の特定の行を特定するクエリの場合、コストベースオプティマイザーは代わりに行ストアイデックスにルーティングします。

TP/AP ワークロードのリソース分離

同じクラスターで OLTP と OLAP を実行すると、リソース競合のリスクが生じます。大規模な分析クエリが十分な CPU と I/O を消費し、OLTP のレイテンシーが急上昇する可能性があります。PolarDB は、1回書き込み・多数読み取りアーキテクチャを使用して独立した RO ノードを追加することで、これらのワークロードを分離するための3つのデプロイモードをサポートしています。

デプロイレベルの分離に加えて、Auto DOP は単一の分析クエリが消費できるリソースを制限します。DOP の計算では、現在のシステム負荷、利用可能な CPU とメモリ、スケジュールされたクエリのキューが考慮され、単一の大規模クエリが他のリクエストを枯渇させるのを防ぎます。