EverDB 分散実行プラン

この記事は、EverDB R&D チームが執筆した WeChat パブリック アカウント「独創的な操作と素晴らしい効果」から転載したものです。この記事を転載する場合は、Jingxinduyun Weimiaoweixiaoの公式アカウントにご連絡ください。

データベース システム設計において、実行プランは、SQL 実行に必要なすべての演算子とその実行順序を含む、SQL 実行プロセスの正式な記述です。 「EXPLAIN + SQL」コマンドを使用すると、実行プランを詳細に表示し、パフォーマンスのボトルネックを見つけ、SQL を最適化するための方向性と基礎を提供できます。この記事では、EverDB 分散データベースの観点から実行プランについて説明します。

（I）分散アーキテクチャ実行計画

集中型データベースと比較して、分散型データベースには多数のシャードノードがあり、各シャードが独自のシャードのデータ計算と保存を担当するため、その実行計画には特別な実装方法が必要です。ミドルウェアアーキテクチャによる分散データベースでは、分散オペレータ（以下、EverDB 実行プランノード）を導入することでデータシャードストレージ機能を実現し、実行プランの分析と最適化を最適化し、データシャード内の独立した計算を送信し、データシャード間の同時実行を調整します。実行結果は、グループ化、並べ替え、その他の操作のためにミドルウェアによってさらに統合されます。これは効率的で便利な実装方法です。

EverDB はこの設計コンセプトに基づいて実行計画を実装します。従来の集中型データベースと比較して、EverDB 実行プランによりデータベースのスケーラビリティが向上し、より大きなデータ スケールとより多くの同時データ アクセスがサポートされます。同じ負荷圧力を処理するという前提の下で、各シャードのストレージとコンピューティング リソース、および並列コンピューティングの利点を最大限に活用して、より優れたパフォーマンスを実現できます。

(II) EverDB実行計画

EverDB 分散データベースは、グリッド スケジューリング レイヤー、データ ノード、構成ノード、および管理コンソールで構成されます。分散データベースのスケジューリング ノードとして、グリッド スケジューリング レイヤーは SQL を受け取って解析し、S​​QL ステートメントを再構築して変換し、シャード テーブルと非シャード テーブルを含む 2 種類の実行プラン分析をサポートします。

図1

EverDB の実行プランには、グリッド スケジューリング レイヤーとバックエンド データ ノードでの SQL 実行プロセスが含まれます。グリッド スケジューリング ノードの実行計画には、主にロジック処理層と接続ドライバー層の 2 つの部分が含まれます。ロジック処理層には、語彙および文法解析モジュール、クライアント通信モジュール、共通テーブル/シャード テーブル構成、SQL 再構築および変換、実行プラン ツリー、およびプラン ツリー ノードが含まれます。共通テーブル/シャードテーブル構成は、SQL にシャーディングが必要かどうかを識別し、シャードテーブルのストレージ アドレス情報を取得し、シャーディング戦略に基づいて実行プランの構築を完了するために使用されます。接続ドライバ層は、内部接続プールと通信プロトコルの処理モジュールです。これは MySQL 通信プロトコルを完全にサポートし、実行プラン内のデータ ノードにリクエストをプッシュダウンする役割を担います。データ ノード実行プランの実装は、MySQL 実行プランを参照できます。

図2

シャード クエリを例にとると、EverDB のグリッド スケジューリング ノードの実行プラン プロセスは次のようになります。

• SQL 解析: クライアント処理スレッドは、クライアントから送信されたクエリ要求を受信し、SQL の語彙および文法の解析を実行します。
• SQL 再構築: SELECT クエリ テーブルのストレージ情報に基づいて、通常のテーブルとシャード テーブルに分割できます。シャードテーブルの場合は、クエリ条件やデータ格納条件に基づいて、SQL 文をさらに再構築して最適化する必要があります。たとえば、複数のシャード間のノード間クエリは、SQL 再構築後にデータ ノードにプッシュダウンして実行したり、一時テーブルを作成して少量のデータを移行することでクエリ パフォーマンスの低下を軽減したりできます。
• 実行プランの構築: SQL が解析された後、対応する実行プラン ツリーを構築する必要があります。これは、複数の実行プラン ノードで構成される、SQL 実行プランを維持するために使用されるデータ構造です。実行プラン ノードは、SQL 実行プロセスの各ステップの実行者です。各スレッドの実行者としてみなすこともできます。多くの種類に分かれており、内部実行ノード、トランザクション実行計画ノード、データ移行実行ノード、情報クエリノード、情報送信ノード、ソートと重複排除の組み合わせノードなど、さまざまな操作を実行するために使用されます。
• 実行プランを実行します。実行プランの実行中、分散クラスターの処理を高速化するために、シャード テーブル クエリにマルチスレッド同時実行が使用されます。
• SQL プッシュダウン: クエリ要求を対応するシャード データ ノードにプッシュダウンするために、EverDB は通信モジュール (図 3 の MySQL プロトコル アダプタとドライバ モジュール) を介してクエリ要求を MySQL 通信プロトコルの形式でデータ パケットにカプセル化し、接続プールによって割り当てられた接続を介してデータ パケットをデータ ノードに送信して、シャード クエリ要求のプッシュダウンを完了します。
• 統合結果: データ ノードはスケジューリング ノードから要求を受信し、さらに SQL 分析を実行し、テーブルの実行プランを作成します。クエリ計算が完了すると、データ ノードはクエリ結果をスケジューリング ノードにフィードバックします。スケジューリング ノードは、実行プラン ツリーに従ってすべてのデータ ノードから返されたシャード結果をマージおよびソートし続け、完全なクエリ結果をクライアントに返してクエリ要求を完了します。

図3

スケジューリング ノードは実行プラン ツリーを生成するときに、シャーディング ルールに従ってステートメントを並列実行用に変換し、再構築された SQL ステートメントを対応する実行プラン リーフ ノードからターゲット インスタンスにプッシュし、データ ノード インスタンスはシャードのクエリ実行プラン分析を完了します。

図 4 は、実行プラン リーフ ノードがクエリ要求をデータ ノードにプッシュする通信プロセスを示しています。 COM_QUERY は、クエリ ステートメントをカプセル化し、実行プランのリーフ ノードによってクエリ計算のために対応するデータ ノードに送信されるプロトコル パケットです。実行プランのリーフ ノードは、MySQL プロトコル プロセスを使用して結果セットを受信し、解析します。図の結果セットによって返されるプロトコル パッケージと順序は次のとおりです。

• ResultSetHead: 列番号情報を含む結果セット ヘッダー パッケージ。
• フィールド: 各フィールドの特定の情報が含まれる結果セット フィールド パッケージ。結果セット内の各フィールドは、フィールド プロトコル パッケージに対応します。
• すべてのフィールド情報が送信された後、バックエンド データ ノードは EOF プロトコル パケットを送信して行データの送信を開始します。
• RowData: 結果セットの行データ パケット。フィールド プロトコル パケットと同じです。各データ行は行データ パケットに対応します。したがって、一度送信される結果セットには、複数の行データ プロトコル パケットが含まれる場合があります。
• すべての行データ パケットが送信された後、サーバーは結果セットの送信の終了を示す EOF プロトコル パケットを送信します。

実行プランのリーフ ノードは、シャードのクエリ結果を受け取った後、各シャードの結果を親の非リーフ ノードに渡して、すべてのシャード結果のさらなる処理 (マージ、並べ替えなど) を行い、完全なクエリ データ結果をクライアントに返します。

図4

(III) 実行計画を表示するにはどうすればいいですか?

実行プランを表示するには、クエリの SELECT キーワードの前に DBSCALE EXPLAIN を追加するだけです。具体的な構文は次のとおりです。

DBSCALE EXPLAIN + SELECT クエリ ステートメント。

結果には、実行プランの各ステップの実行情報が含まれ、実行ノード、実行順序、実行 SQL コンテンツが表示されます。 SQL パフォーマンスは実行プランからも確認できます。 SQL ステートメントとテーブル構造のパフォーマンスのボトルネックを分析するために使用されます。

図5

上図 (図 5) に示すように、実行プランによって返される結果は、上部と下部の 2 つの結果セットに分かれています。最初の部分は、中間層グリッドからデータ ノードへのクエリ要求の完全な実行プランを示しています。結果セットの最初の 2 つの列は、中間層グリッドの SQL 実行プランです。つまり、exec_node フィールドには SQL 実行プラン ツリーが表示され、data_source には各シャード実行ノードに関係するシャード データ ソースが表示されます。結果セットの他のフィールドには、それぞれのデータ ノード上の各シャード クエリの実行プランが表示されます。これは、MySQLexplain によって返される結果と同じです。 2 番目の部分は、実行プランによって各実行ノードで実際に実行された再構築された SQL 文を示しているため、クライアントから受信した SQL 文とは異なる場合があります。

• 実行プランの重要なフィールドは次のとおりです。
• exec_node: 実行プラン ツリーの各実行ノード。列全体に完全な実行プラン ツリーが表示されます。先頭の「*」は実行プラン ツリーのルート ノードを示し、先頭の「-」は実行プラン ツリーの子ノードを示します。ダッシュが長いほど、ノード レベルが深くなります。上記の例に示すように、*MySQLSendNodeid はアスタリスク (*) で始まります。これは、この例のシャード クエリ実行プラン ツリーのルート ノードです。 --MySQLFetchNode は「--」で始まり、実行プラン ツリーの子ノードです。複数の FetchNode が対応するデータ ノードのデータ シャードを同時にクエリし、その後 SendNode が複数の FetchNode のクエリ結果を統合します。
• data_source: データソース情報。データ ソースは、クライアント要求を実行するためのデータベース接続を提供するデータベース インスタンス、つまり、MySQLFetchNode がクエリを実行するインスタンス アドレスです。
• id: クエリ内で選択句または操作テーブルが実行される順序。 ID が同じ場合、実行順序は上から下になります。 ID が異なる場合は、ID 値が大きいほど優先度が高くなり、早く実行されます。

select_type: データをクエリするための操作タイプ。次の表に示します。

table: 実行ノードによって処理されるテーブルの名前。

タイプ: データ ノードがテーブル内の必要な行を見つける方法。「アクセス タイプ」とも呼ばれ、次の意味を持ちます。|すべて |インデックス |範囲 |参照 |等価参照 |定数、システム |ヌル |左から右へ、最悪から最高へ。一般的なタイプを次の表に示します。

• possible_keys: データ ノードがテーブル内の行を見つけるために使用できるインデックスを示します。クエリに関係するフィールドにインデックスがある場合、そのインデックスはリストされますが、クエリでは使用されない可能性があります。
• key: クエリ内のデータ ノードによって実際に使用されるインデックスを表示します。インデックスが使用されていない場合はNULLとして表示されます。
• 注: クエリでカバーリング インデックスが使用されている場合、インデックスはキー リストにのみ表示されます。
• key_len: インデックスで使用されるバイト数を示します。この列は、クエリで使用されるインデックスの長さを計算するために使用できます。 key_len によって表示される値は、インデックス フィールドの最大可能長であり、実際に使用される長さではありません。つまり、key_len はテーブルから取得されるのではなく、テーブル定義に基づいて計算されます。
• ref: 上記のテーブルの接続一致条件、つまりインデックス列の値を見つけるために使用される列または定数を示します。
• 行数: テーブル統計とインデックス選択に基づいて、必要なレコードを見つけるためにデータ ノードが読み取る必要があると推定する行数を示します。
• 追加: データ ノードがクエリを解決する方法に関する詳細情報。次の使用は避けてください: ファイル ソートの使用と一時使用。

2 番目の部分には、node_id と sql の 2 つのフィールドが含まれます。 node_id は、最初の部分の exec_node フィールドの括弧内のシリアル番号に関連付けられており、exec_node の各レベルで実行される特定の SQL ステートメントを示します。特定の SQL ステートメントの内容は、「sql」フィールドに表示されます。

一時テーブル dbscale_tmp が "sql" フィールドに表示される場合 (dbscale_tmp は EverDB の予約語です)、現在の SELECT クエリにクロスシャード クエリが含まれており、システム パフォーマンスの低下が大きいことを意味します。 SQL ステートメントとテーブル構造のパフォーマンスのボトルネックをさらに分析し、一時テーブルの使用を可能な限り避ける必要があります。以下は例です。

図6

結論

ミドルウェアに基づくシャーディング ソリューションを実装する典型的な分散データベース製品である EverDB の実行プランは、基盤となるシャーディング テーブルでの SQL の実行手順と、プロキシが SQL を分散方式で処理する方法の両方を含むという点で、従来の集中型データベースとは異なり、分散データベースの処理パフォーマンスが向上します。これは、ミドルウェアに基づいて実行プランを実装する EverDB 独自の方法です。

EverDB 実行プランには、基盤となるデータ ノードや中間層、あるいは SQL 最適化アルゴリズムの観点から、最適化および改善が必要な領域がまだ数多くあります。 EverDBは今後も機能向上を続け、より優れた国産分散データベース製品を目指してまいります。