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

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

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

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

クエリでパラレルクエリが使用されているかどうかを確認するには、EXPLAIN ステートメントを実行してクエリプラン (explain プラン) を確認します。パラレルクエリの EXPLAIN 出力に SQL ステートメント、句および表現がどのように影響するかの例は、「Aurora MySQL の並列クエリ用の 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) |
+----+-------------+----------+------------+------+---------------+------+---------+------+----------+----------+----------------------------------------------------+

Aurora MySQL バージョン 3 の場合、次のステートメントを発行すると、セッションレベルでハッシュ結合を有効にできます。

SET optimizer_switch='block_nested_loop=on';

Aurora MySQL バージョン 2.09 以降では、aurora_disable_hash_join DB パラメーターまたは DB クラスターパラメータを 0 (オフ) に設定します。aurora_disable_hash_join をオフにすると、optimizer_switch の値が hash_join=on に設定されます。

ハッシュ結合を有効にした後、EXPLAIN ステートメントをもう一度実行してみてください。ハッシュ結合を効果的に使用する方法については、ハッシュ結合を使用した大規模な 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 出力を解釈する方法については、「Aurora MySQL の並列クエリ用の 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 ステートメントがパラレルクエリを利用できるかどうかを理解してください。次に、以下のモニタリング方法を使用して、実際のワークロードでパラレルクエリが使用される頻度を時間をかけて確認します。実際のワークロードでは、同時実行制限などの追加の要素が適用されます。