クエリパフォーマンスに影響を与える要因

ノード、プロセッサ、スライスの数 – コンピューティングノードはスライスに分割されています。ノードが多いということは、プロセッサとスライスが多いことを意味するため、クエリの各部分をスライス間で同時実行することによりプロエスをすばやく処理することが可能になります。ただし、ノードが多いとコストも上昇するため、システムに適したコストとパフォーマンスのバランスを見つける必要があります。Amazon Redshift クラスターアーキテクチャの詳細については、データウェアハウスシステムのアーキテクチャを参照してください。

ノードタイプ — Amazon Redshift クラスターでは、いくつかのノードタイプのうち 1 つを使用できます。各ノードタイプは様々なサイズを提供し、クラスターを適切に拡張することができるように制限します。ノードサイズによって、クラスター内の各ノードのストレージ容量、メモリ、CPU、および料金が決まります。ノードタイプの詳細については、「Amazon Redshift 管理ガイド」の「Amazon Redshift でのクラスター管理の概要」を参照してください。

データディストリビューション – Amazon Redshift は、テーブルのディストリビューションスタイルに応じて、テーブルデータをコンピューティングノードに保存します。クエリを実行すると、クエリオプティマイザが結合と集計を実行するための必要に応じて、データをコンピューティングノードに再分散します。テーブルに適した分散スタイルを選択すると、結合を実行する前にデータを必要な場所に配置しておくことによって、再分散ステップの影響を最小限に抑えることができます。詳細については、「クエリ最適化のためのデータのディストリビューション」を参照してください。

データのソート順 – Amazon Redshift は、テーブルのソートキーに応じたソート順で、テーブルデータをディスクに保存します。クエリオプティマイザとクエリプロセッサは、データの保存場所に関する情報を使用して、スキャンする必要があるブロックの数を減らすため、クエリの速度が向上します。詳細については、「ソートキー」を参照してください。

データセットサイズ – クラスター内のデータのボリュームが大きくなると、スキャンおよび再分散する必要がある行が増えるため、クエリのパフォーマンスが低下する可能性があります。データのバキューム処理とアーカイブを定期的に実行し、クエリデータセットを制限する述語を使用することによって、この影響を緩和できます。

同時オペレーション – 複数のオペレーションを一度に実行すると、クエリパフォーマンスに影響が及ぶ可能性があります。操作が実行されるたびに使用可能なクエリーキューの 1 つ以上のスロットが取得され、それらのスロットに関連付けられたメモリが使用されます。他の操作が実行されている場合、十分なクエリキュースロットを使用できない可能性があります。この場合、クエリは処理を開始する前にスロットが空くのを待つ必要があります。クエリキューの作成と設定の詳細については、「ワークロード管理」を参照してください。

クエリ構造 – クエリの書き込み方法は、そのパフォーマンスに影響を与えます。できる限り少ないデータを処理して返すクエリを記述すると、ニーズを満たすことができます。詳細については、「Amazon Redshift クエリの設計のベストプラクティス」を参照してください。

コードコンパイル – Amazon Redshift は、各クエリ実行プランのコードを生成してコンパイルします。

コンパイル済みコードは、インタプリタを使用してオーバーヘッドを削除するため、高速で実行されます。通常、コードが初めて生成およびコンパイルされるときは、ある程度のオーバーヘッドコストが生じます。その結果、最初に実行したときのクエリのパフォーマンスは、誤解を招く場合があります。1 回限りのクエリを実行するときは、オーバーヘッドコストは特に顕著になります。クエリのパフォーマンスを判断するには、必ず 2 回目にクエリを実行します。Amazon Redshift は、サーバーレスコンパイルサービスを使用して、Amazon Redshift クラスターのコンピューティングリソースを超えてクエリコンパイルをスケーリングします。コンパイルされたコードセグメントは、クラスターでローカルにキャッシュされるだけでなく、事実上無制限のキャッシュに保存されます。このキャッシュは、クラスターの再起動後も保持されます。同じクエリをそれ以降に実行すると、コンパイルフェーズをスキップできるため、高速になります。

キャッシュは Amazon Redshift のバージョン間で互換性がないため、バージョンのアップグレード後にクエリが実行されると、コンパイルキャッシュがフラッシュされ、コードが再コンパイルされます。クエリに厳密な SLA がある場合は、クラスターテーブルのデータをスキャンするクエリセグメントを事前に実行することをお勧めします。これにより、Amazon Redshift でベーステーブルデータがキャッシュされるため、バージョンアップグレード後のクエリの計画時間を短縮できます。スケーラブルなコンパイルサービスを使用することで、Amazon Redshift はコードを並行してコンパイルし、常に高速のパフォーマンスを実現できます。ワークロードの高速化の大きさは、クエリの複雑さと同時実行性によって異なります。