PolarDB:概要

概要

ePQ機能は、シングルノードelastic parallelクエリとマルチノードelastic parallelクエリの2つの並列エンジンをサポートしています。 シングルノード弾性並列クエリは、元の並列クエリ機能と同等です。 マルチノード弾性並列クエリは、クラスタ内のノード間の適応スケジューリングをサポートします。

PolarDB for MySQL 8.0.1は、単一ノードのエラスティック並列クエリのみをサポートします。 クエリデータは、ストレージ層の異なるスレッド間でシャードされます。 スレッドは並列に実行され、結果をリーダースレッドに返します。 次に、リーダースレッドは結果をマージし、最終結果をユーザーに返します。 これにより、照会効率が向上します。

PolarDB for MySQL 8.0.2は、シングルノードelastic parallelクエリとマルチノードelastic parallelクエリをサポートしています。 マルチノード弾性並列クエリは、線形アクセラレーション機能を大幅に改善し、マルチノード分散並列コンピューティングを実装します。 コストベースの最適化により、実行計画を柔軟に並列に実行できます。 これは、単一ノードのエラスティック並列クエリで発生する潜在的なリーダーのボトルネックとワーカーの負荷の不均衡に対処します。 これはまた、単一ノードのCPU、メモリ、およびI/Oボトルネックを克服する。 マルチノードのリソースビューと並列コンピューティングタスクの適応型スケジューリングは、並列コンピューティング機能を大幅に強化し、クエリ遅延を削減し、ノードのリソース負荷のバランスを取り、クラスタ全体のリソース使用量を改善します。

ePQ機能は、クラスター内のマルチコアCPUの並列処理機能を完全に使用することにより、クラウドベースのユーザーインスタンスでのCPUリソース使用率が低く不均一であるという問題に対処できます。 次の図は、8コア、32 GBのPolarDB for MySQLクラスター (専用仕様) でのプロセスを示しています。

前提条件

クラスターのバージョンを表示する方法については、「エンジンバージョンの照会」をご参照ください。

シナリオ

ePQ機能は、大規模なテーブルに対するクエリ、JOINステートメントを使用するマルチテーブルクエリ、大量のデータに対するクエリなど、ほとんどのSELECTステートメントに適用できます。 この機能は、短いクエリに対して大きな利点を提供しません。 多様な並列メソッドにより、この機能は次のシナリオに適しています。

• 膨大な量のデータに対する分析クエリ

  中程度または大量のデータが含まれる場合、分析クエリのSQL文は複雑で時間がかかることがよくあります。 ePQ機能を有効にすると、応答時間を線形に短縮できます。

• 不均衡なリソースロード

  PolarProxyの負荷分散機能は、クラスター内のノードに対して同様の数の接続が作成されるようにするのに役立ちます。 ただし、クエリのコンピューティングの複雑さとリソース使用量の違いにより、接続に基づく負荷分散は、ノード間の負荷の不均衡を完全に防ぐことはできません。 他の分散データベースと同様に、ホットスポットノードはPolarDBに悪影響を及ぼします。

  1. ホットスポット読み取り専用ノードが低速クエリを引き起こす場合、プライマリノードはアンドゥログをパージできず、ディスクが肥大化する可能性があります。

  2. ホットスポット読み取り専用ノードが遅いやり直し適用操作を引き起こす場合、プライマリノードはデータをフラッシュできず、書き込みスループットパフォーマンスが低下する可能性があります。

  ePQ機能は、ビューに基づくグローバルリソースビューと適応型タスクスケジューリングを導入します。 各ノードのリソース使用量とデータアフィニティの値に基づいて、一部またはすべてのクエリタスクがアイドルリソースを持つノードにスケジュールされ、クラスター内で必要な並列度 (DOP) とバランスの取れたリソース使用量を確保します。

  

• エラスティックコンピューティング

  伸縮性は、PolarDBのコア機能の1つです。 自動スケーリングは、短いクエリに適した弾力性を提供します。 ただし、大規模なクエリシナリオではノードを追加して単一のクエリを高速化できないため、複雑な分析クエリには適していません。 クラスターでePQ機能を有効にすると、新しくスケールアウトされたノードが自動的にクラスターに追加され、コンピューティングリソースを共有して弾力性を高めます。

  

• オンラインサービスとオフラインサービスの組み合わせ

  最も効果的な分離方法は、オンライントランザクションサービスとオフライン分析サービスを異なるノードセットにルーティングすることです。 しかしながら、この方法はコストを増大させる。 ほとんどの場合、オンライントランザクションサービスとオフライン分析サービスのピーク時間は異なります。 経済的な方法は、オンライントランザクションサービスとオフライン分析サービスとの間でクラスターリソースを共有し、それらのサービスを異なるクラスターエンドポイントにルーティングすることです。 ePQ機能を有効にすると、オンライントランザクションサービスのオフピーク時にアイドルリソースがオフライン分析サービスに配信され、コストを削減して効率を向上させます。

  

使用上の注意

ePQ機能の使用方法については、「使用方法」をご参照ください。

パフォーマンスメトリクス

次のテストでは、TPCベンチマークH (TPC-H) に基づいて生成された100 GBのデータを使用して、PolarDB for MySQL 8.0クラスターのパフォーマンスを調べます。 テストでは、PolarDBクラスターには、32 CPUコアと256 GBのメモリ (専用) を使用する4つのノードがあります。 シングルノードelastic parallelクエリの場合、max_parallel_degreeパラメーターは32と0に設定されます。 シーケンシャルクエリ、DOPが32のシングルノードエラスティックパラレルクエリ、DOPが128の4ノードエラスティックパラレルクエリのパフォーマンスデータを比較します。 詳細については、「並列クエリシナリオでのパフォーマンステストの結果」をご参照ください。

上記のテスト結果は、TPC-Hの100% のSQLクエリが高速化されていることを示しています。 クエリ速度は平均で17倍、最大で56倍です。

マルチノードエラスティックパラレルクエリを有効にすると、クエリ速度は平均で59倍、最大で159倍速くなります。

エラスティック並列クエリ実行プランの表示

EXPLAINステートメントを実行して、実行プランで弾性並列クエリ情報を表示する方法については、「EXPLAINステートメントを実行して弾性並列クエリ実行プランを表示する」をご参照ください。

用語

• パラレルスキャン

  並列スキャンでは、ワーカーはテーブルのデータを並列にスキャンします。 各ワーカーは部分的な結果を生成し、部分的な結果をリーダースレッドに返します。 リーダースレッドは、収集ノードを使用して結果を収集し、最終結果をクライアント側に返します。

• 複数のテーブルでの並列結合

  ePQ機能が有効になっている場合、マルチテーブル結合操作は並列処理のためにワーカーにプッシュダウンされます。 PolarDBオプティマイザは、並列スキャンに最適なテーブルを選択しますが、他のテーブルに対しては並列スキャンを実行しません。 各ワーカーは部分的な結果を生成し、部分的な結果をリーダースレッドに返します。 リーダースレッドは、収集ノードを使用して結果を収集し、最終結果をクライアントに返します。

• 並列ソート

  PolarDBオプティマイザは、並列ソートのためにORDER BY操作をすべてのワーカーにプッシュダウンします。 各ワーカーは部分的な結果を生成し、部分的な結果をリーダースレッドに返します。 リーダースレッドは、収集マージノードを使用してすべての部分的な結果を収集、マージ、およびソートし、最終的なソート結果をクライアント側に返します。

• 並列グループ化

  PolarDBオプティマイザは、並列処理のためにGROUP BY操作をワーカーにプッシュダウンします。 各ワーカーは、データの一部に対してGROUP BY操作を実行します。 各ワーカーは、GROUP BYの部分結果を生成し、その部分結果をリーダースレッドに返します。 リーダースレッドは、収集ノードを使用してすべてのワーカーから結果を収集します。 PolarDBオプティマイザは、クエリプランに基づいて、リーダースレッドでGROUP BY操作を再度実行するかどうかを決定します。 たとえば、緩いインデックススキャンを使用してGROUP BYステートメントを実行する場合、リーダースレッドはGROUP BY操作を実行しません。 緩いインデックススキャンが使用されない場合、リーダースレッドはGROUP BY操作を実行し、最終結果をクライアント側に返します。

• 並列集計

  ePQ機能が有効になっている場合、並列集約のために集約関数がすべてのワーカーに送信されます。 オプティマイザは、コストに基づいて、シリアル実行、1フェーズ集約、または2フェーズ集約のいずれを実行するかを決定します。

  • 1フェーズ集約: オプティマイザは、集約操作をワーカーに分散します。 各ワーカーには、グループ内のすべてのデータが含まれます。 したがって、第2フェーズの集約演算は不要である。 各ワーカーは、リーダースレッドが2回目の集計を実行するのを防ぐために、グループの最終集計結果を直接計算します。

  • 2フェーズの集約: 最初のフェーズでは、エラスティック並列クエリに関与する各ワーカーが集約を実行します。 2番目のフェーズでは、収集ノードまたは収集マージノードは、各ワーカーによって生成された結果をリーダースレッドに返します。 次に、リーダスレッドはすべてのワーカーからの結果を集約して最終結果を生成します。

  • 2フェーズのシャッフル集計: 最初のフェーズでは、エラスティック並列クエリの各ワーカーが集計を実行します。 2番目のフェーズでは、再分割ノードは、各ワーカーによって生成された結果を、グループ化された列によって複数のワーカーに分散します。 ワーカーは、最終的な集約計算を並行して完了します。 最後に、集計結果がリーダースレッドにまとめられます。

  PolarDBオプティマイザは、コストに基づいて特定の集計方法を決定します。

• パラレルウィンドウ関数

  PolarDBオプティマイザは、コンピューティングを実行し、コストに基づいて並列実行のためにウィンドウ関数をワーカーに配布します。 各ワーカーはデータの一部を計算します。 配布方法は、ウィンドウ関数のPARTITION by句のキーによって決まります。 ウィンドウ関数にPARTITION BY句が含まれていない場合は、シリアルコンピューティングが実行されます。 並列コンピューティングを後の時点で実行できる場合、後続のコンピューティングタスクは、コストに基づいて実行するために複数のワーカーに分散され、最大の並列化を保証します。

• サブクエリのサポート

  エラスティック並列クエリでは、次のいずれかのポリシーを使用してサブクエリを実行できます。

  • リーダースレッドでのシーケンシャル実行

    サブクエリが並列処理をサポートしていない場合、リーダースレッドのサブクエリは順番に実行されます。 たとえば、ユーザー定義関数 (UDF) を参照するJOIN句を使用して2つのテーブルを結合する場合、サブクエリは順番に実行されます。

  • リーダースレッドでの並列実行 (別のワーカーグループが使用されます)

    エラスティック並列クエリプランが生成された後、リーダースレッドの実行プランに並列処理をサポートするサブクエリが含まれている場合、これらの並列サブクエリを事前に実行することも、共有アクセスポリシーに基づいて並列に実行することもできません。 たとえば、サブクエリにウィンドウ関数が含まれている場合、サブクエリは共有アクセスポリシーに基づいて並列に実行できません。

  • 共有アクセス

    エラスティック並列クエリプランが生成された後、ワーカーの実行プランが並列処理をサポートするサブクエリを参照する場合、PolarDBオプティマイザは事前に並列サブクエリを実行します。 このようにして、ワーカーはサブクエリの結果に直接アクセスできます。

  • プッシュダウン

    エラスティック並列クエリプランが生成された後、ワーカーの実行プランが相関するサブクエリを参照する場合、ワーカーは相関するサブクエリを実行します。