Amazon Redshift のパフォーマンス

このトピックでは、パフォーマンスを向上させる Amazon Redshift のコンポーネントについて説明します。これらのコンポーネントを理解することで、Amazon Redshift のパフォーマンスを調整し、パフォーマンスの低下をトラブルシューティングするのに役立ちます。

Amazon Redshift では、以下のパフォーマンス機能を採用することによって、極めて高速のクエリ実行を実現しています。

超並列処理

超並列処理 (MPP) により、大量のデータに対して非常に複雑なクエリを高速で実行できます。複数のコンピューティングノードがすべてのクエリ処理を行って、最終的に結果が集計されます。各ノードの各コアは、同じコンパイル済みクエリセグメントをデータ全体の一部分に対して実行します。

Amazon Redshift では、テーブルの行がコンピューティングノードに分散され、これによりデータの並列処理が可能となっています。各テーブルに対して適切な分散キーを選択することにより、データの分配を最適化して、ワークロードを分散し、ノード間のデータの移動を低減できます。詳細については、「最適な分散スタイルの選択」を参照してください。

フラットファイルからのデータのロードでは、複数のノードにワークロードを分散させることで並列処理を活用しながら、複数のファイルから同時に読み取ります。テーブルへのデータのロード方法の詳細については、「データをロードするための Amazon Redshift のベストプラクティス」を参照してください。

列指向データストレージ

データベーステーブルの列指向ストレージはディスク全体の必要な I/O を大幅に減らすため、分析クエリのパフォーマンスの最適化の重要な要因となっています。詳細については、「列指向ストレージ」を参照してください。

列が適切にソートされていると、クエリプロセッサは大きいデータブロックのサブセットをすばやく除外できます。詳細については、「最良のソートキーの選択」を参照してください。

データ圧縮

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

クエリオプティマイザ

Amazon Redshift のクエリ実行エンジンには、MPP 対応で、列指向データストレージも利用するクエリオプティマイザが組み込まれています。Amazon Redshift のクエリオプティマイザでは、複数テーブルの結合、サブクエリ、および集計処理が含まれることが多い、複雑な分析クエリを処理するための、多くの強化機能と拡張機能が実装されています。クエリの最適化の詳細については、「クエリパフォーマンスのチューニング」を参照してください。

結果のキャッシュ

クエリの実行時間を短縮し、システムパフォーマンスを向上させるために、Amazon Redshift は特定の種類のクエリの結果をリーダーノード上のメモリにキャッシュします。ユーザーがクエリを送信すると、Amazon Redshift は結果キャッシュ内で、有効性がありキャッシュされているクエリ結果のコピーをチェックします。結果のキャッシュに一致するものが見つかった場合、Amazon Redshift はキャッシュ済みの結果を使用して、クエリは実行しません。結果のキャッシュはユーザーに対して透過的です｡

結果のキャッシュはデフォルトでオンになっています。現在のセッションで結果のキャッシュをオフにするには、enable_result_cache_for_session パラメータを off に設定します。

Amazon Redshift は、次の条件がすべて満たされた場合に、新しいクエリに対してキャッシュ内の結果を適用します。

キャッシュの有効性を最大化し、リソースを最も効率的に使用をするため、Amazon Redshift では、サイズの大きなクエリ結果セットの一部をキャッシュしていません。Amazon Redshift は、クエリ結果をキャッシュするかどうかを、さまざまな要因に基づいて決定します。それらの要因とは、キャッシュ内のエントリ数や、Amazon Redshift クラスターのインスタンスタイプなどです。

クエリで結果のキャッシュを使用するかどうかを決定するには､SVL_QLOG システムビューをクエリします。クエリで結果キャッシュが使用された場合、source_query 列はソースクエリのクエリ ID を戻します。結果のキャッシュが使用されない場合、source_query 列の値は Null になります。

次の例は、ユーザー ID 104 およびユーザー ID 102 によって送信されたクエリが、ユーザー ID 100 によって実行されるクエリからの結果キャッシュを使用することを示しています。

select userid, query, elapsed, source_query from svl_qlog 
where userid > 1
order by query desc;

userid | query  | elapsed  | source_query
-------+--------+----------+-------------
   104 | 629035 |       27 |       628919
   104 | 629034 |       60 |       628900
   104 | 629033 |       23 |       628891
   102 | 629017 |  1229393 |             
   102 | 628942 |       28 |       628919
   102 | 628941 |       57 |       628900
   102 | 628940 |       26 |       628891
   100 | 628919 | 84295686 |             
   100 | 628900 | 87015637 |             
   100 | 628891 | 58808694 |             

コンパイル済みコード

リーダーノードは、完全に最適化されたコンパイル済みコードをクラスターのすべてのノードに分配します。クエリをコンパイルすると、インタープリタに伴うオーバーヘッドが削減されるので、実行速度 (特に複雑なクエリの場合) が向上します。コンパイル済みのコードはキャッシュされ、同じクラスターのセッション間で共有されます。その結果、同じクエリを将来的に実行した場合、パラメータを変えても高速化されることが多くなります。

クエリ実行エンジンは、JDBC と ODBC 接続プロトコルでは異なるコードをコンパイルするので、異なるプロトコルを使用する 2 つのクライアントで、コードの初回コンパイル時のコストが発生します。ただし、同じプロトコルを使用するクライアントには、キャッシュされたコードの共有によるメリットがあります。