翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon Redshift のクエリパフォーマンス係数
いくつかの要因がクエリパフォーマンスに影響を与える可能性があります。データ、クラスター、およびデータベースオペレーションの以下の側面はすべて、クエリの処理速度に影響します。
-
-
ソートキー (Amazon Redshift Advisor)
-
データ圧縮 (自動）
-
データのディストリビューション (自動）
-
テーブルのメンテナンス (自動）
-
-
-
ワークロード管理 (自動）
-
ショートクエリアクセラレーション (自動）
テーブルプロパティ
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 ドキュメントの「テーブルのバキューム処理」を参照してください。
分析
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 クラスターの概要」を参照してください。
ノードサイズ、ノード数、スライス
コンピューティングノードはスライスに分割されています。ノードが多いほどプロセッサとスライスが多くなり、クエリの一部をスライス間で同時に実行することで、クエリの処理を高速化できます。ただし、ノード数が多いほど、コストも高くなります。つまり、システムに適したコストとパフォーマンスのバランスを見つける必要があります。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 回限りのクエリを実行すると、オーバーヘッドコストが特に顕著になる可能性があります。クエリをもう一度実行して、その一般的なパフォーマンスを判断することをお勧めします。
Amazon Redshift は、サーバーレスコンパイルサービスを使用して、Amazon Redshift クラスターのコンピューティングリソースを超えてクエリコンパイルをスケーリングします。コンパイルされたコードセグメントは、クラスターでローカルにキャッシュされるだけでなく、事実上無制限のキャッシュに保存されます。このキャッシュは、クラスターの再起動後も保持されます。同じクエリの後続の呼び出しは、コンパイルフェーズをスキップできるため、より速く実行されます。キャッシュは Amazon Redshift のバージョン間で互換性がないため、バージョンのアップグレード後にクエリが実行されると、コードが再コンパイルされます。スケーラブルなコンパイルサービスを使用することで、Amazon Redshift はコードを並行してコンパイルし、常に高速のパフォーマンスを実現できます。ワークロードの高速化の大きさは、クエリの複雑さと同時実行性によって異なります。
