# Amazon Aurora MySQL の並列クエリ
このトピックでは、Amazon Aurora MySQL 互換エディションのパラレルクエリの最適化機能について説明しています。この機能は、特定のデータ集約型クエリに対して特別な処理パスを使用し、Aurora 共有ストレージアーキテクチャを利用します。パラレルクエリは、数百万行のテーブルと完了までに数分または数時間かかる分析クエリを持つテーブルを持つ Aurora MySQL DB クラスターで最も効果的です。
**Topics**
+ [Aurora MySQL の並列クエリの概要](#aurora-mysql-parallel-query-overview)
+ [Aurora MySQL での並列クエリ DB クラスターの作成](aurora-mysql-parallel-query-creating-cluster.md)
+ [Aurora MySQL での並列クエリのオン/オフの切り替え](aurora-mysql-parallel-query-enabling.md)
+ [Aurora MySQL での並列クエリの最適化](aurora-mysql-parallel-query-optimizing.md)
+ [Aurora MySQL の並列クエリを使用しているステートメントの確認](aurora-mysql-parallel-query-verifying.md)
+ [Aurora MySQL の並列クエリのモニタリング](aurora-mysql-parallel-query-monitoring.md)
+ [Aurora MySQL の並列クエリ用の SQL コンストラクト](aurora-mysql-parallel-query-sql.md)
## Aurora MySQL の並列クエリの概要
Aurora MySQL パラレルクエリは、データ集約的なクエリの処理に関連する I/O と計算の一部をパラレル処理する最適化です。パラレル処理される作業には、ストレージから行を取得し、列の値を抽出して、`WHERE` 句と結合句の条件に一致する行を判別することが含まれます。このデータ集約型の作業は、Aurora 分散ストレージレイヤー内の複数のノードに委譲されます (データベース最適化の用語では、*プッシュダウン*されます)。並行クエリがないと、各クエリはすべてのスキャンされたデータを Aurora MySQL クラスター (ヘッドノード) 内の単一のノードに持ち込み、そこですべてのクエリ処理を実行します。
**ヒント**
PostgreSQL データベースエンジンにも「パラレルクエリ」と呼ばれる機能があります。この機能は、Aurora のパラレルクエリとは異なります。
パラレルクエリ特徴を有効にすると、ヒントやテーブル属性などの SQL の変更を必要とせずに、Aurora MySQL エンジンはクエリがいつ利点を得られるかを自動的に判断します。以降のセクションで、パラレルクエリがいつクエリに適用されるかについて説明します。パラレルクエリが最も効果的な場所に適用されていることを確認する方法についても説明します。
**注記**
パラレルクエリの最適化は、完了までに数分や数時間といった長い時間がかかるクエリの場合に最もメリットがあります。Aurora MySQL は、一般的に安価なクエリのためにはパラレルクエリの最適化を実行しません。また、クエリのキャッシュ、バッファプールのキャッシュ、インデックスの検索などの別の最適化手法を使用したほうが効果的な場合も、通常はパラレルクエリの最適化を行いません。パラレルクエリが適切に使用されていない場合は、「[Aurora MySQL の並列クエリを使用しているステートメントの確認](aurora-mysql-parallel-query-verifying.md)」を参照してください。
**Topics**
+ [利点](#aurora-mysql-parallel-query-benefits)
+ [アーキテクチャ](#aurora-mysql-parallel-query-architecture)
+ [前提条件](#aurora-mysql-parallel-query-prereqs)
+ [制限](#aurora-mysql-parallel-query-limitations)
+ [並列クエリの I/O コスト](#aurora-mysql-parallel-query-cost)
### 利点
パラレルクエリを使用すると、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 インスタンスの数に依存しません。
### 前提条件
パラレルクエリのすべての機能を使用するには、バージョン 2.09 以上を実行している Aurora MySQL DB クラスターが必要です。パラレルクエリを使用したいクラスターが既にある場合は、互換性のあるバージョンにアップグレードしてからパラレルクエリを有効にすることができます。その場合、これらの新しいバージョンでは設定名とデフォルト値が異なるため、「[パラレルクエリのアップグレードに関する考慮事項](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade)」のアップグレード手順に従ってください。
クラスターの DB インスタンスでは、`db.r*` インスタンスクラスを使用する必要があります。
クラスターでは、ハッシュ結合の最適化を必ず有効にしてください。この方法については、「[パラレルクエリクラスターのハッシュ結合の有効化](aurora-mysql-parallel-query-enabling.md#aurora-mysql-parallel-query-enabling-hash-join)」を参照してください。
`aurora_parallel_query` や `aurora_disable_hash_join` などのパラメータをカスタマイズするには、クラスターで使用するカスタムパラメータグループが必要です。これらのパラメータは、DB パラメータグループを使用して DB インスタンスごとに個別に指定することもできます。ただし、DB クラスターパラメータグループで指定することをお勧めします。これにより、クラスターのすべての DB インスタンスでこれらのパラメータの同じ設定が継承されます。
### 制限
パラレルクエリ機能には、次の制限が適用されます。
+ 並列クエリは Aurora I/O-Optimized DB クラスターのストレージ設定ではサポートされていません。
+ db.t2 または db.t3 インスタンスクラスでは、パラレルクエリは使用できません。この制限は、`aurora_pq_force` セッション変数を使用してパラレルクエリを行う場合にも適用されます。
+ パラレルクエリは、`COMPRESSED` または `REDUNDANT` の行形式を使用するテーブルには適用されません。パラレルクエリを使用するテーブルには、`COMPACT` または `DYNAMIC` の行形式を使用してください。
+ Aurora では、コストに基づくアルゴリズムを使用して、それぞれの SQL ステートメントにパラレルクエリを使用するかどうかを判断します。ステートメントで特定の SQL コンストラクトを使用すると、パラレルクエリを防止したり、そのステートメントでパラレルクエリが行われる可能性を低くしたりすることができます。SQL コンストラクトとパラレルクエリの互換性については、「[Aurora MySQL の並列クエリ用の SQL コンストラクト](aurora-mysql-parallel-query-sql.md)」を参照してください。
+ 各 Aurora DB インスタンスは、一度に特定の数のパラレルクエリセッションのみを実行できます。クエリにサブクエリ、結合、または `UNION` 演算子などのパラレルクエリを使用する複数の部分がある場合、それらのフェーズは順番に実行されます。このステートメントは、一度に 1 つのパラレルクエリセッションとしてカウントされます。[パラレルクエリステータス可変](aurora-mysql-parallel-query-monitoring.md)を使用して、アクティブなセッションの数をモニタリングできます。ステータス可変 `Aurora_pq_max_concurrent_requests` を照会することで、特定の DB インスタンスの同時セッションの制限を確認できます。
+ パラレルクエリは、Aurora がサポートしているすべての AWS リージョンで利用できます。ほとんどの AWS リージョンの場合、パラレルクエリを使用するために必要な Aurora MySQL の最小バージョンは 2.09 です。
+ パラレルクエリは、データ集約型クエリのパフォーマンスを向上させるように設計されています。軽量のクエリ用向けには設計されていません。
+ SELECT ステートメント、特にデータ量の多いステートメントにはリーダーノードを使用することをお勧めします。
### 並列クエリの I/O コスト
Aurora MySQL クラスターがパラレルクエリを使用している場合、`VolumeReadIOPS` 値が増加することがあります。パラレルクエリでは、バッファプールは使用されません。したがって、クエリは高速ですが、この最適化された処理により、読み取り操作とそれに関連する料金が増加する可能性があります。
クエリのパラレルクエリ I/O コストは、ストレージレイヤーで計測され、パラレルクエリがオンになっている場合と同じかそれ以上になります。利点は、クエリのパフォーマンスが向上することです。パラレルクエリで I/O コストが高くなる可能性がある理由は 2 つあります。
+ テーブル内のデータの一部がバッファプールにある場合でも、パラレルクエリでは、すべてのデータをストレージレイヤーでスキャンする必要があり、I/O コストが発生します。
+ パラレルクエリを実行しても、バッファプールはウォームアップされません。その結果、同じパラレルクエリを連続して実行すると、完全な I/O コストが発生します。