PolarDB:IMCIの技術アーキテクチャ

PolarDBチームは、ホワイトリストメカニズムを使用して互換性の目標を達成します。 ホワイトリストメカニズムは、次の要因を考慮して使用されます。

• 利用可能なシステムリソース、主にメモリリソースの制限。

  ほとんどの場合、列インデックスはデータベースのすべてのテーブルのすべての列に作成されません。 クエリ文が列ストアに存在しない列を使用する必要がある場合、文は列ストアで実行できません。

• パフォーマンス。

  PolarDBチームは、すべての物理実行演算子と式コンピューティングを含む列指向のSQL実行エンジンを書き換えます。 サポートされているシナリオのカバレッジは、MySQLのネイティブ行ストアと比較して不十分です。 発行されたSQL文に、IMCI実行エンジンでサポートされていないいくつかの演算子フラグメントまたは列タイプが含まれている場合、実行エンジンはSQL文を識別してインターセプトし、実行のために行ストアに戻すことができる必要があります。

ホワイトリストメカニズムは、SQL文やその他のシナリオ (複数文がサポートされていないシナリオなど) のデータ型、演算子、式をチェックします。

MySQLは何十年も進化してきました。 MySQLは、さまざまな列タイプと豊富なSQL構文をサポートします。 IMCIでは、最初の焦点は、分析クエリ文で最も一般的なSQLパフォーマンスの問題を最適化することです。 IMCIの適用可能なシナリオが限られている場合でも、IMCIでサポートされているSQL構文は、ほとんどのOLAPシステムよりもMySQLとの互換性があります。 発行されたSQL文を列ストアで実行できない場合、SQL文はMySQLのネイティブ実行エンジンに直接フォールバックされます。 このようにして、MySQLとの100% 互換性が達成される。

プラン変換の目的は、MySQLのネイティブ論理実行プランの抽象構文ツリー (AST) 表現をIMCIの論理プランに変換することです。 IMCIの論理プランが生成された後、一連の最適化の後に物理プランが生成される。

プランの変換はシンプルで直接的です。 ユーザーは、実行プランツリーをトラバースし、MySQLによって最適化されたASTを、IMCIのノードとしてリレーション演算子を持つツリー構造に変換するだけです。 このプロセスでは、MySQLの柔軟なタイプシステムとの互換性を確保するために、暗黙的なタイプの変換が実行されます。

プラン変換プロセスは、同等の論理プランを生成する。 論理プランは、エグゼキュータによって実行することができず、実行のために物理プランに変換されなければならない。 IMCIのオプティマイザは単純なロジックを使用します。 ハッシュ結合またはネストされたループ結合を使用するかどうかの決定など、いくつかの基本的な実行計画の最適化に加えて、オプティマイザは主に、IMCIエグゼキュータによってサポートされていないサブクエリを同等の結合操作に変換するために使用されます。

行ストアと列ストアの2つの実行エンジンに基づいて、実行プランが選択された場合、オプティマイザはより多くの選択肢を提供します。 オプティマイザは、行ストア実行計画のコストを列ストア実行計画のコストと比較し、コストの低い実行計画を使用できます。

MySQLのネイティブの行ストアベースのシリアル実行機能に加えて、PolarDBは、マルチコアのコンピューティング能力を最大限に活用できる行ストアベースの並列クエリ機能もサポートしています。 したがって、PolarDBオプティマイザは、行ストアベースのシリアル実行、行ストアベースの並列クエリ、およびIMCIのいずれかを選択します。 現在の反復フェーズでは、PolarDBオプティマイザは次の実行プロセスに従います。

1. PolarDBオプティマイザはSQL文を解析し、論理プランを生成します。 次に、PolarDBオプティマイザはMySQLのネイティブオプティマイザを呼び出して、結合順序調整などの最適化を実行します。 同時に、得られた論理プランは、IMCI実行プランのコンパイルモジュールに渡される。 モジュールは、カラムストア実行プランの生成を試みます。 SQLステートメントは、ホワイトリストによってブロックされ、実行のために行ストアにフォールバックされる可能性があります。

2. PolarDBオプティマイザは、行ストア実行プランに基づいて行指向の実行コストを計算します。 コストが特定のしきい値を超えると、PolarDBオプティマイザは、IMCIプランに基づいて実行するために、SQLステートメントをIMCIエグゼキュータにプッシュダウンしようとします。

3. IMCIエグゼキュータがSQL文を実行できない場合、PolarDBは並列クエリ実行プランのコンパイルとSQL文の実行を試みます。 並列クエリ実行プランを生成できない場合、IMCIおよび並列クエリ機能はSQL文を実行できず、SQL文は実行のために行ストアにフォールバックされます。

前述の戦略は、次の判断に基づいています。実行パフォーマンスの観点から、行ストアの直列実行は、IMCIに劣る行ストアの並列実行に劣ります。 SQL互換性の点では、IMCIは行ストア並列実行よりも劣り、行ストア直列実行よりも劣る。 しかし、実際の状況はより複雑です。 たとえば、場合によっては、行ストアインデックスに基づく並列インデックス結合は、列ストアに基づくソートマージ結合よりもコストが低くなります。 IMCIは、現在の戦略に基づいてSQLステートメントを実行するために選択され得る。

IMCI実行エンジンは、従来の火山モデルを使用し、列ストアとベクトル化実行に基づいて実行パフォーマンスを向上させます。

火山モデルに関して、SQLによって生成された構文木に対応する関係代数では、各演算は演算子に抽象化されます。 実行エンジンは、SQL全体を演算子ツリーに構築する。 クエリツリーはNext() インターフェイスを上から下に呼び出し、データは下から上にプルされます。 この方法の利点は、計算モデルが単純かつ簡単であることである。 これは、異なる物理演算子をイテレータに抽象化することによって実現されます。 各演算子は、独自の内部ロジックのみを気にします。 これにより、演算子間の結合が減り、論理的に正しい実行エンジンの書き込みが容易になります。

• IMCI実行エンジンでは、各演算子もイテレータ関数を使用してデータにアクセスします。 違いは、イテレータへの各呼び出しがバッチを返しますが、データの行は返しません。 したがって、実行エンジンは、ベクトル化モデルを使用する火山モデルとみなすことができる。

  

• シリアル実行の機能は、シングルコアコンピューティングの効率、メモリアクセスの待ち時間、I/Oの待ち時間などの要因によって制限されます。 IMCIエグゼキュータのScan、Join、Aggなどのいくつかの主要な物理演算子は、並列実行をサポートしています。 物理演算子は並列処理をサポートする必要があり、IMCIオプティマイザも並列実行プランの生成をサポートする必要があります。 オプティマイザがテーブルのアクセスモードを決定すると、オプティマイザは、アクセスするデータ量に基づいて並列実行を有効にするかどうかを決定します。 オプティマイザが並列実行を有効にすることを決定した場合、オプティマイザは一連の状態データを参照して並列度 (DOP) を決定する。 状態データには、システム内の利用可能なCPU、メモリ、およびI/Oリソース、スケジュールされキューに入れられるタスクに関する情報、統計、クエリの複雑さ、およびユーザーが設定できるパラメーターが含まれます。 これらのデータに基づいて、推奨されるDOP値がオペレータについて計算され、各オペレータは、同じDOP値を内部的に使用する。 ユーザーは、ヒントを使用してDOP値を指定することもできます。

  

前述の2つの最適化のアイデアに基づいて、テーブルスキャン、ハッシュ結合、ネストループ結合、およびグループバイを含むすべての物理実行演算子が再実装されます。 次の例では、実行プログラムの並列化とベクトル化の高速化を示すためにHash Joinを使用します。 IMCIでのHash Joinの実行プロセスを次の図に示します。

ベクトル化実行は、シングルコアの実行効率が低いという問題を解決しますが、並列実行はシングルコアのコンピューティングのボトルネックを解消します。 この2つの組み合わせにより、IMCIの実行速度は、MySQLの従来の行実行よりも数桁速くなります。

APシナリオでは、SQLには多くの場合、1つまたは複数の値、演算子、または関数を含む多くのコンピューティングプロセスが含まれます。 これは、式コンピューティングのカテゴリに属します。 式の評価は計算集約的なタスクであるため、式の計算効率は全体的なパフォーマンスに影響を与える重要な要素です。

MySQLの従来の式コンピューティングシステムは、一般にイテレータモデル実装と呼ばれる行ごとの操作方法を使用します。 イテレータはテーブル全体を抽象化し、式はツリー構造として実装されます。 ただし、この抽象化はパフォーマンスの損失をもたらします。 これは、イテレータの反復中に、データの各行の取得が複数層の関数呼び出しをトリガーするためです。 データの行ごとの取得は、あまりにも多くのI/Oをもたらし、キャッシュにとって友好的ではない。 MySQLはストレージエンジンのアクセス方法によって制約されるため、MySQLはツリーイテレータモデルを使用します。 これは、複雑な計算ロジックを最適化することを困難にする。

列ストアの場合、各列のデータは別々に順番に格納されるため、特定の列での式の計算はバッチで実行できます。 各式の入力と出力の単位はバッチです。 バッチ処理モデルでは、計算プロセスは、SIMD命令を使用することによって加速することができる。

ベクトル化された式システムには、2つのキー最適化があります。

• ベクトル化された式システムは、列ストアの利点を最大限に活用し、イテレータモデルをバッチ処理モデルに置き換えます。 PolarDBチームは、SIMD命令を使用して、最も一般的なデータ型の式カーネル実装を書き換えます。 たとえば、INT、DECIMAL、およびDOUBLEを含むすべての数値型のすべての基本的な数学演算 (+ 、− 、× 、/、およびabs) は、対応するSIMD命令を使用することによって実装される。 AVX512命令セットの助けによって、単一中心操作の性能は数回改善されます。

  

• 式の実装は、PostgreSQLの実装に似ています。 SQLコンパイルおよび最適化ステージでは、IMCI式は、既存の行イテレータモデルと同様のツリー構造に格納されます。 しかし、実行前に、式ツリーはポストオーダーでトラバースされ、記憶のために1次元配列に変換される。 後続の計算において、ユーザは、操作を完了するために1次元アレイをトラバースするだけでよい。 計算は、ツリー反復子モデルにおける再帰的プロセスを排除するので、より効率的である。 さらに、この方法は、計算プロセスの簡潔な抽象化を提供し、データを計算から分離します。これは、並列計算に適しています。

MySQLのプラグインストレージエンジンフレームワークのアーキテクチャでは、列ストアのサポートを追加する最も簡単なソリューションは、InfobrightとMariaDBの列ストアのように、個別のストレージエンジンを実装することです。 PolarDBは、InnoDBのセカンダリインデックスとして列ストアを実装するソリューションを使用します。 これは主に次の考慮事項に基づいています。

• InnoDBは、複数のインデックスをネイティブにサポートします。 INSERT、UPDATE、およびDELETE操作は、行の粒度で一次インデックスおよびすべての二次インデックスに適用され、トランザクションが保証されます。 カラムストアを二次インデックスとして実装するソリューションは、このトランザクション処理フレームワークを再利用できます。

• 2次インデックスとして実装された列ストアは、他の行ストアインデックスと同じデータエンコード形式を使用できます。 メモリコピーで十分です。 ユーザーは、文字セットや照合順序などの情報を考慮する必要はありません。

• セカンダリインデックスは柔軟に管理できます。 ユーザーは、ユーザーがテーブルを作成するときにインデックス内の列を指定できます。 ユーザーは、DDLステートメントを使用して、後続の操作でセカンダリインデックスの列を追加または削除することもできます。 たとえば、解析が必要なINT、FLOAT、DOUBLE列を列インデックスに追加できます。 通常、ポイントクエリにのみ含まれるが、多くのスペースを占めるTEXTおよびBLOBフィールドは、行ストアに保持できます。

• クラッシュ回復プロセスでは、InnoDBのredoトランザクションログモジュールを再利用して、既存の実装とのシームレスな互換性を確保できます。 これにより、PolarDBの物理レプリケーションプロセスも容易になります。 列ストアインデックスは、分析サービスを提供するために独立したROノードまたはスタンバイノードで生成できます。

• セカンダリインデックスは、プライマリインデックスと同じライフサイクルを持ちます。 ユーザーは、セカンダリインデックスを便利に管理できます。

  

前の図に示すように、PolarDBのすべてのプライマリインデックスとセカンダリインデックスはB + ツリーとして実装されています。 カラムインデックスは、定義によるインデックスですが、インデックスによってカバーされるカラムに対する追加、削除、および変更操作をキャプチャするために使用される仮想インデックスです。

上の表の場合、プライマリインデックスには5つの列 (C1、C2、C3、C4、およびC5) のデータが含まれ、セカンダリインデックスには2つの列 (C2とC1) のデータが含まれます。 共通の二次インデックスにおいて、C2およびC1は、1つの行に符号化され、B + ツリーに格納される。 カラム・ストア・インデックスは、3つのカラム (C2、C3、およびC4) のデータを含む。 実際の物理ストレージでは、3つの列が分割され、独立して格納されます。 各列は、書き込み順序に基づいて列ストア形式に変換されます。

カラムストアを二次インデックスとして実装する別の利点は、エグゼキュータのエンジニアリング実装が非常に簡単であることです。 カバーインデックスの用語はMySQLにすでに存在します。つまり、クエリに必要なすべての列がセカンダリインデックスに格納されます。 このセカンダリインデックスのデータは、クエリ要件を満たすために直接使用できます。 一次インデックスと比較して、二次インデックスの使用は、読み取られるデータの量を大幅に削減し、したがって、クエリのパフォーマンスを向上させることができる。 クエリに必要なすべての列が列列インデックスでカバーされている場合、列ストアを高速化すると、クエリのパフォーマンスが数十倍または数百倍向上します。

列インデックスの各列は、順序付けられていない形式で格納され、追加書き込みモードを使用します。 スペースの再利用は、バックグラウンドでラベル削除と非同期コンパクションを使用することによって達成されます。 特定の実装には、次の重要なポイントがあります。

• 列インデックスのレコードは、行グループに基づいて整理されます。 各行グループには64,000行が含まれます。 各行グループの異なる列は、データパックを形成するためにパッケージ化される。

• 各行グループは追加書き込みモードを使用し、各列に属するデータパックも追加書き込みモードを使用します。 列インデックスの場合、アクティブな行グループのみが新しい書き込みを受け入れます。 行グループがいっぱいになると、フリーズします。 行グループに含まれるすべてのデータパックは圧縮されてディスクに格納され、各データブロックの統計はフィルタリングを容易にするために記録されます。

• 列指向の行グループに書き込まれた各新しい行には、位置決めのための行IDが割り当てられる。 システムは、行IDを使用して、行に属するすべての列の位置を計算します。 同時に、システムは、その後の削除および変更操作をサポートするために、主キーから行IDへのマッピングインデックスを維持する。

• 更新操作は、ラベル削除に基づいて実施される。 削除操作を実行するために、ユーザーはビットマップを直接指定できます。 更新操作を実行するには、ユーザーは行IDに基づいて元の位置を計算し、削除ラベルを指定してから、アクティブな行グループに新しいデータを書き込みます。

• 行グループ内の無効なレコードの数が特定のしきい値を超えると、バックグラウンドで非同期コンパクションがトリガーされます。 一方では、非同期コンパクションはスペースを再利用するために使用されます。 一方、非同期コンパクションは、効果的なデータストレージをよりコンパクトにし、分析クエリ順序の効率を向上させることができます。

  

このデータ編成方法は、分析クエリ中のバッチスキャンと列によるフィルタリングの要件を満たします。 さらに、TPトランザクション操作への影響は非常に小さいです。 書き込み操作の場合、ユーザーは列ごとにメモリにデータを追加するだけで済みます。 削除操作の場合、ユーザーは削除ラベルを指定するだけで済みます。 更新操作は、ラベル削除および追加書き込みを含む。 列ストアは、OLTPパフォーマンスを低下させることなく、トランザクションレベルの更新をサポートします。

行から列への操作は、次の場合に実行されます。

• ケース1: ユーザーが既存のテーブルの分析要件を持っている場合、DDLステートメントを使用して一部の列に列インデックスを作成します。 ユーザーは、テーブル全体のデータをスキャンして列インデックスを作成する必要があります。

• ケース2: 行から列への操作は、トランザクション操作に含まれる列に対して実行されます。

フルテーブルの行から列への変換の場合、ユーザーは並列スキャンを使用してInnoDBの主キーをスキャンし、関係するすべての列を列ストア形式に順番に変換できます。 この操作は非常に高速で、I/Oスループット速度とサーバー上の利用可能なCPUリソースによってのみ制限されます。 この操作はオンラインDDLプロセスであり、オンラインサービスの実行をブロックしません。

列インデックスがテーブルに作成された後、すべての更新トランザクションが行指向データと列指向データを同時に更新して、行指向データと列指向データのトランザクションの一貫性を確保します。 次の図は、IMCI機能が無効および有効の場合の違いを示しています。

• IMCI機能が無効になっている場合、トランザクションによるすべての行への更新が最初にロックされます。 次に、データページが修正される。 すべてのロックされたレコードは、トランザクションがコミットされる前に一度にロック解除されます。

• IMCI機能を有効にすると、トランザクションシステムは列ストアの更新キャッシュを作成します。 すべてのデータページが変更されると、列ストアの変更操作が記録されます。 トランザクションが終了し、ロックされたレコードがアンロックされる前に、更新キャッシュが列ストアシステムに適用されます。

一般的なOLTP要求の場合、メモリデータページを更新するのに費やされる時間は、トランザクション動作プロセスのごく一部のみを占める。 したがって、この方法は、TPトランザクションのレイテンシにほとんど影響を与えない。 多数の行で動作する大規模なトランザクションの場合、列インデックスへの更新はリアルタイムで列ストアに直接適用されますが、トランザクションがコミットされる前に更新は公開されません。 これにより、大きなトランザクションのコミット待ち時間が非常に短い時間範囲内で増加することが保証される。 TPパフォーマンスへの影響をさらに減らすために、APクエリにデータの適時性に対する高い要件がない場合、列インデックスの更新を列ストアに非同期に適用できます。

列ストアは、行ストアと同じレベルのトランザクション分離を提供します。 書き込み操作ごとに、行グループの各行は、行を変更するトランザクションのIDを記録します。 削除ビットマップ内のラベル削除操作ごとに、操作のトランザクションIDも記録されます。 トランザクションIDの書き込みと削除により、APクエリは、非常に軽量な方法でグローバルに一貫したスナップショットを取得できます。

前述のストレージフォーマットからわかるように、IMCI内のすべてのデータパックは順序付けされておらず、追加書き込みモードを使用します。 したがって、InnoDBの通常の順序付けられたインデックスほど正確に要件を満たさないデータを除外することは不可能です。 IMCIでは、ユーザーは統計を使用してデータブロックをフィルタリングし、データアクセスの単価を下げることができます。

• 各アクティブなデータパックの書き込みが完了すると、システムは事前にコンピューティングを実行します。 次に、システムは、最小値、最大値、値の合計、ヌル値の数、およびレコードの総数を含む情報をデータパックに生成する。 全ての情報は、データパックのメタデータ領域に保持され、メモリに存在する。 データ削除操作は凍結されたデータパックに含まれるため、統計の更新と維持はバックグラウンドで実行されます。

• クエリ要求の場合、データパックは、クエリ条件に基づいて、関連データパック、無関係データパック、および場合によっては関連データパックに分類される。 これにより、実際のデータブロックアクセスが減少する。 カウントや合計などの一部の集計クエリ操作では、ユーザーは事前に計算された統計値に対して簡単な操作を実行できます。 これらのデータブロックは、解凍される必要さえない。

統計に基づく大まかなインデックススキームは、一部のデータを正確に見つける必要がある一部のクエリにはあまり適していません。 しかしながら、ハイブリッド行 − 列ストアエンジンでは、列インデックスは、大量のデータのスキャンを伴うクエリを加速することを支援するだけでよい。 このシナリオでは、IMCIには大きな利点があります。 少量のデータのみにアクセスするSQLクエリの場合、オプティマイザは通常、コストモデルを使用して、行ストアに基づいてより費用対効果の高いソリューションを計算します。

PolarDBのハイブリッド行-列ストアソリューションは、1つのクラスターでAPクエリとTPクエリの両方をサポートします。 しかしながら、多くのサービスは、高いOLTP負荷を有し、突然のOLAP負荷は、TPサービスの応答待ち時間に干渉し得る。 したがって、HTAPデータベースでは負荷分離をサポートする必要があります。 PolarDBのwrite-once-read-manyアーキテクチャにより、ユーザーはAPロードとTPロードを簡単に分離できます。 PolarDBの技術アーキテクチャに基づいて、次の展開モードがサポートされています。

• モード1: ハイブリッド行-列ストアソリューションは、読み取り /書き込み (RW) ノードで有効になります。 このモードは、軽量APクエリをサポートします。 このモードは、TP負荷が主に使用され、AP要求が比較的少ない場合に適しています。 PolarDBを使用してレポートをクエリし、データがバッチデータのインポートから取得された場合にも、このモードを使用できます。

• モード2: RWノードはOLTP負荷をサポートし、APタイプROノードは、クエリをサポートするためのハイブリッド行 − 列ストア解決策を有効にするために起動される。 このモードでは、CPUリソースを完全に分離することができ、APタイプのROノードのすべてのメモリを列ストアとエグゼキュータに割り当てることができます。 しかし、同じ共有ストレージが使用されるので、I/Oは影響を受ける。

• モード3: RWノードとROノードの両方がOLTPロードをサポートし、ハイブリッド行列ストアソリューションは、APクエリをサポートするために別のスタンバイノードで有効になります。 スタンバイノードは独立した共有ストレージクラスターを使用するため、このモードでは、モード2で実現されるCPUとメモリリソースの分離に加えて、I/Oリソースの分離も実現できます。

さまざまなレベルのリソース分離をサポートする前述のさまざまなデプロイメントアーキテクチャに加えて、PolarDBでは、並列に実行する必要のある大規模なクエリで自動並列度 (Auto DOP) がサポートされています。 このメカニズムは、現在のシステム負荷と利用可能なCPUおよびメモリリソースとを考慮に入れ、単一のクエリで使用できるリソースを制限します。 これにより、1つのクエリが多くのリソースを消費し、他の要求の処理に影響を与えることを防ぎます。