翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Redshift でのクエリのパフォーマンス要因
いくつかの要因がクエリパフォーマンスに影響を与える可能性があります。データ、クラスター、データベース操作の次の側面はすべて、クエリ処理の速度に影響を与えます。
+ [テーブルプロパティ](#table-properties)
+ [ソートキー](#table-sort-keys) (Amazon Redshift Advisor)
+ [データ圧縮](#data-compression) (自動)
+ [データのディストリビューション](#data-distribution) (自動)
+ [テーブルのメンテナンス](#table-maintenance) (自動)
+ [クラスターの設定](#cluster-configuration)
+ [ノードタイプ](#node-type)
+ [ノードサイズ、ノード数、スライス数](#node-size)
+ [ワークロード管理](#workload-management) (自動)
+ [ショートクエリアクセラレーション](#sqa) (自動)
+ [SQL クエリ](#query)
+ [クエリ構造](#query-structure)
+ [コードコンパイル](#code-compilation)
## テーブルプロパティ
Amazon Redshift テーブルは、Amazon Redshift にデータを保存するための基本的な単位であり、各テーブルには、その動作とアクセシビリティを決定する一連のプロパティがあります。これらのプロパティには、ソート、分散スタイル、圧縮エンコーディングなどが含まれます。これらのプロパティを理解することは、Amazon Redshift テーブルのパフォーマンス、セキュリティ、コスト効率を最適化するために不可欠です。
### ソートキー
Amazon Redshift は、テーブルのソートキーに応じたソート順で、データをディスクに保存します。クエリオプティマイザとクエリプロセッサは、コンピューティングノード内のデータの保存場所に関する情報を使用して、スキャンする必要があるブロックの数を減らします。これにより、処理するデータの量が減り、クエリ速度が大幅に向上します。ソートキーを使用して、`WHERE` 句のフィルターを容易にすることをお勧めします。詳細については、Amazon Redshift のドキュメントの「[ソートキーの使用](https://docs.aws.amazon.com/redshift/latest/dg/t_Sorting_data.html)」を参照してください。
### データ圧縮
データ圧縮により必要なストレージが減るので、ディスク I/O が減少し、クエリのパフォーマンスが向上します。クエリを実行すると、圧縮されたデータがメモリに読み込まれ、クエリの実行時に圧縮解除されます。メモリにロードするデータを少なくできるので、Amazon Redshift は、より多くのメモリをデータ分析のために割り当てられるようになります。列指向ストレージでシーケンシャルに格納される類似のデータに対して、Amazon Redshift では、列指向のデータ型と明示的に結び付けられた適応型圧縮エンコーディングを利用できます。テーブルの列でデータの圧縮を有効にする最良の方法は、テーブルにデータをロードする際に、Amazon Redshift の `AUTO` オプションを使用して、最適な圧縮エンコーディングが適用されるようにすることです。自動データ圧縮の使用の詳細については、Amazon Redshift ドキュメントの「[自動圧縮ありでテーブルをロードする](https://docs.aws.amazon.com/redshift/latest/dg/c_Loading_tables_auto_compress.html)」を参照してください。
### データのディストリビューション
Amazon Redshift は、テーブルの分散スタイルに応じて、データをコンピューティングノードに保存します。クエリを実行すると、クエリオプティマイザが結合と集計を実行するための必要に応じて、データをコンピューティングノードに再分散します。テーブルに適した分散スタイルを選択すると、結合を実行する前にデータを必要な場所に配置しておくことによって、再分散ステップの影響を最小限に抑えることができます。最も一般的な結合を容易にするために、分散キーを使用することをお勧めします。詳細については、Amazon Redshift のドキュメントの「[データディストリビューションスタイルの操作](https://docs.aws.amazon.com/redshift/latest/dg/t_Distributing_data.html)」を参照してください。
### テーブルのメンテナンス
Amazon Redshift はほとんどのワークロードで業界標準のパフォーマンスを提供しますが、Amazon Redshift クラスターを正常に実行し続けるにはメンテナンスが必要です。データを更新および削除すると、バキューム処理が必要なデッド行が作成され、追加順序がソートキーと一致しない場合は、追加専用テーブルも再ソートする必要があります。
#### Vacuum
Amazon Redshift でのバキューム処理プロセスは、Amazon Redshift クラスターのヘルスとメンテナンスに不可欠です。また、クエリのパフォーマンスにも影響します。削除や更新によって古いデータにフラグが付きますが、実際に削除されたわけではないため、バキューム処理を使用して、前の `UPDATE` および `DELETE` 操作で削除対象としてマークされたテーブル行によって占有されたディスク領域を再利用する必要があります。Amazon Redshift は、バックグラウンドでテーブルを自動的にソートし、`VACUUM DELETE` オペレーションを実行できます。
ロードまたは一連の増分更新の後にテーブルをクリーンアップするには、データベース全体または個々のテーブルに対して `VACUUM` コマンドを実行することもできます。テーブルにソートキーがあり、テーブルのロードが挿入時にソートするように最適化されていない場合は、バキュームを使用してデータを再ソートする必要があります (これはパフォーマンスにとって重要です)。詳細については、Amazon Redshift ドキュメントの「[Vacuuming tables](https://docs.aws.amazon.com/redshift/latest/dg/t_Reclaiming_storage_space202.html)」を参照してください。
#### 分析
`ANALYZE` 操作によって、Amazon Redshift データベース内のテーブルの統計メタデータを更新します。統計を最新状態に保つことで、クエリプランナーが最適なプランを選択できるようになるため、クエリのパフォーマンスが向上します。Amazon Redshift はデータベースを継続的にモニタリングし、バックグラウンドで自動的に分析オペレーションを実行します。システムパフォーマンスへの影響を最小限にするために、`ANALYZE` 操作はワークロードが軽い期間に自動で実行されます。`ANALYZE` を明示的に実行することを選択した場合は、以下を実行する必要があります。
+ クエリを実行する前に `ANALYZE` コマンドを実行します。
+ 定期的なロードまたは更新サイクルが終わるたびに、データベースで `ANALYZE` コマンドを定期的に実行します。
+ 作成した新しいテーブルと大幅に変更された既存のテーブルまたは列で `ANALYZE` コマンドを実行します。
+ クエリでの使用と変更傾向に基づき、異なるタイプのテーブルおよび列に対し、異なるスケジュールで `ANALYZE` 操作を実行することを考慮します。
+ 時間とクラスターリソースを節約するには、`ANALYZE` コマンドを実行するときに `PREDICATE COLUMNS` 句を使用します。
## クラスターの設定
クラスターは、データの実際の保存と処理を実行するノードのコレクションです。以下を実現するには、Amazon Redshift クラスターを正しい方法で設定してください。
+ 高いスケーラビリティと同時実行性
+ Amazon Redshift の効率的な使用
+ パフォーマンスの向上
+ コストの削減
### ノードタイプ
Amazon Redshift クラスターは、複数のノードタイプ (RA3、DC2、DS2) のいずれかを使用できます。各ノードタイプは様々なサイズを提供し、クラスターを適切に拡張することができるように制限します。ノードサイズによって、クラスター内の各ノードのストレージ容量、メモリ、CPU、および料金が決まります。コストとパフォーマンスの最適化は、適切なノードタイプとサイズを選択することから始まります。ノードタイプの詳細については、Amazon Redshift ドキュメントの「[Amazon Redshift クラスターの概要](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#working-with-clusters-overview)」を参照してください。
### ノードサイズ、ノード数、スライス数
コンピューティングノードはスライスに分割されています。ノードが多いということは、プロセッサとスライスが多いことを意味するため、クエリの各部分をスライス間で同時実行することによりプロセスをすばやく処理することが可能になります。ただし、ノード数が多いほど、コストも高くなります。つまり、システムに適したコストとパフォーマンスのバランスを見つける必要があります。Amazon Redshift クラスターアーキテクチャの詳細については、Amazon Redshift ドキュメントの「[データウェアハウスシステムのアーキテクチャ](https://docs.aws.amazon.com/redshift/latest/dg/c_high_level_system_architecture.html)」を参照してください。
### ワークロード管理
Amazon Redshift のワークロード管理 (WLM) により、ユーザーはワークロードのキューに優先順位を付けて柔軟に管理することが可能になります。これにより、実行速度が高く処理時間の短いクエリが、処理時間の長いクエリの後に滞らないようにできます。自動 WLM は、機械学習 (ML) アルゴリズムを使用してクエリをプロファイリングし、クエリの同時実行とメモリ割り当てを管理しながら、適切なリソースを使用して適切なキューに配置します。WLM の詳細については、Amazon Redshift ドキュメントの「[ワークロード管理の実装](https://docs.aws.amazon.com/redshift/latest/dg/cm-c-implementing-workload-management.html)」を参照してください。
### ショートクエリアクセラレーション
ショートクエリアクセラレーション (SQA) は、実行時間が短いクエリを、実行時間が長いクエリよりも優先します。SQA では実行時間が短いクエリを専用領域で実行します。このため SQA クエリは、実行時間が長いクエリをキューで待機するよう強制されません。SQA は、実行時間が短く、ユーザー定義のキュー内にあるクエリのみを優先します。SQA を使用すると、実行時間が短いクエリの実行開始が早くなり、ユーザーへの結果表示も早くなります。SQA を有効にすると、実行時間の短いクエリ専用の WLM キューを減らす、またはなくすことができます。さらに、長時間実行されるクエリは、WLM キュー内のスロットに対して競合する必要はありません。つまり、より少ないクエリスロットを使用するように WLM キューを設定できます。同時実行数が減るとクエリのスループットが向上し、大部分のワークロードに関するシステム全体のパフォーマンスも向上します。SQA の詳細については、Amazon Redshift ドキュメントの「[「ショートクエリアクセラレーションを使用する](https://docs.aws.amazon.com/redshift/latest/dg/wlm-short-query-acceleration.html)」を参照してください。
## SQL クエリ
データベースクエリは、データベースからのデータのリクエストです。リクエストは SQL を使用して Amazon Redshift クラスターに送信される必要があります。Amazon Redshift は、Java Database Connectivity (JDBC) および Open Database Connectivity (ODBC) を介して接続する SQL クライアントツールをサポートします。JDBC または ODBC ドライバーをサポートするほとんどの SQL クライアントツールを使用できます。
### クエリ構造
クエリの書き込み方法は、そのパフォーマンスに大きな影響を与えます。クエリを作成して処理し、ニーズに合わせて必要な最小限のデータを返すことをお勧めします。クエリの構造方法の詳細については、このガイドの「[Amazon Redshift クエリの設計のベストプラクティス](best-practices-designing-queries.md)」セクションを参照してください。
### コードコンパイル
Amazon Redshift は、クエリ実行プランごとに最適化されたコードを生成してコンパイルします。コンパイル済みコードは、インタプリタを使用してオーバーヘッドを排除するため、高速で実行されます。コンパイルされたコードのパフォーマンス上の利点を維持しながら、新しいクエリのレイテンシーを最小限に抑えるために、Amazon Redshift は*コンポジション*と呼ばれる手法を使用します。コンポジションは、既存のロジックの軽量な配置を生成して新しいクエリをすぐに処理し、同時に高度に最適化されたクエリ固有のコードをバックグラウンドでコンパイルします。これにより、クエリ実行のクリティカルパスからコンパイルが削除されます。つまり、新しいクエリはより高速に開始され、後続の実行と一貫したパフォーマンスを提供します。
また、Amazon Redshift はサーバーレスコンパイルサービスを使用して、Amazon Redshift クラスターのコンピューティングリソースを超えてクエリコンパイルをスケールします。コンパイルされたコードセグメントは、クラスター上のローカルキャッシュと、クラスターの再起動後も保持される実質的に無制限のリモートキャッシュの両方にキャッシュされます。同じクエリをそれ以降に実行すると、コンパイルフェーズをスキップできるため、高速になります。スケーラブルなコンパイルサービスを使用することで、Amazon Redshift はコードを並行してコンパイルし、一貫して高速なパフォーマンスを提供します。