翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon Redshift でのクエリのパフォーマンス要因

いくつかの要因がクエリパフォーマンスに影響を与える可能性があります。データ、クラスター、データベース操作の次の側面はすべて、クエリ処理の速度に影響を与えます。

テーブルプロパティ

Amazon Redshift テーブルは、Amazon Redshift にデータを保存するための基本的な単位であり、各テーブルには、その動作とアクセシビリティを決定する一連のプロパティがあります。これらのプロパティには、ソート、分散スタイル、圧縮エンコーディングなどが含まれます。これらのプロパティを理解することは、Amazon Redshift テーブルのパフォーマンス、セキュリティ、コスト効率を最適化するために不可欠です。

ソートキー

Amazon Redshift は、テーブルのソートキーに応じたソート順で、データをディスクに保存します。クエリオプティマイザとクエリプロセッサは、コンピューティングノード内のデータの保存場所に関する情報を使用して、スキャンする必要があるブロックの数を減らします。これにより、処理するデータの量が減り、クエリ速度が大幅に向上します。ソートキーを使用して、WHERE 句のフィルターを容易にすることをお勧めします。詳細については、Amazon Redshift のドキュメントの「ソートキーの使用」を参照してください。

データ圧縮

データ圧縮により必要なストレージが減るので、ディスク I/O が減少し、クエリのパフォーマンスが向上します。クエリを実行すると、圧縮されたデータがメモリに読み込まれ、クエリの実行時に圧縮解除されます。メモリにロードするデータを少なくできるので、Amazon Redshift は、より多くのメモリをデータ分析のために割り当てられるようになります。列指向ストレージでシーケンシャルに格納される類似のデータに対して、Amazon Redshift では、列指向のデータ型と明示的に結び付けられた適応型圧縮エンコーディングを利用できます。テーブルの列でデータの圧縮を有効にする最良の方法は、テーブルにデータをロードする際に、Amazon Redshift の AUTO オプションを使用して、最適な圧縮エンコーディングが適用されるようにすることです。自動データ圧縮の使用の詳細については、Amazon Redshift ドキュメントの「自動圧縮ありでテーブルをロードする」を参照してください。

データのディストリビューション

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

テーブルのメンテナンス

Amazon Redshift はほとんどのワークロードで業界標準のパフォーマンスを提供しますが、Amazon Redshift クラスターを正常に実行し続けるにはメンテナンスが必要です。データを更新および削除すると、バキューム処理が必要なデッド行が作成され、追加順序がソートキーと一致しない場合は、追加専用テーブルも再ソートする必要があります。

Vacuum

Amazon Redshift でのバキューム処理プロセスは、Amazon Redshift クラスターのヘルスとメンテナンスに不可欠です。また、クエリのパフォーマンスにも影響します。削除や更新によって古いデータにフラグが付きますが、実際に削除されたわけではないため、バキューム処理を使用して、前の UPDATE および DELETE 操作で削除対象としてマークされたテーブル行によって占有されたディスク領域を再利用する必要があります。Amazon Redshift は、バックグラウンドでテーブルを自動的にソートし、VACUUM DELETE オペレーションを実行できます。

ロードまたは一連の増分更新の後にテーブルをクリーンアップするには、データベース全体または個々のテーブルに対して VACUUM コマンドを実行することもできます。テーブルにソートキーがあり、テーブルのロードが挿入時にソートするように最適化されていない場合は、バキュームを使用してデータを再ソートする必要があります (これはパフォーマンスにとって重要です)。詳細については、Amazon Redshift ドキュメントの「Vacuuming tables」を参照してください。

分析

ANALYZE 操作によって、Amazon Redshift データベース内のテーブルの統計メタデータを更新します。統計を最新状態に保つことで、クエリプランナーが最適なプランを選択できるようになるため、クエリのパフォーマンスが向上します。Amazon Redshift はデータベースを継続的にモニタリングし、バックグラウンドで自動的に分析オペレーションを実行します。システムパフォーマンスへの影響を最小限にするために、ANALYZE 操作はワークロードが軽い期間に自動で実行されます。ANALYZE を明示的に実行することを選択した場合は、以下を実行する必要があります。

クラスターの設定

クラスターは、データの実際の保存と処理を実行するノードのコレクションです。以下を実現するには、Amazon Redshift クラスターを正しい方法で設定してください。

ノードの種類

Amazon Redshift クラスターは、複数のノードタイプ (RA3、DC2、DS2) のいずれかを使用できます。各ノードタイプは様々なサイズを提供し、クラスターを適切に拡張することができるように制限します。ノードサイズによって、クラスター内の各ノードのストレージ容量、メモリ、CPU、および料金が決まります。コストとパフォーマンスの最適化は、適切なノードタイプとサイズを選択することから始まります。ノードタイプの詳細については、Amazon Redshift ドキュメントの「Amazon Redshift クラスターの概要」を参照してください。

ノードサイズ、ノード数、スライス数

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

ワークロード管理

Amazon Redshift のワークロード管理 (WLM) により、ユーザーはワークロードのキューに優先順位を付けて柔軟に管理することが可能になります。これにより、実行速度が高く処理時間の短いクエリが、処理時間の長いクエリの後に滞らないようにできます。自動 WLM は、機械学習 (ML) アルゴリズムを使用してクエリをプロファイリングし、クエリの同時実行とメモリ割り当てを管理しながら、適切なリソースを使用して適切なキューに配置します。WLM の詳細については、Amazon Redshift ドキュメントの「ワークロード管理の実装」を参照してください。

ショートクエリアクセラレーション

ショートクエリアクセラレーション (SQA) は、実行時間が短いクエリを、実行時間が長いクエリよりも優先します。SQA では実行時間が短いクエリを専用領域で実行します。このため SQA クエリは、実行時間が長いクエリをキューで待機するよう強制されません。SQA は、実行時間が短く、ユーザー定義のキュー内にあるクエリのみを優先します。SQA を使用すると、実行時間が短いクエリの実行開始が早くなり、ユーザーへの結果表示も早くなります。SQA を有効にすると、実行時間の短いクエリ専用の WLM キューを減らす、またはなくすことができます。さらに、長時間実行されるクエリは、WLM キュー内のスロットに対して競合する必要はありません。つまり、より少ないクエリスロットを使用するように WLM キューを設定できます。同時実行数が減るとクエリのスループットが向上し、大部分のワークロードに関するシステム全体のパフォーマンスも向上します。SQA の詳細については、Amazon Redshift ドキュメントの「「ショートクエリアクセラレーションを使用する」を参照してください。

SQL クエリ

データベースクエリは、データベースからのデータのリクエストです。リクエストは SQL を使用して Amazon Redshift クラスターに送信される必要があります。Amazon Redshift は、Java Database Connectivity (JDBC) および Open Database Connectivity (ODBC) を介して接続する SQL クライアントツールをサポートします。JDBC または ODBC ドライバーをサポートするほとんどの SQL クライアントツールを使用できます。

クエリ構造

クエリの書き込み方法は、そのパフォーマンスに大きな影響を与えます。クエリを作成して処理し、ニーズに合わせて必要な最小限のデータを返すことをお勧めします。クエリの構造方法の詳細については、このガイドの「Amazon Redshift クエリの設計のベストプラクティス」セクションを参照してください。

コードコンパイル

Amazon Redshift は、各クエリ実行プランのコードを生成してコンパイルします。コンパイル済みコードは、インタプリタを使用してオーバーヘッドを削除するため、高速で実行されます。通常、コードが初めて生成およびコンパイルされるときは、ある程度のオーバーヘッドコストが生じます。その結果、最初に実行したときのクエリのパフォーマンスは、誤解を招く場合があります。1 回限りのクエリを実行するときは、オーバーヘッドコストが特に顕著になります。クエリのパフォーマンスを判断するには、必ず 2 回目にクエリを実行することをお勧めします。

Amazon Redshift は、サーバーレスコンパイルサービスを使用して、Amazon Redshift クラスターのコンピューティングリソースを超えてクエリコンパイルをスケーリングします。コンパイルされたコードセグメントは、クラスターでローカルにキャッシュされるだけでなく、事実上無制限のキャッシュに保存されます。このキャッシュは、クラスターの再起動後も保持されます。同じクエリをそれ以降に呼び出すと、コンパイルフェーズをスキップできるため、高速になります。キャッシュは Amazon Redshift のバージョン間で互換性がないため、バージョンのアップグレード後にクエリが実行されると、コードが再コンパイルされます。スケーラブルなコンパイルサービスを使用することで、Amazon Redshift はコードを並行してコンパイルし、常に高速のパフォーマンスを実現できます。ワークロードの高速化の大きさは、クエリの複雑さと同時実行性によって異なります。