Amazon Aurora MySQL の並列クエリの使用 - Amazon Aurora

Amazon Aurora MySQL の並列クエリの使用

以下は、MySQL と互換性がある Amazon Aurora の並列クエリ最適化機能についての説明です。この機能は、特定のデータ集約型クエリに対して特別な処理パスを使用し、Aurora 共有ストレージアーキテクチャを利用します。現在、MySQL 5.6 または MySQL 5.7 と互換性のある Aurora MySQL のバージョンでは、並列クエリがサポートされています。並列クエリは、数百万行のテーブルと完了までに数分または数時間かかる分析クエリを持つテーブルを持つ Aurora MySQL DB クラスターで最も効果的です。

Aurora MySQL の並列クエリの概要

Aurora MySQL 並列クエリは、データ集約的なクエリの処理に関連する I/O と計算の一部を並列処理する最適化です。並列処理される作業には、ストレージから行を取得し、列の値を抽出して、WHERE 句と結合句の条件に一致する行を判別することが含まれます。このデータ集約型の作業は、Aurora 分散ストレージレイヤー内の複数のノードに委譲されます (データベース最適化の用語では、プッシュダウンされます)。並列クエリがないと、各クエリはすべてのスキャンされたデータを Aurora MySQL クラスター (ヘッドノード) 内の単一のノードに持ち込み、そこですべてのクエリ処理を実行します。

ヒント

PostgreSQL データベースエンジンにも「並列クエリ」と呼ばれる機能があります。この機能は、Aurora の並列クエリとは異なります。

並列クエリ機能を有効にすると、Aurora MySQL エンジンは、ヒントやテーブル属性などの SQL の変更を必要とせずに、クエリがいつ利点を得られるかを自動的に判断します。以降のセクションで、並列クエリがいつクエリに適用されるかについて説明します。並列クエリが最も効果的な場所に適用されていることを確認する方法についても説明します。

注記

並列クエリの最適化は、完了までに数分や数時間といった長い時間がかかるクエリの場合に最もメリットがあります。Aurora MySQL は、通常、時間のかからないクエリには並列クエリの最適化を行いません。また、クエリのキャッシュ、バッファプールのキャッシュ、インデックスの検索などの別の最適化手法を使用したほうが効果的な場合も、通常は並列クエリの最適化を行いません。並列クエリが適切に使用されていない場合は、「並列クエリを使用しているステートメントの確認」を参照してください。

利点

並列クエリを使用すると、Aurora MySQL のテーブルに対してデータ集約型の分析クエリを実行できます。多くの場合、従来のようにクエリの処理を分ける場合よりもパフォーマンスが大幅に向上します。

並列クエリを使用すると、次のような利点があります。

  • 複数のストレージノード間で物理的な読み取りリクエストを並列処理するため、I/O パフォーマンスが向上しました。

  • ネットワークトラフィックが減少しました。Aurora は、ストレージノードからヘッドノードへのデータページ全体を送信せず、その後不要な行および列をフィルタリングしません。代わりに、Aurora は、結果セットに必要な列値のみを含むコンパクトなタプルを送信します。

  • 関数の処理、行のフィルタリング、および WHERE 句の列射影をプッシュダウンすることにより、ヘッドノードの CPU 使用率を削減しました。

  • バッファプールのメモリ負荷が低減されました。並列クエリによって処理されたページは、バッファプールに追加されません。これにより、データ集約型のスキャンで、頻繁に使用されるデータがバッファプールから削除されることが少なくなります。

  • 既存のデータに対して長時間実行される分析クエリを実用的に実行することで、抽出、変換、ロード (ETL) パイプラインでのデータ重複を潜在的に削減します。

アーキテクチャ

並列クエリ機能は、Aurora MySQL の主なアーキテクチャ原則を使用して、ストレージサブシステムからデータベースエンジンを切り離し、通信プロトコルを合理化してネットワークトラフィックを削減します。Aurora MySQL は、これらの手法を使用して、redo ログ処理などの書き込み重視の操作を高速化します。並列クエリは、同じ原則を読み取り操作に適用します。

注記

Aurora MySQL の並列クエリのアーキテクチャは、他のデータベースシステムの類似の名前の付いた特徴とは異なります。Aurora MySQL 並列クエリには対称型マルチプロセッシング (SMP) が含まれていないため、データベースサーバーの CPU 容量に依存しません。並列処理は、クエリコーディネーターとして機能する Aurora MySQL サーバーとは独立して、ストレージレイヤーで行われます。

並列クエリを使用しない場合のデフォルトの Aurora のクエリ処理では、Aurora クラスターの単一のノード (ヘッドノード) に raw データを送ります。Aurora は、その単一のノードの単一のスレッドでそのクエリのすべての処理を行います。並列クエリでは、この I/O 集約型および CPU 集約型の作業の多くは、ストレージレイヤー内のノードに委譲されます。結果セットのコンパクトな行のみがヘッドノードに戻されます (行はすでにフィルタリングされ、列の値はすでに抽出され、変換されています)。パフォーマンスの利点は、ネットワークトラフィックの削減、ヘッドノードでの CPU 使用率の削減、ストレージノード間の I/O の並列化から得られます。パラレル I/O、フィルタリング、および射影の量は、クエリを実行する Aurora クラスター内の DB インスタンスの数に依存しません。

前提条件

並列クエリのすべての機能を使用するには、バージョン 1.23 または 2.09 以上が実行されている Aurora MySQL DB クラスターが必要です。並列クエリを使用したいクラスターが既にある場合は、互換性のあるバージョンにアップグレードしてから並列クエリを有効にすることができます。その場合、これらの新しいバージョンでは設定名とデフォルト値が異なるため、「並列クエリのアップグレードに関する考慮事項」のアップグレード手順に従ってください。

また、MySQL 5.6 および 5.6.10a と互換性がある Aurora MySQL の特定の古いバージョン (MySQL 5.6 では 1.22.2、1.20.1、1.19.6) で並列クエリを使用することもできます。これらの古いバージョンの並列クエリのサポートは、特定の AWS リージョンでのみ利用できます。これらの古いバージョンには、以降で説明する追加の制限があります。また、Aurora MySQL の古いバージョンで並列クエリを使用するには、後で変更することができない特別なエンジンモードパラメータを持つ専用の DB クラスターを作成する必要もあります。このような理由から、実用性を重視する場合は Aurora MySQL 1.23 または 2.09 以上で並列クエリを使用することをお勧めします。

クラスターの DB インスタンスでは、db.r* インスタンスクラスを使用する必要があります。

テーブルに並列クエリの最適化を適用するには、テーブルがパーティション化されていない必要があります。

クラスターでは、ハッシュ結合の最適化を必ず有効にしてください。その手順は、クラスターで実行されている Aurora MySQL のバージョンが 1.23 または 2.09 よりも上か下かによって異なります。この方法については、「並列クエリクラスターのハッシュ結合の有効化」を参照してください。

aurora_parallel_queryaurora_disable_hash_join などのパラメータをカスタマイズするには、クラスターで使用するカスタムパラメータグループが必要です。これらのパラメータは、DB パラメータグループを使用して DB インスタンスごとに個別に指定することもできます。ただし、DB クラスターパラメータグループで指定することをお勧めします。これにより、クラスターのすべての DB インスタンスでこれらのパラメータの同じ設定が継承されます。

制約事項

並列クエリ機能には、次の制限が適用されます。

  • db.t2 または db.t3 インスタンスクラスでは、並列クエリは使用できません。この制限は、SQL ヒント句の aurora_pq_force を使用して並列クエリを行う場合にも適用されます。

  • 並列クエリは、COMPRESSED または REDUNDANT の行形式を使用するテーブルには適用されません。並列クエリを使用するテーブルには、COMPACT または DYNAMIC の行形式を使用してください。

  • 現在、並列クエリではパーティション分割されたテーブルはサポートされていません。並列クエリのクラスターでパーティション分割されたテーブルを使用できます。これらのテーブルに対するクエリでは、並列クエリ以外の処理方法が使用されます。

  • Aurora では、コストに基づくアルゴリズムを使用して、それぞれの SQL ステートメントに並列クエリを使用するかどうかを判断します。ステートメントで特定の SQL コンストラクトを使用すると、並列クエリを防止したり、そのステートメントで並列クエリが行われる可能性を低くしたりすることができます。SQL コンストラクトと並列クエリの互換性については、「SQL 構造での並列クエリの動作」を参照してください。

  • 各 Aurora DB インスタンスは、一度に特定の数の並列クエリセッションのみを実行できます。クエリにサブクエリ、結合、または UNION 演算子などの並列クエリを使用する複数の部分がある場合、それらのフェーズは順番に実行されます。このステートメントは、一度に 1 つの並列クエリセッションとしてカウントされます。並列クエリステータス変数を使用して、アクティブなセッションの数を監視できます。ステータス変数 Aurora_pq_max_concurrent_requests を照会することで、特定の DB インスタンスの同時セッションの制限を確認できます。

  • 並列クエリは、Aurora がサポートするすべての AWS リージョンで使用できます。ほとんどの AWS リージョンでは、並列クエリを使用するために必要な Aurora MySQL の最小バージョンは 1.23 または 2.09 です。詳細については、「Aurora 並列クエリ」を参照してください。

  • Aurora MySQL 1.22.2、1.20.1、1.19.6 および 5.6.10a のみ: これらの古いバージョンで並列クエリを使用するには、新しいクラスターを作成するか、既存の Aurora MySQL クラスターのスナップショットから復元する必要があります。

  • Aurora MySQL 1.22.2、1.20.1、1.19.6 および 5.6.10a のみ: 並列クエリでは、AWS Identity and Access Management (IAM) データベース認証はサポートされていません。

並列クエリクラスターの計画

並列クエリが有効な DB クラスターを計画するには、いくつかの選択を行う必要があります。これには、セットアップ手順の実行 (Aurora MySQL クラスター全体の作成または復元) と DB クラスター全体で並列クエリをどのように有効にするかの決定が含まれます。

計画の一環として、以下の点を検討してください。

  • クラスターに Aurora MySQL のどのバージョンを使用するかを選択します。 その選択に応じて、次のいずれかの方法を使用して、クラスターで並列クエリを有効にすることができます。

    MySQL 5.7 と互換性がある Aurora MySQL を使用する場合は、Aurora MySQL 2.09 以上を選択する必要があります。その場合、必ずプロビジョニングされたクラスターを作成します。その上で、aurora_parallel_query パラメータを使用して並列クエリを有効にします。Aurora の並列クエリを初めて使用する場合は、この方法をお勧めします。

    MySQL 5.6 と互換性がある Aurora MySQL を使用する場合は、バージョン 1.23 またはそれより下の特定のバージョンを選択できます。バージョン 1.23 以上では、プロビジョニングされたクラスターを作成し、DB クラスターパラメータの aurora_parallel_query を使用して並列クエリを有効にします。1.23 より下のバージョンでは、クラスターの作成時に parallelquery エンジンモードを選択します。その場合、クラスターで並列クエリが永続的に有効になります。parallelquery エンジンモードでは、その他の Aurora MySQL クラスターとの相互運用に制限があります。可能であれば、MySQL 5.6 と互換性があるバージョン 1.23 以上の Aurora MySQL を選択することをお勧めします。

    バージョン 1.23 以上または 2.09 以上が実行されている既存の Aurora MySQL クラスターがある場合は、並列クエリを使用するために新しいクラスターを作成する必要はありません。クラスターまたはクラスター内の特定の DB インスタンスを aurora_parallel_query パラメータが有効なパラメータグループに関連付けることができます。これにより、並列クエリで使用する関連データを設定する時間と手間を減らすことができます。

  • アクセス時に並列クエリを使用できるように見直す必要がある大きなテーブルについての計画を立てます。いくつかの大きなテーブルでは、並列クエリが役立つように新しいものを作成する必要がある場合があります。例えば、パーティション化されていないテーブルを作成したり、全文検索インデックスを削除したりすることが必要になる場合があります。詳細については、「並列クエリを利用するためのスキーマオブジェクトの作成」を参照してください。

並列クエリと Aurora MySQL のバージョンの互換性の確認

並列クエリを使用するクラスターと互換性のある Aurora MySQL のバージョンを確認するには、AWS CLI コマンドの describe-db-engine-versions を使用して、SupportsParallelQuery フィールドの値を確認します。次のコード例は、指定された AWS リージョンの並列クエリクラスターで使用可能な組み合わせを確認する方法を示しています。--query パラメータのすべての文字列は、必ず 1 行で指定してください。

aws rds describe-db-engine-versions --region us-east-1 --engine aurora --query '*[]|[?SupportsParallelQuery == `true`].[EngineVersion]' --output text aws rds describe-db-engine-versions --region us-east-1 --engine aurora-mysql --query '*[]|[?SupportsParallelQuery == `true`].[EngineVersion]' --output text

上記のコマンドを実行すると、次のような出力が返されます。この出力は、指定した AWS リージョンで使用可能な Aurora MySQL のバージョンによって異なります。

5.6.10a 5.6.mysql_aurora.1.19.0 5.6.mysql_aurora.1.19.1 5.6.mysql_aurora.1.19.2 5.6.mysql_aurora.1.19.3 5.6.mysql_aurora.1.19.3.1 5.6.mysql_aurora.1.19.3.90 5.6.mysql_aurora.1.19.4 5.6.mysql_aurora.1.19.4.1 5.6.mysql_aurora.1.19.4.2 5.6.mysql_aurora.1.19.4.3 5.6.mysql_aurora.1.19.4.4 5.6.mysql_aurora.1.19.4.5 5.6.mysql_aurora.1.19.5 5.6.mysql_aurora.1.19.5.90 5.6.mysql_aurora.1.19.6 5.6.mysql_aurora.1.20.1 5.6.mysql_aurora.1.22.0 5.6.mysql_aurora.1.22.2 5.6.mysql_aurora.1.23.0 5.7.mysql_aurora.2.09.0

クラスターで並列クエリの使用を開始したら、パフォーマンスをモニタリングして、並列クエリを使用する上での障害を取り除くことができます。これらの手順については、「並列クエリのパフォーマンスチューニング」を参照してください。

並列クエリを使用する DB クラスターの作成

並列クエリを使用して Aurora MySQL クラスターを作成したり、新しいインスタンスを追加したり、他の管理操作を実行するには、他の Aurora MySQL クラスターと同じ AWS マネジメントコンソール および AWS CLI テクニックを使用します。並列クエリを処理するための新しいクラスターを作成できます。また、並列クエリを使用する DB クラスターは、MySQL と互換性がある Aurora DB クラスターのスナップショットから復元することによって作成することもできます。新しい Aurora MySQL クラスターを作成するプロセスに詳しくない場合は、「Amazon Aurora DB クラスターの作成」の背景情報と前提条件を参照してください。

ただし、特定のオプションが異なります。

  • Aurora MySQL のエンジンのバージョンを選択する場合は、MySQL 5.7 と互換性がある最新のエンジンを選択することをお勧めします。現在、並列クエリは、Aurora MySQL 2.09 以上と MySQL 5.6 と互換性がある特定の Aurora MySQL のバージョンでサポートされています。Aurora MySQL 1.23 以上または 2.09 以上を使用すると、並列クエリの有効と無効を切り替えたり、既存のクラスターで並列クエリを使用したりできるため、柔軟性が増します。

  • バージョン 1.23 より前の Aurora MySQL の場合のみ: DB クラスターを作成または復元する場合は、必ず parallelquery エンジンモードを選択してください。

新しいクラスターを作成する場合でも、スナップショットから復元する場合でも、同じテクニックを使用して、他の Aurora MySQL クラスターで行う新しい DB インスタンスを追加できます。

コンソールを使用した並列クエリクラスターの作成

次のように、コンソールで新しい並列クエリクラスターを作成できます。

AWS マネジメントコンソール コンソールで並列クエリクラスターを作成するには

  1. Amazon Aurora DB クラスターの作成」一般的な AWS マネジメントコンソール の手順に従います。

  2. [Select engine (エンジンの選択)] 画面で、Aurora MySQL を選択します。

    実用性を重視する場合は、[Engine version (エンジンバージョン)] で Aurora MySQL 2.09 以上または Aurora MySQL 1.23 以上を選択します。これらのバージョンは、並列クエリの使用に関する制限が最も少なくなります。また、これらのバージョンは、いつでも並列クエリを有効または無効にできる最も高い柔軟性を備えています。

    クラスターで Aurora MySQL の最新のバージョンを使用するのが現実的でない場合は、[Show versions that support the parallel query feature (並列クエリ機能がサポートされているバージョンを表示)] をオンにします。これにより、[Version (バージョン)] メニューがフィルタリングされ、並列クエリと互換性がある特定の Aurora MySQL のバージョンのみが表示されます。

  3. (古いバージョンの場合のみ) [Capacity type (キャパシティータイプ)] で、[Provisioned with Aurora parallel query enabled (Aurora の並列クエリを有効にしてプロビジョニング済み)] を選択します。AWS マネジメントコンソール では、この選択肢は 1.23 より前のバージョンの Aurora MySQL を選択した場合にのみ表示されます。Aurora MySQL 1.23 以上または 2.09 以上では、クラスターと並列クエリの互換性のために特別な選択を行う必要はありません。

  4. (最新バージョンの場合のみ) [Additional configuration (追加設定)] で、[DB cluster parameter group (DB クラスターパラメータグループ)] のために作成したパラメータグループを選択します。Aurora MySQL 1.23 以上または 2.09 以上では、このようなカスタムパラメータグループを使用する必要があります。DB クラスターパラメータグループで、パラメータ設定の aurora_parallel_query=ONaurora_disable_hash_join=OFF を指定します。これにより、クラスターで並列クエリが有効になり、並列クエリと組み合わせて使用するハッシュ結合の最適化が有効になります。

新しいクラスターが並列クエリを使用できることを確認するには

  1. 上記の方法を使用してクラスターを作成します。

  2. (最新バージョンの場合のみ) aurora_parallel_query の設定が true で、aurora_disable_hash_join の設定が false になっていることを確認します。

    mysql> select @@aurora_parallel_query; +-------------------------+ | @@aurora_parallel_query | +-------------------------+ | 1 | +-------------------------+ mysql> select @@aurora_disable_hash_join; +----------------------------+ | @@aurora_disable_hash_join | +----------------------------+ | 0 | +----------------------------+
  3. (古いバージョンの場合のみ) aurora_pq_supported の設定が true になっていることを確認します。

    mysql> select @@aurora_pq_supported; +-----------------------+ | @@aurora_pq_supported | +-----------------------+ | 1 | +-----------------------+
  4. いくつかの大きなテーブルとデータ集約型のクエリについて、クエリの計画を確認して、一部のクエリで並列クエリの最適化を使用していることを確認します。これを行うには、「並列クエリを使用しているステートメントの確認」の手順に従います。

CLI を使用した並列クエリクラスターの作成

次のように、CLI で新しい並列クエリクラスターを作成できます。

AWS CLI コンソールで並列クエリクラスターを作成するには

  1. (オプション) 並列クエリを使用するクラスターと互換性のある Aurora MySQL のバージョンを確認します。これを行うには、describe-db-engine-versions コマンドを使用して、SupportsParallelQuery フィールドの値を確認します。例については、「並列クエリと Aurora MySQL のバージョンの互換性の確認」を参照してください。

  2. (オプション) aurora_parallel_query=ON 設定と aurora_disable_hash_join=OFF 設定を使用して、カスタム DB クラスターパラメータグループを作成します。以下のようなコマンドを使用します。

    aws rds create-db-cluster-parameter-group --db-parameter-group-family aurora-mysql5.7 --db-cluster-parameter-group-name pq-enabled-57-compatible aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name pq-enabled-57-compatible \ --parameters ParameterName=aurora_parallel_query,ParameterValue=ON,ApplyMethod=pending-reboot aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name pq-enabled-57-compatible \ --parameters ParameterName=aurora_disable_hash_join,ParameterValue=OFF,ApplyMethod=pending-reboot

    この手順を行う場合は、後続の create-db-cluster ステートメントで --db-cluster-parameter-group-name my_cluster_parameter_group オプションを指定します。パラメータグループの名前は、使用するものに置き換えてください。この手順を省略する場合は、「並列クエリの有効化と無効化」の説明に従って、後でパラメータグループを作成してクラスターに関連付けます。

  3. Amazon Aurora DB クラスターの作成」一般的な AWS CLI の手順に従います。

  4. 以下のオプションのセットを指定します。

    • --engine オプションには、aurora または aurora-mysql を使用します。これらの値は、それぞれ MySQL 5.6 または MySQL 5.7 と互換性がある並列クエリを使用するクラスターを生成します。

    • --engine-mode パラメータに使用する値は、選択したエンジンのバージョンによって異なります。

      Aurora MySQL 1.23 以上または 2.09 以上の場合は、--engine-mode provisioned を指定します。provisioned はデフォルトのため、--engine-mode パラメータを省略することもできます。これらのバージョンでは、常に並列クエリを使用する専用のクラスターを作成しなくても、ほぼデフォルトの Aurora MySQL クラスターで並列クエリの有効と無効を切り替えることができます。

      Aurora MySQL 1.23 より前のバージョンでは、--engine-mode オプションに parallelquery を使用します。--engine-mode パラメータは、create-db-cluster 操作に適用されます。その後、後続の create-db-instance 操作で自動的にクラスターのエンジンモードが使用されます。

    • --db-cluster-parameter-group-name オプションには、作成してパラメータの値に aurora_parallel_query=ON を指定した DB クラスターパラメータグループの名前を指定します。このオプションを省略すると、デフォルトのパラメータグループを使用してクラスターを作成してから、後でこのようなカスタムパラメータグループを使用するように変更できます。

    • --engine-version オプションには、並列クエリと互換性がある Aurora MySQL のバージョンを使用します。必要に応じて、「並列クエリクラスターの計画」の手順に従ってバージョンの一覧を取得します。実用性を重視する場合は、1.23.0 以上または 2.09.0 以上を使用してください。これらのバージョンでは、並列クエリが大幅に強化されています。

      次のサンプルはその方法を示しています。$CLUSTER_ID などの環境変数は、それぞれ使用する値に置き換えてください。

      aws rds create-db-cluster --db-cluster-identifier $CLUSTER_ID--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.09.0 \ --master-username $MASTER_USER_ID --master-user-password $MASTER_USER_PW \ --db-cluster-parameter-group-name $CUSTOM_CLUSTER_PARAM_GROUP aws rds create-db-cluster --db-cluster-identifier $CLUSTER_ID --engine aurora --engine-version 5.6.mysql_aurora.1.23.0 \ --master-username $MASTER_USER_ID --master-user-password $MASTER_USER_PW \ --db-cluster-parameter-group-name $CUSTOM_CLUSTER_PARAM_GROUP aws rds create-db-instance --db-instance-identifier ${INSTANCE_ID}-1 \ --engine same_value_as_in_create_cluster_command \ --db-cluster-identifier $CLUSTER_ID --db-instance-class $INSTANCE_CLASS
  5. 作成または復元したクラスターに並列クエリ機能が使用可能であることを確認します。

    Aurora MySQL 1.23 以上および 2.09 以上の場合: aurora_parallel_query の設定がされていることを確認します。この設定の値が 1 の場合は、並列クエリを使用する準備ができています。この設定の値が 0 の場合は、並列クエリを使用するために 1 に設定します。どちらの場合も、クラスターで並列クエリを実行できます。

    mysql> select @@aurora_parallel_query; +------------------------+ | @@aurora_parallel_query| +------------------------+ | 1 | +------------------------+

    Aurora MySQL 1.23 より前のバージョン: aurora_pq_supported の設定が true であることを確認します。

    mysql> select @@aurora_pq_supported; +-----------------------+ | @@aurora_pq_supported | +-----------------------+ | 1 | +-----------------------+

AWS CLI を使用してスナップショットをパラレルクエリクラスターに復元するには。

  1. 並列クエリを使用するクラスターと互換性のある Aurora MySQL のバージョンを確認します。これを行うには、describe-db-engine-versions コマンドを使用して、SupportsParallelQuery フィールドの値を確認します。例については、「並列クエリと Aurora MySQL のバージョンの互換性の確認」を参照してください。復元したクラスターで使用するバージョンを決定します。実用性を重視する場合は、MySQL 5.7 と互換性があるクラスターの場合は Aurora MySQL 2.09.0 以上、MySQL 5.6 と互換性があるクラスターの場合は 1.23.0 以上を選択します。

  2. Aurora MySQL と互換性があるクラスターのスナップショットを見つけます。

  3. DB クラスターのスナップショットからの復元」一般的な AWS CLI の手順に従います。

  4. --engine-mode パラメータに使用する値は、選択したエンジンのバージョンによって異なります。

    Aurora MySQL 1.23 以上または 2.09 以上の場合は、--engine-mode provisioned を指定します。provisioned はデフォルトのため、--engine-mode パラメータを省略することもできます。これらのバージョンでは、常に並列クエリを使用する専用のクラスターを作成しなくても、Aurora MySQL クラスターで並列クエリの有効と無効を切り替えることができます。

    Aurora MySQL 1.23 より前のバージョンでは、--engine-mode parallelquery を指定します。--engine-mode パラメータは、create-db-cluster 操作に適用されます。その後、後続の create-db-instance 操作で自動的にクラスターのエンジンモードが使用されます。

    aws rds restore-db-cluster-from-snapshot \ --db-cluster-identifier mynewdbcluster \ --snapshot-identifier mydbclustersnapshot \ --engine aurora --engine-mode parallelquery
  5. 作成または復元したクラスターに並列クエリ機能が使用可能であることを確認します。CLI を使用した並列クエリクラスターの作成 と同じ確認手順を使用してください。

並列クエリの有効化と無効化

注記

並列クエリが有効になっている場合、Aurora MySQL は実行時にクエリごとにそれを使用するかどうかを決定します。結合、ユニオン、サブクエリなどの場合、Aurora MySQL は各クエリブロックに対して実行時に並列クエリを使用するかどうかを決定します。詳細については、「並列クエリを使用しているステートメントの確認」および「SQL 構造での並列クエリの動作」を参照してください。

Aurora MySQL 1.23 以上および 2.09 以上

Aurora MySQL 1.23 以上および 2.09 以上では、aurora_parallel_query オプションを使用することによって、DB インスタンスのグローバルレベルとセッションレベルの両方で並列クエリを動的に有効または無効にすることができます。DB クラスターグループの aurora_parallel_query の設定を変更すると、デフォルトの並列クエリの有効と無効を切り替えることができます。

mysql> select @@aurora_parallel_query; +------------------------+ | @@aurora_parallel_query| +------------------------+ | 1 | +------------------------+

aurora_parallel_query パラメータをセッションレベルで切り替えるには、標準の方法を使用してクライアントの設定を変更します。例えば、mysql コマンドラインや JDBC または ODBC アプリケーションで変更できます。この標準の MySQL クライアントのコマンドは set session aurora_pq = {'ON'/'OFF'} です。セッションレベルのパラメータを JDBC コンフィグレーションまたはアプリケーションコード内に追加して、並列クエリを動的に有効または無効にすることもできます。

aurora_parallel_query パラメータの設定は、特定の DB インスタンスまたはクラスター全体に対して永続的に変更することができます。DB パラメータグループでこのパラメータの値を指定すると、その値はクラスターの特定の DB インスタンスにのみ適用されます。DB クラスターパラメータグループでこのパラメータの値を指定すると、クラスターのすべての DB インスタンスで同じ設定が継承されます。aurora_parallel_query パラメータをクラスターレベルで切り替えるには、「DB パラメータグループおよび DB クラスターパラメータグループを使用する」で説明されているパラメータグループの使用方法に従います。以下のステップに従ってください。

  1. カスタムクラスターパラメータグループ (推奨) またはカスタム DB パラメータグループを作成します。

  2. このパラメータグループで、parallel_query を必要な値に更新します。

  3. DB クラスターパラメータグループと DB パラメータグループのどちらを作成したかによって、並列クエリ機能を使用する Aurora クラスターまたは特定の DB インスタンスにパラメータグループをアタッチします。

    ヒント

    aurora_parallel_query は動的パラメータであるため、この設定を変更した後にクラスターを再起動する必要はありません。

並列クエリパラメータは、API オペレーションの ModifyDBClusterParameterGroupModifyDBParameterGroup または AWS マネジメントコンソールを使用して変更できます。

Aurora MySQL 1.23 より前のバージョン

これらの古いバージョンでは、aurora_pq オプションを使用することによって、DB インスタンスのグローバルレベルとセッションレベルの両方で並列クエリを動的に有効または無効にすることができます。並列クエリ機能が使用可能なクラスターでは、このパラメータはデフォルトで有効になっています。

mysql> select @@aurora_pq; +-------------+ | @@aurora_pq | +-------------+ | 1 | +-------------+

mysql コマンドラインや JDBC や ODBC アプリケーションなどで、セッションレベルで aurora_pq パラメータを切り替えるには、標準メソッドを使用してクライアントの設定を変更します。たとえば、標準の MySQL クライアント上のコマンドは、set session aurora_pq = {'ON'/'OFF'} です。セッションレベルのパラメータを JDBC コンフィグレーションまたはアプリケーションコード内に追加して、並列クエリを動的に有効または無効にすることもできます。

aurora_pq パラメータを永続的に切り替えるには、「DB パラメータグループおよび DB クラスターパラメータグループを使用する」で説明されているパラメータグループの使用方法に従います。以下のステップに従ってください。

  1. カスタムクラスターパラメータグループまたはカスタム DB インスタンスパラメータグループを作成します。クラスターパラメータグループを使用して、クラスターのすべての DB インスタンスで同じ設定が継承されるようにすることをお勧めします。

  2. このパラメータグループで、aurora_pq を必要な値に更新します。

  3. 並列クエリ機能を使用する Aurora クラスターにカスタムクラスターパラメータグループを関連付けます。または、カスタム DB パラメータグループを使用する場合は、クラスターの 1 つ以上の DB インスタンスに関連付けます。

  4. クラスターのすべての DB インスタンスを再起動します。

並列クエリパラメータは、API オペレーションの ModifyDBClusterParameterGroupModifyDBParameterGroup または AWS マネジメントコンソールを使用して変更できます。

注記

並列クエリが有効になっている場合、Aurora MySQL は実行時にクエリごとにそれを使用するかどうかを決定します。結合、ユニオン、サブクエリなどの場合、Aurora MySQL は各クエリブロックに対して実行時に並列クエリを使用するかどうかを決定します。詳細については、「並列クエリを使用しているステートメントの確認」および「SQL 構造での並列クエリの動作」を参照してください。

並列クエリクラスターのハッシュ結合の有効化

並列クエリは通常、ハッシュ結合の最適化による利点がある、大量のリソースを使用する種類のクエリに使用されます。そのため、並列クエリを使用するクラスターでハッシュ結合を有効にしておくと役立ちます。

  • バージョン 1.23 より前の MySQL 5.6 と互換性がある Aurora MySQL クラスターでは、並列クエリが有効なクラスターで常にハッシュ結合を使用できます。この場合、ハッシュ結合機能についての操作を行う必要はありません。このようなクラスターにアップグレードする場合は、アップグレード時にハッシュ結合を有効にする必要があります。

  • Aurora MySQL 1.23 以上または 2.09 以上では、並列クエリとハッシュ結合の設定はどちらもデフォルトで無効になっています。このようなクラスターで並列クエリを有効にする場合は、ハッシュ結合も有効にします。これを行う最も簡単な方法は、クラスターの設定パラメータの aurora_disable_hash_join=OFF を設定することです。ハッシュ結合を有効にして効果的に使用する方法については、「Aurora MySQL でのハッシュ結合の使用」を参照してください。

コンソールを使用した並列クエリの有効化と無効化

パラメータグループを使用して、DB インスタンスレベルまたは DB クラスターレベルで並列クエリを有効または無効にすることができます。

AWS マネジメントコンソールを使用して DB クラスターで並列クエリを有効または無効にするには

  1. DB パラメータグループおよび DB クラスターパラメータグループを使用する」の説明に従って、カスタムパラメータグループを作成します。

  2. Aurora MySQL 1.23 以上および 2.09 以上の場合: aurora_parallel_query1 (有効) または 0 (無効) に更新します。並列クエリ機能を使用できるクラスターでは、aurora_parallel_query はデフォルトで有効になっています。

    Aurora MySQL 1.23 より前のバージョンの場合: aurora_pq1 (有効) または 0 (無効) に更新します。並列クエリ機能が利用できるクラスターでは、aurora_pq はデフォルトで有効になっています。

  3. カスタムクラスターパラメータグループを使用する場合は、並列クエリ機能を使用する Aurora DB クラスターにアタッチします。カスタム DB パラメータグループを使用する場合は、クラスターの 1 つ以上の DB インスタンスにアタッチします。クラスターパラメータグループを使用することをお勧めします。そうすることにより、クラスターのすべての DB インスタンスで並列クエリとそれに関連するハッシュ結合などの機能の設定が同じになります。

CLI を使用した並列クエリの有効化と無効化

並列クエリのパラメータは、modify-db-cluster-parameter-group または modify-db-parameter-group コマンドを使用して変更することができます。DB クラスターパラメータグループまたは DB パラメータグループのどちらを使用して aurora_parallel_query の値を指定するかに応じて、適切なコマンドを選択してください。

CLI を使用して DB クラスターで並列クエリを有効または無効にするには

  • 並列クエリパラメータは、modify-db-cluster-parameter-group コマンドを使用して変更します。以下のようなコマンドを使用します。カスタムパラメータグループの名前は、使用する適切なものに置き換えてください。--parameters オプションの ParameterValue の部分の ON または OFF も置き換えてください。

    # Aurora MySQL 1.23 or 2.09 and higher: $ aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name cluster_param_group_name \ --parameters ParameterName=aurora_parallel_query,ParameterValue=ON,ApplyMethod=pending-reboot { "DBClusterParameterGroupName": "cluster_param_group_name" } # Before Aurora MySQL 1.23: $ aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name cluster_param_group_name \ --parameters ParameterName=aurora_pq,ParameterValue=ON,ApplyMethod=pending-reboot { "DBClusterParameterGroupName": "cluster_param_group_name" }

また、mysql コマンドラインや JDBC や ODBC アプリケーションなどで、セッションレベルで並列クエリを有効または無効にすることもできます。これを行うには、標準メソッドを使用してクライアントの構成設定を変更します。例えば、Aurora MySQL 1.23 以上または 2.09 以上では、この標準の MySQL クライアントのコマンドは set session aurora_parallel_query = {'ON'/'OFF'} です。Aurora MySQL 1.23 より前のバージョンでは、このコマンドは set session aurora_pq = {'ON'/'OFF'} です。

セッションレベルのパラメータを JDBC コンフィグレーションまたはアプリケーションコード内に追加して、並列クエリを動的に有効または無効にすることもできます。

並列クエリのアップグレードに関する考慮事項

Aurora MySQL 1.23 以上または 2.09 以上では、並列クエリはプロビジョニングされたクラスターで使用できるため、parallelquery エンジンモードパラメータは必要ありません。そのため、これらのバージョンで並列クエリを使用するために新しいクラスターを作成したり、既存のスナップショットから復元したりする必要はありません。これらのバージョンでは、「Aurora MySQL DB クラスターのマイナーバージョンまたはパッチレベルのアップグレード」で説明されているアップグレード手順に従ってクラスターをアップグレードできます。古いクラスターでは、並列クエリを使用するクラスターかプロビジョニングされたクラスターかにかかわらずアップグレードできます。[Engine version (エンジンバージョン)] メニューの選択肢の数を減らすには、[Show versions that support the parallel query feature (並列クエリ機能がサポートされているバージョンを表示)] をオンにしてメニューのエントリをフィルタリングします。その上で、Aurora MySQL 1.23 以上または 2.09 以上を選択します。

以前のバージョンの並列クエリを使用するクラスターを Aurora MySQL 1.23 以上または 2.09 以上にアップグレードしたら、アップグレードしたクラスターで並列クエリを有効にします。これらのバージョンでは並列クエリはデフォルトで無効になっており、有効にする手順も異なります。また、ハッシュ結合の最適化もデフォルトで無効になっているため、個別に有効にする必要があります。そのため、アップグレード後には、これらの設定をもう一度有効にするようにしてください。その手順については、「並列クエリの有効化と無効化」および「並列クエリクラスターのハッシュ結合の有効化」を参照してください。

特に注意が必要なのは、aurora_pq_supportedaurora_pq ではなく、aurora_parallel_query=ONaurora_disable_hash_join=OFF 設定パラメータを使用して並列クエリを有効にすることです。aurora_pq_supported パラメータと aurora_pq パラメータは、Aurora MySQL の新しいバージョンでは非推奨になっています。

アップグレードしたクラスターでは、EngineMode 属性の値は parallelquery ではなく、provisioned になります。指定したエンジンバージョンで並列クエリが使用できるかどうかを確認するには、AWS CLI コマンドの describe-db-engine-versions の出力の SupportsParallelQuery フィールドの値を確認します。Aurora MySQL の以前のバージョンでは、SupportedEngineModes の一覧に parallelquery があることを確認していました。

Aurora MySQL 1.23 以上または 2.09 以上にアップグレードすると、以下の機能を利用できるようになります。これらの機能は、Aurora MySQL の古いバージョンが実行されている並列クエリを使用するクラスターでは使用できません。

並列クエリのパフォーマンスチューニング

並列クエリを使用してワークロードのパフォーマンスを管理するには、この最適化が最も役立つクエリに対して並列クエリが使用されていることを確認します。

そのためには、以下を実行できます。

  • 大きなテーブルが並列クエリと互換性があるようにします。テーブルのプロパティを変更したり、一部のテーブルを作成し直したりして、それらのテーブルに対するクエリで並列クエリの最適化を利用できるようにします。この方法については、「並列クエリを利用するためのスキーマオブジェクトの作成」を参照してください。

  • 並列クエリを使用するクエリを監視します。この方法については、「並列クエリのモニタリング」を参照してください。

  • 並列クエリが最もデータ集約型で実行に時間がかかるクエリに使用され、ワークロードに適したレベルの同時実行性があることを確認します。この方法については、「並列クエリを使用しているステートメントの確認」を参照してください。

  • SQL のコードを調整して、並列クエリを目的のクエリに適用できるようにします。この方法については、「SQL 構造での並列クエリの動作」を参照してください。

並列クエリを利用するためのスキーマオブジェクトの作成

並列クエリで使用するテーブルを作成または変更するには、「前提条件」および「制約事項」で説明されている要件を理解しておく必要があります。

並列クエリでは、テーブルに ROW_FORMAT=Compact または ROW_FORMAT=Dynamic の設定が使用されている必要があるため、Aurora の設定で INNODB_FILE_FORMAT 設定オプションへの変更を確認してください。SHOW TABLE STATUS ステートメントを発行して、データベース内のすべてのテーブルの行形式を確認します。

並列クエリは、現在、パーティション分割されないテーブルが必要です。そのため、CREATE TABLE ステートメントと SHOW CREATE TABLE 出力を確認し、PARTITION BY 句を削除してください。既存のパーティションテーブルの場合は、最初に、同じ列定義とインデックスを持つパーティション分割されていないテーブルにデータをコピーします。次に、既存のクエリおよび ETL ワークフローでパーティション分割されていないテーブルを使用するように、古いテーブルと新しいテーブルの名前を変更します。

並列クエリがより多くのテーブルで効果があるようにスキーマを変更するには、テストが必要です。テストでは、並列クエリによってそれらのテーブルのパフォーマンスが実際に向上するかどうかを確認する必要があります。また、並列クエリのスキーマ要件が目標に適合していることを確認してください。

例えば、ROW_FORMAT=Compressed から ROW_FORMAT=Compact または ROW_FORMAT=Dynamic に切り替える前には、元のテーブルと新しいテーブルでワークロードのパフォーマンスをテストします。また、データ量の増加などの潜在的な影響も考慮してください。

並列クエリを使用しているステートメントの確認

一般的な操作では、並列クエリを利用するために特別なアクションを実行する必要はありません。クエリが並列クエリの必須要件を満たした後、クエリオプティマイザは、特定のクエリごとに並列クエリを使用するかどうかを自動的に決定します。

開発環境やテスト環境で実験を行うと、テーブルの行数や全体のデータ量が少ないために並列クエリが使用されないことがあります。テーブルのデータは、バッファプールに完全に含まれている場合があります。特に、最近実験を実行するために作成したテーブルの場合があります。

クラスターのパフォーマンスをモニタリングまたは調整する場合は、並列クエリが適切な状況で使用されているかどうかを確認する必要があります。この機能を利用するには、データベースのスキーマ、設定、SQL クエリ、またはクラスタートポロジとアプリケーションの接続設定を調整する必要があります。

クエリで並列クエリが使用されているかどうかを確認するには、EXPLAIN ステートメントを実行してクエリプラン (explain プラン) を確認します。並列クエリの EXPLAIN 出力に SQL ステートメント、句および式がどのように影響するかの例は、「SQL 構造での並列クエリの動作」を参照してください。

次の例は、従来のクエリプランと並列クエリプランの違いを示しています。この explain プランは、TPC-H ベンチマークのクエリ 3 のものです。このセクションのサンプルクエリの多くは、TPC-H データセットのテーブルを使用しています。テーブル定義、クエリ、サンプルデータを生成する dbgen プログラムは、TPC-H のウェブサイトから入手できます。

EXPLAIN SELECT l_orderkey, sum(l_extendedprice * (1 - l_discount)) AS revenue, o_orderdate, o_shippriority FROM customer, orders, lineitem WHERE c_mktsegment = 'AUTOMOBILE' AND c_custkey = o_custkey AND l_orderkey = o_orderkey AND o_orderdate < date '1995-03-13' AND l_shipdate > date '1995-03-13' GROUP BY l_orderkey, o_orderdate, o_shippriority ORDER BY revenue DESC, o_orderdate LIMIT 10;

デフォルトでは、クエリには以下のようなプランがあります。クエリプランでハッシュ結合が使用されていない場合は、最適化が有効になっていることをまず確認してください。

+----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+ | 1 | SIMPLE | customer | NULL | ALL | NULL | NULL | NULL | NULL | 1480234 | 10.00 | Using where; Using temporary; Using filesort | | 1 | SIMPLE | orders | NULL | ALL | NULL | NULL | NULL | NULL | 14875240 | 3.33 | Using where; Using join buffer (Block Nested Loop) | | 1 | SIMPLE | lineitem | NULL | ALL | NULL | NULL | NULL | NULL | 59270573 | 3.33 | Using where; Using join buffer (Block Nested Loop) | +----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+

次のステートメントを発行すると、セッションレベルでハッシュ結合を有効にできます。その後で、EXPLAIN ステートメントをもう一度試してください。

SET optimizer_switch='hash_join=on';

ハッシュ結合を永続的に有効にして効果的に使用する方法については、「Aurora MySQL でのハッシュ結合の使用」を参照してください。

ハッシュ結合が有効で並列クエリが無効な場合は、クエリプランは次のようなものになります。このプランでは、ハッシュ結合は使用されていますが、並列クエリは使用されていません。

+----+-------------+----------+...+-----------+-----------------------------------------------------------------+ | id | select_type | table |...| rows | Extra | +----+-------------+----------+...+-----------+-----------------------------------------------------------------+ | 1 | SIMPLE | customer |...| 5798330 | Using where; Using index; Using temporary; Using filesort | | 1 | SIMPLE | orders |...| 154545408 | Using where; Using join buffer (Hash Join Outer table orders) | | 1 | SIMPLE | lineitem |...| 606119300 | Using where; Using join buffer (Hash Join Outer table lineitem) | +----+-------------+----------+...+-----------+-----------------------------------------------------------------+

並列クエリを有効にすると、次の EXPLAIN の出力の Extra 列に示されているように、このクエリプランの 2 つのステップで並列クエリの最適化を使用できます。これらのステップに対する I/O 集約型および CPU 集約型の処理は、ストレージレイヤーにプッシュダウンされます。

+----+...+--------------------------------------------------------------------------------------------------------------------------------+ | id |...| Extra | +----+...+--------------------------------------------------------------------------------------------------------------------------------+ | 1 |...| Using where; Using index; Using temporary; Using filesort | | 1 |...| Using where; Using join buffer (Hash Join Outer table orders); Using parallel query (4 columns, 1 filters, 1 exprs; 0 extra) | | 1 |...| Using where; Using join buffer (Hash Join Outer table lineitem); Using parallel query (4 columns, 1 filters, 1 exprs; 0 extra) | +----+...+--------------------------------------------------------------------------------------------------------------------------------+

並列クエリの出力および並列クエリが適用できる SQL ステートメントの部分の EXPLAIN 出力を解釈する方法については、「SQL 構造での並列クエリの動作」を参照してください。

次の出力例は、コールドバッファプールを持つ db.r4.2xlarge インスタンスで前のクエリを実行した結果を示しています。並列クエリを使用すると、クエリが大幅に高速化されます。

注記

タイミングは多くの環境要因に依存し、この例のクエリは初期のバージョンの並列クエリを使用して実行されているため、結果は異なる場合があります。自分の環境、ワークロードなどで結果を確認するには、常に独自のパフォーマンステストを実施してください。

-- Without parallel query +------------+-------------+-------------+----------------+ | l_orderkey | revenue | o_orderdate | o_shippriority | +------------+-------------+-------------+----------------+ | 92511430 | 514726.4896 | 1995-03-06 | 0 | . . | 28840519 | 454748.2485 | 1995-03-08 | 0 | +------------+-------------+-------------+----------------+ 10 rows in set (24 min 49.99 sec)
-- With parallel query +------------+-------------+-------------+----------------+ | l_orderkey | revenue | o_orderdate | o_shippriority | +------------+-------------+-------------+----------------+ | 92511430 | 514726.4896 | 1995-03-06 | 0 | . . | 28840519 | 454748.2485 | 1995-03-08 | 0 | +------------+-------------+-------------+----------------+ 10 rows in set (1 min 49.91 sec)

このセクション全体のサンプルクエリの多くは、この TPC-H データセットのテーブル、特に 2000 万行と以下の定義を持つ PART テーブルを使用しています。

+---------------+---------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +---------------+---------------+------+-----+---------+-------+ | p_partkey | int(11) | NO | PRI | NULL | | | p_name | varchar(55) | NO | | NULL | | | p_mfgr | char(25) | NO | | NULL | | | p_brand | char(10) | NO | | NULL | | | p_type | varchar(25) | NO | | NULL | | | p_size | int(11) | NO | | NULL | | | p_container | char(10) | NO | | NULL | | | p_retailprice | decimal(15,2) | NO | | NULL | | | p_comment | varchar(23) | NO | | NULL | | +---------------+---------------+------+-----+---------+-------+

ワークロードを試して、個々の SQL ステートメントが並列クエリを利用できるかどうかを理解してください。次に、以下のモニタリング方法を使用して、実際のワークロードで並列クエリが使用される頻度を時間をかけて確認します。実際のワークロードでは、同時実行制限などの追加の要素が適用されます。

並列クエリのモニタリング

Amazon Aurora を使用した Amazon CloudWatch メトリクスのモニタリング で説明されている Amazon CloudWatch メトリクスに加えて、Aurora は他のグローバルなステータス変数を提供します。これらのグローバルステータス変数を使用して、並列クエリの実行のモニタリングに役立てることができます。これらの変数からは、オプティマイザが特定の状況で並列クエリを使用したり、使用しなかったりする理由についてのインサイトを得ることができます。これらの変数にアクセスするには、SHOW GLOBAL STATUS コマンドを使用します。これらの変数は次のとおりです。

並列クエリセッションは、データベースによって実行されるクエリと必ずしも 1 対 1 のマッピングにはなっていません。例えば、クエリプランに並列クエリを使用する 2 つのステップがあるとします。この場合、クエリには 2 つの並列セッションが含まれ、試行された要求と成功したリクエストのカウンターは 2 つずつ増分されます。

EXPLAIN ステートメントを発行して並列クエリを試してみると、実際にはクエリが実行されていなくても「選択されていません」と指定されたカウンターの増加が見込まれます。本稼働環境で並列クエリを処理する場合、「選択されていない」カウンターが予想どおりに高速に増加しているかどうかを確認できます。その段階で、目的のクエリで並列クエリが実行されるように調整できます。これは、並列クエリが有効になっているクラスターの設定、クエリの組み合わせ、DB インスタンスなどを変更することによって行うことができます。

これらのカウンターは、DB インスタンスレベルで追跡されます。別のエンドポイントに接続すると、各 DB インスタンスが独自の並列クエリセットを実行するため、別のメトリクスが表示されることがあります。リーダーエンドポイントがセッションごとに異なる DB インスタンスに接続すると、別のメトリクスが表示されることもあります。

名前

説明

Aurora_pq_request_attempted

リクエストされた並列クエリセッションの数。この値は、サブクエリや結合などの SQL 構成に応じて、クエリごとに複数のセッションを表す場合があります。

Aurora_pq_request_executed

並列クエリセッションの数は正常に実行されます。

Aurora_pq_request_failed

クライアントにエラーを戻した並列クエリセッションの数。場合によっては、たとえば、ストレージレイヤーの問題のために、並列クエリのリクエストが失敗することがあります。このような場合、失敗したクエリ部分は、非並列クエリメカニズムを使用して再試行されます。再試行されたクエリも失敗すると、エラーがクライアントに返され、このカウンターが増分されます。

Aurora_pq_pages_pushed_down

並列クエリがヘッドノードへのネットワーク送信を回避したデータページ数 (それぞれ 16 KiB の固定サイズ)。

Aurora_pq_bytes_returned

並列クエリ中にヘッドノードに送信されたタプルデータ構造のバイト数。Aurora_pq_pages_pushed_down と比較するために 16,384 で割ります。

Aurora_pq_request_not_chosen

クエリを満たすために並列クエリが選択されなかった回数。この値は、他のいくつかのより細かいカウンターの合計です。EXPLAIN ステートメントでは、クエリが実際に実行されていない場合でもこのカウンターは増加します。

Aurora_pq_request_not_chosen_below_min_rows

テーブル内の行数のために並列クエリが選択されなかった回数。EXPLAIN ステートメントでは、クエリが実際に実行されていない場合でもこのカウンターは増加します。

Aurora_pq_request_not_chosen_small_table

行数および平均行長によって決定される、テーブルの全体的なサイズのために並列クエリが選択されなかった回数。EXPLAIN ステートメントでは、クエリが実際に実行されていない場合でもこのカウンターは増加します。

Aurora_pq_request_not_chosen_high_buffer_pool_pct

テーブルデータの高パーセンテージ (現在は 95 パーセント以上) がすでにバッファプールに入っていたため、並列クエリが選択されなかった回数。このような場合、オプティマイザは、バッファプールからのデータの読取りがより効率的であると判断します。EXPLAIN ステートメントでは、クエリが実際に実行されていない場合でもこのカウンターは増加します。

Aurora_pq_request_not_chosen_few_pages_outside_buffer_pool

並列クエリを価値のあるものにするためのバッファされていないテーブルデータが十分ないため、テーブルデータの 95 パーセント未満がバッファプールにあったにもかかわらず、並列クエリの回数は選択されませんでした。

Aurora_pq_max_concurrent_requests

この Aurora DB インスタンスで同時に実行できる並列クエリセッションの最大数。これは、AWS の DB インスタンスクラスによって異なる固定の数です。

Aurora_pq_request_in_progress

現在進行中の並列クエリセッションの数。この数は、Aurora DB クラスター全体ではなく、接続している特定の Aurora DB インスタンスのものが適用されます。DB インスタンスが同時実行の制限に近いかどうかを調べるには、この値を Aurora_pq_max_concurrent_requests と比較します。

Aurora_pq_request_throttled

特定の Aurora DB インスタンスですでに実行されている同時並列クエリの最大数のために、並列クエリが選択されなかった回数。

Aurora_pq_request_not_chosen_long_trx

長時間実行トランザクション内でクエリが開始されているために、非並列クエリ処理パスを使用した並列クエリリクエストの数。EXPLAIN ステートメントでは、クエリが実際に実行されていない場合でもこのカウンターは増加します。

Aurora_pq_request_not_chosen_unsupported_access

WHERE 句が並列クエリの基準を満たしていないために、非並列クエリ処理パスを使用する並列クエリリクエストの数。この結果は、クエリがデータ集約型スキャンを必要としない場合、またはクエリが DELETE または UPDATE ステートメントである場合に発生します。

Aurora_pq_request_not_chosen_column_bit

射影された列の中にサポートされていないデータ型があるために、並列クエリ以外の処理方法が使用される並列クエリのリクエスト数。

Aurora_pq_request_not_chosen_column_geometry

テーブルに GEOMETRY データ型の列があるために、並列クエリ以外の処理方法が使用される並列クエリのリクエスト数。

Aurora_pq_request_not_chosen_column_lob

テーブルに LOB データ型の列または宣言された長さにより外部に格納された VARCHAR の列があるために、並列クエリ以外の処理方法が使用される並列クエリのリクエスト数。

Aurora_pq_request_not_chosen_column_virtual

テーブルに仮想列があるために、並列クエリ以外の処理方法が使用される並列クエリのリクエスト数。

Aurora_pq_request_not_chosen_custom_charset

テーブルにカスタム文字セットの列があるために、並列クエリ以外の処理方法が使用される並列クエリのリクエスト数。

Aurora_pq_request_not_chosen_fast_ddl

テーブルが高速 DDL の ALTER ステートメントによって変更中であるために、並列クエリ以外の処理方法が使用される並列クエリのリクエスト数。

Aurora_pq_request_not_chosen_full_text_index

テーブルに全文インデックスがあるために、並列クエリ以外の処理方法が使用される並列クエリのリクエスト数。

Aurora_pq_request_not_chosen_index_hint

クエリにインデックスヒントが含まれているために、並列クエリ以外の処理方法が使用される並列クエリのリクエスト数。

Aurora_pq_request_not_chosen_innodb_table_format

テーブルでサポートされていない InnoDB の行形式を使用しているために、並列クエリ以外の処理方法が使用される並列クエリのリクエスト数。Aurora の並列クエリは、COMPACTREDUNDANTDYNAMIC 行形式にのみ適用されます。

Aurora_pq_request_not_chosen_no_where_clause

クエリに WHERE 句がないために、並列クエリ以外の処理方法が使用される並列クエリのリクエスト数。

Aurora_pq_request_not_chosen_range_scan

インデックスの範囲スキャンを使用しているために、並列クエリ以外の処理方法が使用される並列クエリのリクエスト数。

Aurora_pq_request_not_chosen_row_length_too_long

すべての列の合計長が長すぎるために、並列クエリ以外の処理方法が使用される並列クエリのリクエスト数。

Aurora_pq_request_not_chosen_temporary_table

クエリでサポートされていない MyISAM また memory テーブルタイプを使用している一時テーブルを参照しているために、並列クエリ以外の処理方法が使用される並列クエリのリクエスト数。

Aurora_pq_request_not_chosen_tx_isolation

クエリでサポートされていないトランザクション分離レベルを使用しているために、並列クエリ以外の処理方法が使用される並列クエリのリクエスト数。リーダー DB インスタンスでは、並列クエリは REPEATABLE READ および READ COMMITTED 分離レベルにのみ適用されます。

Aurora_pq_request_not_chosen_update_delete_stmts

クエリが UPDATE または DELETE ステートメントの一部であるために、並列クエリ以外の処理方法が使用される並列クエリのリクエスト数。

SQL 構造での並列クエリの動作

このセクションでは、特定の SQL ステートメントで並列クエリが使用される理由と使用されない理由について詳しく説明します。また、Aurora MySQL の機能と並列クエリのインタラクションについても説明します。これらの内容は、並列クエリを使用するクラスターのパフォーマンスの問題を診断したり、特定のワークロードに並列クエリがどのように適用されるかを理解したりするために役立ちます。

並列クエリを使用するかどうかの決定は、ステートメントが実行される時点で発生する多くの要因に依存します。したがって、並列クエリは、特定の条件の下で常に使用される、特定の条件の下では決して使用されない、または特定の条件の下でのみ使用される特定のクエリに対して使用される可能性があります。

ヒント

以下の例を HTML で表示している場合は、記載されている各コードの右上隅にあるコピーウィジェットを使用して SQL コードをコピーして使用することができます。このコピーウィジェットを使用すると、mysql> プロンプトとそれに続く -> の行の周りの余分な文字がコピーされません。

EXPLAIN ステートメント

このセクションの例で示すように、EXPLAIN ステートメントは、クエリの各ステージが現在並列クエリに適しているかどうかを示します。また、クエリのどの側面をストレージレイヤーにプッシュダウンできるかを示します。以下に、クエリプランで最も重要な点を示します。

  • key 列の NULL 以外の値は、インデックスのルックアップを使用してクエリを効率的に実行できることを示しています。また並列クエリは効率的には実行できません。

  • rows 列の値が小さい場合 (値が百万単位に達しない場合) は、クエリでアクセスしているデータが並列クエリが役立つほどの量ではないことを示しています。そのため、並列クエリが使用されることはあまりありません。

  • Extra 列には、並列クエリを使用することが予想されるかどうかを示します。この出力は、次の例のようになります。

    Using parallel query (A columns, B filters, C exprs; D extra)

    columns の数は、クエリブロックで参照される列の数を表します。

    filters の数は、列の値と定数の簡単な比較を表す WHERE 述語の数を表します。比較は、等価、不等値、または範囲にすることができます。Aurora は、これらの種類の述語を最も効果的に並列化できます。

    exprs の数は、関数呼び出し、演算子、または並列化できる他の式の数を表しますが、フィルター条件ほど効果的ではありません。

    extra の数は、プッシュダウンできず、ヘッドノードによって実行される式の数を表します。

たとえば、次の EXPLAIN 出力を考えてみます。

mysql> explain select p_name, p_mfgr from part -> where p_brand is not null -> and upper(p_type) is not null -> and round(p_retailprice) is not null; +----+-------------+-------+...+----------+----------------------------------------------------------------------------+ | id | select_type | table |...| rows | Extra | +----+-------------+-------+...+----------+----------------------------------------------------------------------------+ | 1 | SIMPLE | part |...| 20427936 | Using where; Using parallel query (5 columns, 1 filters, 2 exprs; 0 extra) | +----+-------------+-------+...+----------+----------------------------------------------------------------------------+

Extra 列の情報は、各行から 5 つの列が抽出され、クエリ条件を評価し結果セットを構成することを示しています。1 つの WHERE 述語にはフィルター、つまり WHERE 句で直接テストされた列が含まれます。2 つの WHERE 句では、この場合は関数呼び出しを含む、より複雑な式を評価する必要があります。0 extra フィールドは、WHERE 句のすべての操作が並列クエリ処理の一部としてストレージレイヤーにプッシュダウンされることを確認します。

並列クエリが選択されていない場合は、通常、EXPLAIN 出力の他の列から理由を推測できます。たとえば、rows 値が小さすぎたり、possible_keys 列が、データ集約型スキャンではなくインデックスルックアップを使用できることを示します。次の例は、オプティマイズがクエリでスキャンする行の数が少ないとみなすクエリを示しています。これは、主キーの文字数に基づいて判断されます。この場合、並列クエリは不要です。

mysql> explain select count(*) from part where p_partkey between 1 and 100; +----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+ | 1 | SIMPLE | part | range | PRIMARY | PRIMARY | 4 | NULL | 99 | Using where; Using index | +----+-------------+-------+-------+---------------+---------+---------+------+------+--------------------------+

並列クエリを使用するかどうかを示す出力には、EXPLAIN ステートメントが実行された時点で利用可能なすべての要素が考慮されます。その間に状況が変わった場合、オプティマイザはクエリが実際に実行されたときに別の選択肢を作る場合もあります。たとえば、EXPLAIN は、ステートメントが並列クエリを使用すると報告する場合があります。しかし、クエリが実際に後で実行される場合は、条件に基づいて並列クエリを使用しないことがあります。このような条件には、同時に実行されている他の複数の並列クエリが含まれます。また、テーブルから削除される行、作成される新しいインデックス、実行中のトランザクションに時間がかかりすぎていることなども含まれます。

WHERE 句

クエリが並列クエリの最適化を使用するには、WHERE 句を含める必要があります

並列クエリの最適化は、WHERE 句で使用される多くの種類の式を高速化します。

  • 列の値と定数の簡単な比較は、フィルターとして知られています。これらの比較は、ストレージレイヤーへのプッシュダウンを最大限に活用します。クエリのフィルター式の数は、EXPLAIN 出力でレポートされます。

  • WHERE 句にある他の種類の式も、可能であれば、ストレージレイヤーにプッシュダウンされます。クエリ内のそのような式の数は、EXPLAIN 出力でレポートされます。これらの式は、関数呼び出し、LIKE 演算子、CASE 式などです。

  • 特定の関数と演算子は、現在、並列クエリによってプッシュダウンされていません。クエリ内のそのような式の数は、EXPLAIN 出力の extra カウンターとしてレポートされます。残りのクエリは引き続き並列クエリを使用できます。

  • 選択リスト内の式はプッシュダウンされませんが、そのような関数を含むクエリは、並列クエリの中間結果のネットワークトラフィックが減少しても有益です。たとえば、選択リスト内の集計関数を呼び出すクエリでは、集計関数がプッシュダウンされていなくても、並列クエリを使用できます。

たとえば、次のクエリはテーブル全体のスキャンを実行し、P_BRAND 列のすべての値を処理します。ただし、クエリには WHERE 句が含まれていないため、並列クエリは使用されません。

mysql> explain select count(*), p_brand from part group by p_brand; +----+-------------+-------+------+---------------+------+---------+------+----------+---------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+------+---------------+------+---------+------+----------+---------------------------------+ | 1 | SIMPLE | part | ALL | NULL | NULL | NULL | NULL | 20427936 | Using temporary; Using filesort | +----+-------------+-------+------+---------------+------+---------+------+----------+---------------------------------+

対照的に、次のクエリには、結果をフィルタリングする WHERE 述語が含まれているため、並列クエリを適用できます。

mysql> explain select count(*), p_brand from part where p_name is not null -> and p_mfgr in ('Manufacturer#1', 'Manufacturer#3') and p_retailprice > 1000 -> group by p_brand; +----+...+----------+-------------------------------------------------------------------------------------------------------------+ | id |...| rows | Extra | +----+...+----------+-------------------------------------------------------------------------------------------------------------+ | 1 |...| 20427936 | Using where; Using temporary; Using filesort; Using parallel query (5 columns, 1 filters, 2 exprs; 0 extra) | +----+...+----------+-------------------------------------------------------------------------------------------------------------+

オプティマイザが、クエリブロックの戻される行数が少ないと見積もった場合、そのクエリブロックに対して並列クエリは使用されません。次の例は、プライマリキー列のより大きい演算子が数百万行にも適用され、並列クエリが使用される場合を示しています。その反対に数の少ないテストでは、ほんの数行にしか適用されず、並列クエリは使用されません。

mysql> explain select count(*) from part where p_partkey > 10; +----+...+----------+----------------------------------------------------------------------------+ | id |...| rows | Extra | +----+...+----------+----------------------------------------------------------------------------+ | 1 |...| 20427936 | Using where; Using parallel query (1 columns, 1 filters, 0 exprs; 0 extra) | +----+...+----------+----------------------------------------------------------------------------+ mysql> explain select count(*) from part where p_partkey < 10; +----+...+------+--------------------------+ | id |...| rows | Extra | +----+...+------+--------------------------+ | 1 |...| 9 | Using where; Using index | +----+...+------+--------------------------+

データ定義言語 (DDL)

並列クエリは、高速データ定義言語 (DDL) オペレーションが保留されていないテーブルでのみ使用できます。高速 DDL については、「高速 DDL を使用して Amazon Aurora でテーブルを変更する」を参照してください。

列のデータ型

TEXTBLOBJSONGEOMETRY データ型は、並列クエリではサポートされていません。これらの型の列を参照するクエリは、並列クエリを使用できません。

可変長の列 (VARCHAR および CHAR) は、最大 768 バイトの宣言された最大長までの並列クエリと互換性があります。上記より長い最大長で宣言された型の列を参照するクエリは、並列クエリを使用できません。マルチバイト文字セットを使用する列の場合、バイト制限には文字セット内の最大バイト数が考慮されます。たとえば、最大文字長が 4 バイトの文字セット utf8mb4 の場合、VARCHAR(192) 列は並列クエリと互換性がありますが、VARCHAR(193) 列は互換性はありません。

パーティションテーブル

現在、並列クエリではパーティション分割されたテーブルはサポートされていません。並列クエリのクラスターでパーティション分割されたテーブルを使用できます。これらのテーブルに対するクエリは、非並列クエリ処理パスを使用します。

注記

一部のクエリブロックがパーティション分割されたテーブルを参照していても、結合クエリ、union クエリ、または他のマルチパートクエリでは部分的に並列クエリを使用できます。パーティション分割されていないテーブルのみを参照するクエリブロックは、並列クエリの最適化を使用できます。

WHERE 句での関数呼び出し

Aurora は、WHERE 句のほとんどの組み込み関数への呼び出しに並列クエリの最適化を適用できます。これらの関数呼び出しを並列化すると、いくつかの CPU 作業がヘッドノードからオフロードされます。最も早いクエリステージで述語関数を並行して評価することで、Aurora は後のステージで送信および処理されるデータ量を最小限に抑えることができます。

現在、並列化は選択リストの関数呼び出しには適用されません。これらの関数は、同じ関数呼び出しが WHERE 句に現れても、ヘッドノードによって評価されます。関連する列からの元の値は、ストレージノードからヘッドノードに送信されたタプルに含まれます。ヘッドノードは、UPPERCONCATENATE などの変換を行って、結果セットの最終的な値を生成します。

次の例では、WHERE 句にあるため、並列クエリは LOWER の呼び出しを並列化します。SUBSTRUPPER の呼び出しは選択したリストにあるため、並列クエリには影響されません。

mysql> explain select sql_no_cache distinct substr(upper(p_name),1,5) from part -> where lower(p_name) like '%cornflower%' or lower(p_name) like '%goldenrod%'; +----+...+---------------------------------------------------------------------------------------------+ | id |...| Extra | +----+...+---------------------------------------------------------------------------------------------+ | 1 |...| Using where; Using temporary; Using parallel query (2 columns, 0 filters, 1 exprs; 0 extra) | +----+...+---------------------------------------------------------------------------------------------+

CASE 式や LIKE 演算子など、他の式にも同じ考慮事項が適用されます。次の例では、並列クエリは、WHERE 句の CASE 式と LIKE演算子を評価します。

mysql> explain select p_mfgr, p_retailprice from part -> where p_retailprice > case p_mfgr -> when 'Manufacturer#1' then 1000 -> when 'Manufacturer#2' then 1200 -> else 950 -> end -> and p_name like '%vanilla%' -> group by p_retailprice; +----+...+-------------------------------------------------------------------------------------------------------------+ | id |...| Extra | +----+...+-------------------------------------------------------------------------------------------------------------+ | 1 |...| Using where; Using temporary; Using filesort; Using parallel query (4 columns, 0 filters, 2 exprs; 0 extra) | +----+...+-------------------------------------------------------------------------------------------------------------+

集計関数、GROUP BY 句、HAVING 句

集計関数を含むクエリは、大規模なテーブル内の多数の行をスキャンするため、並列クエリに適しています。選択リストまたは HAVING 句にある集計関数呼び出しは、ストレージレイヤーにプッシュダウンされません。ただし、並列クエリは、集計関数を使用してこのようなクエリのパフォーマンスを向上させることができます。これは、最初にストレージレイヤーで並列に raw データページから列値を抽出することによって行われます。次に、それらの値をデータページ全体ではなくコンパクトなタプル形式でヘッドノードに戻します。今回も、クエリには並列クエリを有効にするための少なくとも 1 つの WHERE 述語が必要です。

次の簡単な例は、並列クエリの利点を受ける集約クエリの種類を示しています。これは、中間結果をコンパクト形式でヘッドノードに戻し、一致しない行を中間結果から除外するか、またはその両方を行うことによって行います。

mysql> explain select sql_no_cache count(distinct p_brand) from part where p_mfgr = 'Manufacturer#5'; +----+...+----------------------------------------------------------------------------+ | id |...| Extra | +----+...+----------------------------------------------------------------------------+ | 1 |...| Using where; Using parallel query (2 columns, 1 filters, 0 exprs; 0 extra) | +----+...+----------------------------------------------------------------------------+ mysql> explain select sql_no_cache p_mfgr from part where p_retailprice > 1000 group by p_mfgr having count(*) > 100; +----+...+-------------------------------------------------------------------------------------------------------------+ | id |...| Extra | +----+...+-------------------------------------------------------------------------------------------------------------+ | 1 |...| Using where; Using temporary; Using filesort; Using parallel query (3 columns, 0 filters, 1 exprs; 0 extra) | +----+...+-------------------------------------------------------------------------------------------------------------+

LIMIT 句

現在のところ、LIMIT 句を含むクエリブロックでは、並列クエリは使用されません。GROUP by、ORDER BY、または結合を使用して、以前のクエリフェーズでも並列クエリを使用することができます。

比較演算子

オプティマイザは、比較演算子を評価するためにスキャンする行数を推定し、その推定値に基づいて並列クエリを使用するかどうかを決定します。

次の最初の例は、プライマリキー列との等価比較を並列クエリなしで効率的に実行できることを示しています。次の 2 番目の例では、インデックス作成されていない列に対する同様の比較では数百万行のスキャンが必要なため、パラレルクエリのメリットが得られます。

mysql> explain select * from part where p_partkey = 10; +----+...+------+-------+ | id |...| rows | Extra | +----+...+------+-------+ | 1 |...| 1 | NULL | +----+...+------+-------+ mysql> explain select * from part where p_type = 'LARGE BRUSHED BRASS'; +----+...+----------+----------------------------------------------------------------------------+ | id |...| rows | Extra | +----+...+----------+----------------------------------------------------------------------------+ | 1 |...| 20427936 | Using where; Using parallel query (9 columns, 1 filters, 0 exprs; 0 extra) | +----+...+----------+----------------------------------------------------------------------------+

等しくないテストや、より小さい、より大きい、等しい、または BETWEEN などの範囲比較にも同じ考慮事項が適用されます。オプティマイザは、スキャンする行数を推定し、I/O 全体の量に基づいて並列クエリが有効かどうかを判断します。

結合

大きなテーブルを使用した結合クエリには、通常、並列クエリの最適化のメリットを受けるデータ集約型操作が含まれます。現在、複数のテーブル (つまり、結合述語自体) 間の列値の比較は並列化されません。ただし、並列クエリは、ハッシュ結合中に Bloom フィルターを構築するなど、他の結合フェーズの内部処理の一部をプッシュダウンできます。並列クエリは、WHERE 句がなくても結合クエリに適用できます。したがって、結合クエリは、並列クエリを使用するために WHERE 句が必要であるという規則に対する例外です。

結合処理の各フェーズが評価され、並列クエリに適格であるかどうかがチェックされます。複数のフェーズで並列クエリを使用できる場合は、これらのフェーズが順番に実行されます。したがって、各結合クエリは、同時実行制限に関して単一の並列クエリセッションとしてカウントされます。

たとえば、結合クエリが結合テーブルの 1 つから行をフィルタリングする WHERE 述語を含む場合、そのフィルタリングオプションは並列クエリを使用できます。別の例として、結合クエリがハッシュ結合メカニズムを使用するとします。たとえば、大きなテーブルを小さなテーブルに結合する場合などです。この場合、Bloom フィルターデータ構造を生成するためのテーブルスキャンは、並列クエリを使用することができます。

注記

並列クエリは通常、ハッシュ結合の最適化による利点がある、大量のリソースを使用する種類のクエリに使用されます。Aurora MySQL 1.23 より前のバージョンでは、並列クエリが有効なクラスターで常にハッシュ結合を使用できます。Aurora MySQL 1.23 以上および 2.09 以上では、並列クエリとハッシュ結合の設定はどちらもデフォルトで無効になっています。このようなクラスターで並列クエリを有効にする場合は、ハッシュ結合も有効にします。ハッシュ結合を有効にして効果的に使用する方法については、「Aurora MySQL でのハッシュ結合の使用」を参照してください。

mysql> explain select count(*) from orders join customer where o_custkey = c_custkey; +----+...+----------+-------+---------------+-------------+...+-----------+-----------------------------------------------------------------------------------------------------------------+ | id |...| table | type | possible_keys | key |...| rows | Extra | +----+...+----------+-------+---------------+-------------+...+-----------+-----------------------------------------------------------------------------------------------------------------+ | 1 |...| customer | index | PRIMARY | c_nationkey |...| 15051972 | Using index | | 1 |...| orders | ALL | o_custkey | NULL |...| 154545408 | Using join buffer (Hash Join Outer table orders); Using parallel query (1 columns, 0 filters, 1 exprs; 0 extra) | +----+...+----------+-------+---------------+-------------+...+-----------+-----------------------------------------------------------------------------------------------------------------+

ネストされたループメカニズムを使用する結合クエリの場合、最も外側のネストされたループブロックは並列クエリを使用する場合があります。並列クエリの使用は、WHERE 句に追加のフィルター条件が存在するなど、通常と同じ要素に依存します。

mysql> -- Nested loop join with extra filter conditions can use parallel query. mysql> explain select count(*) from part, partsupp where p_partkey != ps_partkey and p_name is not null and ps_availqty > 0; +----+-------------+----------+...+----------+----------------------------------------------------------------------------+ | id | select_type | table |...| rows | Extra | +----+-------------+----------+...+----------+----------------------------------------------------------------------------+ | 1 | SIMPLE | part |...| 20427936 | Using where; Using parallel query (2 columns, 1 filters, 0 exprs; 0 extra) | | 1 | SIMPLE | partsupp |...| 78164450 | Using where; Using join buffer (Block Nested Loop) | +----+-------------+----------+...+----------+----------------------------------------------------------------------------+

サブクエリ

外部クエリブロックと内部サブクエリブロックでは、そのそれぞれで並列クエリを使用するかどうかが決定されます。各ブロックで使用するかどうかは、テーブルの通常の特徴や WHERE 句などに基づきます。たとえば、次のクエリでは、外部ブロックではなくサブクエリブロックに対して並列クエリが使用されます。

mysql> explain select count(*) from part where --> p_partkey < (select max(p_partkey) from part where p_name like '%vanilla%'); +----+-------------+...+----------+----------------------------------------------------------------------------+ | id | select_type |...| rows | Extra | +----+-------------+...+----------+----------------------------------------------------------------------------+ | 1 | PRIMARY |...| NULL | Impossible WHERE noticed after reading const tables | | 2 | SUBQUERY |...| 20427936 | Using where; Using parallel query (2 columns, 0 filters, 1 exprs; 0 extra) | +----+-------------+...+----------+----------------------------------------------------------------------------+

現在、相関サブクエリは並列クエリ最適化を使用できません。

UNION

UNION クエリの各クエリブロックは、UNION の各部分に対して、テーブルの通常の特性、または WHERE 句などに基づいて並列クエリを使用するかどうかを指定できます。

mysql> explain select p_partkey from part where p_name like '%choco_ate%' -> union select p_partkey from part where p_name like '%vanil_a%'; +----+----------------+...+----------+----------------------------------------------------------------------------+ | id | select_type |...| rows | Extra | +----+----------------+...+----------+----------------------------------------------------------------------------+ | 1 | PRIMARY |...| 20427936 | Using where; Using parallel query (2 columns, 0 filters, 1 exprs; 0 extra) | | 2 | UNION |...| 20427936 | Using where; Using parallel query (2 columns, 0 filters, 1 exprs; 0 extra) | | NULL | UNION RESULT | <union1,2> |...| NULL | Using temporary | +----+--------------+...+----------+----------------------------------------------------------------------------+
注記

クエリ内の各 UNION 句は順番に実行されます。クエリにすべてが並列クエリを使用する複数のステージが含まれていても、常に 1 つの並列クエリしか実行されません。したがって、複雑な複数ステージのクエリであっても、同時並行クエリの制限として 1 つだけカウントされます。

ビュー

オプティマイザは、基になるテーブルを使用して、より長いクエリとしてビューを使用するクエリをすべて書き換えます。したがって、並列クエリは、テーブル参照がビューでも実テーブルであっても同じように機能します。クエリに対して並列クエリを使用するかどうか、およびプッシュダウンする部分については、最終的に書き直されたクエリに同じ考慮事項が適用されます。

例えば、次のクエリプランは、通常は並列クエリを使用しないビューの定義を示しています。追加の WHERE 句でビューがクエリされると、Aurora MySQL は並列クエリを使用します。

mysql> create view part_view as select * from part; mysql> explain select count(*) from part_view where p_partkey is not null; +----+...+----------+----------------------------------------------------------------------------+ | id |...| rows | Extra | +----+...+----------+----------------------------------------------------------------------------+ | 1 |...| 20427936 | Using where; Using parallel query (1 columns, 0 filters, 0 exprs; 1 extra) | +----+...+----------+----------------------------------------------------------------------------+

データ操作言語 (DML) ステートメント

SELECT 部分が並列クエリの他の条件を満たしている場合、INSERT ステートメントは処理の SELECT フェーズに対して並列クエリを使用できます。

mysql> explain insert into part_subset select * from part where p_mfgr = 'Manufacturer#1'; +----+...+----------+----------------------------------------------------------------------------+ | id |...| rows | Extra | +----+...+----------+----------------------------------------------------------------------------+ | 1 |...| 20427936 | Using where; Using parallel query (9 columns, 1 filters, 0 exprs; 0 extra) | +----+...+----------+----------------------------------------------------------------------------+
注記

通常、INSERT ステートメントの後に、新しく挿入された行のデータがバッファプールにあります。したがって、多数の行を挿入した直後に、テーブルが並列クエリに適格でない可能性があります。後で、通常の操作中にバッファプールからデータが除去された後に、テーブルに対するクエリが並列クエリを再び使用し始める可能性があります。

ステートメントの SELECT 部分が並列クエリに適格であっても、CREATE TABLE AS SELECT ステートメントは並列クエリを使用しません。このステートメントの DDL 側面は、並列クエリ処理と互換性がありません。対照的に、INSERT ... SELECT ステートメントでは、SELECT 部分は並列クエリを使用できます。

並列クエリは、WHERE 句のテーブルおよび述語のサイズに関係なく、DELETEステートメントまたは UPDATE ステートメントには使用されません。

mysql> explain delete from part where p_name is not null; +----+-------------+...+----------+-------------+ | id | select_type |...| rows | Extra | +----+-------------+...+----------+-------------+ | 1 | SIMPLE |...| 20427936 | Using where | +----+-------------+...+----------+-------------+

トランザクションとロック

すべての分離レベルは、Aurora プライマリインスタンスで使用できます。

Aurora のリーダー DB インスタンスでは、並列クエリは REPEATABLE READ 分離レベルで実行されるステートメントに適用されます。また、Aurora MySQL のバージョン 1.23 以上および 2.09 以上では、リーダー DB インスタンスで READ COMMITTED 分離レベルを使用することもできます。REPEATABLE READ は、Aurora のリーダー DB インスタンスのデフォルトの分離レベルです。リーダー DB インスタンスで READ COMMITTED 分離レベルを使用するには、セッションレベルで aurora_read_replica_read_committed 設定オプションを設定する必要があります。

Aurora の分離レベルの詳細については、「Aurora MySQL の分離レベル」を参照してください。

大きなトランザクションが終了した後、テーブルの統計情報は古くなっている可能性があります。このような古くなった統計では、Aurora が正確に行数を見積もるには、ANALYZE TABLE ステートメントが必要になることがあります。大規模な DML ステートメントでは、テーブルデータのかなりの部分がバッファプールに持ち込まれる可能性があります。このデータをバッファプールに入れると、データがプールから削除されるまで、並列クエリの選択頻度が低くなります。

セッションが長時間実行トランザクション (デフォルトでは 10 分) 内にある場合、そのセッション内の以降のクエリは並列クエリを使用しません。1 つの長期実行クエリ中にもタイムアウトが発生する可能性があります。このタイプのタイムアウトは、並列クエリ処理が開始されるまでの最大間隔 (現在は 10 分) より長くクエリが実行された場合に発生する可能性があります。

mysql セッションに autocommit=1 を設定して、偶発的に長時間実行トランザクションが開始される機会を減らすことができます。テーブルに対する SELECT ステートメントでさえ、読み込みビューを作成してトランザクションを開始します。読み込みビューは、トランザクションがコミットされるまで続くクエリ用の一貫したデータセットです。このようなアプリケーションは autocommit 設定をオフにして実行する可能性があるため、Aurora で JDBC または ODBC アプリケーションを使用する場合にもこの制限に注意してください。

次の例は、autocommit 設定をオフにして、テーブルに対してクエリを実行すると、暗黙的にトランザクションを開始する読み込みビューが作成される方法を示しています。すぐ後で実行されるクエリは引き続き並列クエリを使用できます。ただし、数分の休止後は、クエリはもはや並列クエリの対象となりません。COMMIT または ROLLBACK を使用してトランザクションを終了すると、並列クエリの適格性が復元されます。

mysql> set autocommit=0; mysql> explain select sql_no_cache count(*) from part_txn where p_retailprice > 10.0; +----+...+---------+----------------------------------------------------------------------------+ | id |...| rows | Extra | +----+...+---------+----------------------------------------------------------------------------+ | 1 |...| 2976129 | Using where; Using parallel query (1 columns, 1 filters, 0 exprs; 0 extra) | +----+...+---------+----------------------------------------------------------------------------+ mysql> select sleep(720); explain select sql_no_cache count(*) from part_txn where p_retailprice > 10.0; +------------+ | sleep(720) | +------------+ | 0 | +------------+ 1 row in set (12 min 0.00 sec) +----+...+---------+-------------+ | id |...| rows | Extra | +----+...+---------+-------------+ | 1 |...| 2976129 | Using where | +----+...+---------+-------------+ mysql> commit; mysql> explain select sql_no_cache count(*) from part_txn where p_retailprice > 10.0; +----+...+---------+----------------------------------------------------------------------------+ | id |...| rows | Extra | +----+...+---------+----------------------------------------------------------------------------+ | 1 |...| 2976129 | Using where; Using parallel query (1 columns, 1 filters, 0 exprs; 0 extra) | +----+...+---------+----------------------------------------------------------------------------+

クエリが長時間実行トランザクションのために並列クエリに適格でなかった回数を確認するには、ステータス変数 Aurora_pq_not_chosen_long_trx を確認します。

mysql> show global status like '%pq%trx%'; +-------------------------------+-------+ | Variable_name | Value | +-------------------------------+-------+ | Aurora_pq_not_chosen_long_trx | 4 | +-------------------------------+-------+

SELECT FOR UPDATE 構文や SELECT LOCK IN SHARE MODE 構文などのロックを取得するすべての SELECT ステートメントでは、並列クエリを使用できません。

並列クエリは、LOCK TABLES ステートメントによってロックされているテーブルに対して機能します。

mysql> explain select o_orderpriority, o_shippriority from orders where o_clerk = 'Clerk#000095055'; +----+...+-----------+----------------------------------------------------------------------------+ | id |...| rows | Extra | +----+...+-----------+----------------------------------------------------------------------------+ | 1 |...| 154545408 | Using where; Using parallel query (3 columns, 1 filters, 0 exprs; 0 extra) | +----+...+-----------+----------------------------------------------------------------------------+ mysql> explain select o_orderpriority, o_shippriority from orders where o_clerk = 'Clerk#000095055' for update; +----+...+-----------+-------------+ | id |...| rows | Extra | +----+...+-----------+-------------+ | 1 |...| 154545408 | Using where | +----+...+-----------+-------------+

B ツリーインデックス

ANALYZE TABLE ステートメントによって収集される統計は、各列のデータの特性に基づいて、並列クエリまたはインデックスのルックアップをいつ使用するかをオプティマイザが決定するのに役立ちます。テーブル内のデータを大幅に変更する DML 操作の後で ANALYZE TABLE を実行することにより、統計情報を最新の状態に保ちます。

インデックスのルックアップがデータ集約型スキャンなしで効率的にクエリを実行できる場合は、Aurora は インデックスのルックアップを使用する可能性があります。そうすることにより、並列クエリ処理のオーバーヘッドが回避されます。また、どの Aurora DB クラスターでも同時に実行できる並列クエリの数には同時実行制限があります。テーブルのインデックス付けにベストプラクティスを使用して、最も頻繁で最も並行性の高いクエリがインデックスのルックアップを使用するようにしてください。

全文検索 (FTS) インデックス

現在のところ、全文検索インデックスを含むテーブルでは、クエリで全文検索インデックスのある列を参照しているか MATCH 演算子を使用しているかどうかにかかわらず、並列クエリは使用されません。

全文検索 (FTS) インデックス

現在のところ、仮想列を含むテーブルでは、クエリで仮想列を参照しているかどうかにかかわらず、並列クエリは使用されません。

組み込みキャッシュメカニズム

Aurora には、組み込みキャッシュメカニズム、つまりバッファプールとクエリキャッシュが組み込まれています。Aurora オプティマイザは、どのクエリが特定のクエリに対して最も効果的かに応じて、これらのキャッシュメカニズムと並列クエリを選択します。

並列クエリが行をフィルタリングし、列の値を変換して抽出すると、データはデータページではなくタプルとしてヘッドノードに返されます。したがって、並列クエリを実行しても、バッファプールにはページが追加されず、すでにバッファプールにあるページは削除されます。

Aurora は、バッファプール内に存在するテーブルデータのページ数と、その番号が表すテーブルデータの部分を検査します。Aurora はその情報を使用して、並列クエリを使用する方が効率的かどうかを判断します (また、バッファプール内のデータをバイパスします)。または、Aurora はバッファプールにキャッシュされたデータを使用する非並列クエリ処理パスを使用することがあります。キャッシュされるページと、データ集約型のクエリがキャッシュおよび削除に与える影響は、バッファプールに関連する構成設定によって異なります。したがって、バッファプール内の常に変化するデータに依存するため、特定のクエリで並列クエリが使用されているかどうかを予測することは困難です。

また、Aurora は並列クエリに同時実行制限を課します。すべてのクエリが並列クエリを使用するわけではないので、複数のクエリによって同時にアクセスされるテーブルは、通常、バッファプール内のデータのかなりの部分を占めます。したがって、Aurora は並列クエリに対してこれらのテーブルを選択しないことがよくあります。

同じテーブルで非並列クエリのシーケンスを実行すると、データがバッファプールにないため、最初のクエリが遅くなる可能性があります。これでバッファプールが「ウォームアップ」状態になるため、2 番目以降のクエリは非常に高速になります。並列クエリは、通常、テーブルに対する最初のクエリからの一貫したパフォーマンスを示します。パフォーマンステストを実行するときは、コールドバッファプールとウォームバッファプールの両方を使用して、非並列クエリを評価します。場合によっては、ウォームバッファプールを使用した結果は、並列クエリ時間とよく比較できます。その場合、そのテーブルに対するクエリの頻度などの要因を考慮してください。また、そのテーブルのデータをバッファプールに保持するメリットがあるかどうかも考慮してください。

クエリキャッシュは、同じクエリが送信されたときに基になるテーブルのデータに変更がない場合に、クエリがもう一度実行されることを防ぎます。並列クエリ機能によって最適化されたクエリは、クエリキャッシュに入り、効果的に再度実行することができます。

注記

パフォーマンスの比較を行うとき、クエリキャッシュは意図的に低いタイミング数を生成する可能性があります。したがって、ベンチマークのような状況では、sql_no_cache ヒントを使用できます。このヒントは、以前に同じクエリが実行された場合でも、クエリキャッシュから結果が提供されるのを防ぎます。ヒントは、クエリの SELECT ステートメントの直後に表示されます。このトピックの多くの並列クエリの例には、このヒントが含まれており、並列クエリで有効化されているクエリとそうでないクエリのバージョン間でクエリ時間を比較できます。

並列クエリの本稼働使用に移行するときは、ソースからこのヒントを削除するようにしてください。

MyISAM 一時テーブル

並列クエリの最適化は、InnoDB テーブルにのみ適用されます。Aurora MySQL は一時テーブルの背後で MyISAM を使用するため、一時テーブルを含む内部クエリフェーズでは並列クエリは使用されません。これらのクエリフェーズは、EXPLAIN 出力に Using temporary によって示されています。