

# EXPLAIN ANALYZE の DPU について
<a name="understanding-dpus-explain-analyze"></a>

Aurora DSQL は、`EXPLAIN ANALYZE VERBOSE` プラン出力に**ステートメントレベル**の分散処理ユニット (DPU) 情報を提供し、開発中のクエリコストをより詳細に可視化します。このセクションでは、DPU とは何か、`EXPLAIN ANALYZE VERBOSE` 出力でそれらを解釈する方法について説明します。

## DPU とは
<a name="what-is-dpu"></a>

分散処理ユニット (DPU) は、Aurora DSQL によって実行された作業の標準化された測定単位です。これは以下で構成されます。
+ **ComputeDPU** – SQL クエリの実行にかかった時間
+ **ReadDPU** – ストレージからデータを読み取るために使用されるリソース
+ **WriteDPU** - ストレージへのデータの書き込みに使用されるリソース
+ **MultiRegionWriteDPU** – マルチリージョン設定でピア接続されたクラスターへの書き込みをレプリケートするために使用されるリソース

## EXPLAIN ANALYZE VERBOSE での DPU の使用
<a name="dpu-usage-explain-analyze"></a>

Aurora DSQL は `EXPLAIN ANALYZE VERBOSE` を拡張して、ステートメントレベルの DPU 使用量の見積もりを出力の最後に含めます。これにより、クエリコストがすぐに可視化され、ワークロードのコスト要因の特定、クエリのパフォーマンスの調整、リソース使用量の予測に役立ちます。

次の例は、EXPLAIN ANALYZE VERBOSE 出力に含まれるステートメントレベルの DPU 見積もりを解釈する方法を示しています。

### 例 1: SELECT クエリ
<a name="select-query-example"></a>

```
EXPLAIN ANALYZE VERBOSE SELECT * FROM test_table;
```

```
QUERY PLAN
----------------------------------------------------
Index Only Scan using test_table_pkey on public.test_table  (cost=125100.05..171100.05 rows=1000000 width=36) (actual time=2.973..4.482 rows=120 loops=1)
  Output: id, context
  -> Storage Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
      Projections: id, context
      -> B-Tree Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
Query Identifier: qymgw1m77maoe
Planning Time: 11.415 ms
Execution Time: 4.528 ms
Statement DPU Estimate:
  Compute: 0.01607 DPU
  Read: 0.04312 DPU
  Write: 0.00000 DPU
  Total: 0.05919 DPU
```

この例では、SELECT ステートメントはインデックスのみのスキャンを実行するため、ほとんどのコストは、ストレージから取得されたデータを表す読み取り DPU (0.04312) と、結果を処理して返すために使用されるコンピューティングリソースを反映したコンピューティング DPU (0.01607) から発生します。クエリはデータを変更しないため、書き込み DPU はありません。合計 DPU (0.05919) は、コンピューティング \$1 読み取り \$1 書き込みの合計です。

### 例 2: INSERT クエリ
<a name="insert-query-example"></a>

```
EXPLAIN ANALYZE VERBOSE INSERT INTO test_table VALUES (1, 'name1'), (2, 'name2'), (3, 'name3');
```

```
QUERY PLAN
----------------------------------------------------
Insert on public.test_table  (cost=0.00..0.04 rows=0 width=0) (actual time=0.055..0.056 rows=0 loops=1)
  ->  Values Scan on "*VALUES*"  (cost=0.00..0.04 rows=3 width=122) (actual time=0.003..0.008 rows=3 loops=1)
        Output: "*VALUES*".column1, "*VALUES*".column2
Query Identifier: jtkjkexhjotbo
Planning Time: 0.068 ms
Execution Time: 0.543 ms
Statement DPU Estimate:
  Compute: 0.01550 DPU
  Read: 0.00307 DPU (Transaction minimum: 0.00375)
  Write: 0.01875 DPU (Transaction minimum: 0.05000)
  Total: 0.03732 DPU
```

このステートメントは主に書き込みを実行するため、ほとんどのコストは書き込み DPU に関連付けられます。Compute DPU (0.01550) は、値を処理して挿入するために行われた作業を表します。読み取り DPU (0.00307) は、マイナーシステム読み取り (カタログルックアップまたはインデックスチェックの場合) を反映します。

読み取りおよび書き込み DPU の横に表示されるトランザクションの最小値に注意してください。これらは、*オペレーションに読み取りまたは書き込みが含まれている場合にのみ*適用されるトランザクションあたりのベースラインコストを示します。すべてのトランザクションで 0.00375 読み取り DPU または 0.05 書き込み DPU 料金が自動的に発生するわけではありません。代わりに、これらの最小値は、コスト集計中に、そのトランザクション内で読み取りまたは書き込みが行われた場合にのみ、トランザクションレベルで適用されます。このスコープの違いにより、`EXPLAIN ANALYZE VERBOSE` のステートメントレベルの見積もりが、CloudWatch または請求データで報告されたトランザクションレベルのメトリクスと正確に一致しない場合があります。

## 最適化のための DPU 情報の使用
<a name="using-dpu-information-optimization"></a>

ステートメントごとの DPU 見積もりは、実行時間を超えてクエリを最適化する強力な方法を提供します。一般的ユースケースには以下が含まれます。
+ **コスト認識:** クエリが他のクエリと比較してどのくらいのコストがかかるかを把握します。
+ **スキーマの最適化:** インデックスまたはスキーマの変更がパフォーマンスとリソース効率の両方に与える影響を比較します。
+ **Budget Planning:** 観測された DPU 使用量に基づいてワークロードコストを見積もります。
+ **クエリ比較:** 代替クエリアプローチを相対的な DPU 消費量で評価します。

## DPU 情報の解釈
<a name="interpreting-dpu-information"></a>

`EXPLAIN ANALYZE VERBOSE` の DPU データを使用する場合は、次のベストプラクティスに注意してください。
+ **方向的に使用する:** 報告されたDPUを、CloudWatchメトリクスや請求データとの厳密な一致ではなく、クエリの*相対的な*コストを理解する手段として扱います。`EXPLAIN ANALYZE VERBOSE` はステートメントレベルのコストを報告し、CloudWatch はトランザクションレベルのアクティビティを集計するため、差異が良そうされます。CloudWatch には、`EXPLAIN ANALYZE VERBOSE` が意図的に除外するバックグラウンドオペレーション (ANALYZE や圧縮など) とトランザクションオーバーヘッド (`BEGIN`/`COMMIT`) も含まれています。
+ **実行間の DPU の変動は分散システムでは正常**であり、エラーを示すものではありません。キャッシュ、実行計画の変更、同時実行、データ分散のシフトなどの要因により、同じクエリが 1 回の実行から次の実行まで異なるリソースを消費する可能性があります。
+ **バッチスモールオペレーション:** ワークロードが多数のスモールステートメントを発行する場合は、それらをより大きなオペレーション (10MB を超えない) にバッチ処理することを検討してください。これにより、四捨五入オーバーヘッドが削減され、より意味のあるコスト見積もりが生成されます。
+ **請求ではなく調整に使用する:** `EXPLAIN ANALYZE VERBOSE` の DPU データは、コスト認識、クエリ調整、最適化のために設計されています。請求グレードのメトリクスではありません。信頼できるコストと使用状況データについては、常に CloudWatch メトリクスまたは毎月の請求レポートに依存します。