メニュー
Amazon Redshift
データベース開発者ガイド (API Version 2012年12月1日)

パフォーマンス

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

超並列処理

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

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

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

列指向データストレージ

データベーステーブルの列指向ストレージによって必要なディスク I/O の総量が大幅に減少するので、この機能は分析クエリのパフォーマンスの最適化において重要な要因です。データベーステーブルの情報を列指向の方式で格納すると、ディスク I/O 要求の数と、ディスクからロードする必要のあるデータの量が減ります。メモリにロードするデータが減少するので、Amazon Redshift はクエリを実行するときにより多くのメモリ内処理を実行できます。詳細な説明については、「列指向ストレージ」を参照してください。

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

データ圧縮

データ圧縮により必要なストレージが減るので、ディスク 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 は、次の条件がすべて満たされた場合に、新しいクエリに対してキャッシュされた結果を使用します。

  • クエリを発行したユーザーは、クエリで使用されるオブジェクトへのアクセス権を持っています。

  • クエリ内のテーブルまたはビューは変更されていません。

  • クエリでは、GETDATE のような、実行するたびに評価する必要がある関数は使用されません。

  • クエリの結果に影響を与える構成パラメーターは変更されません。

  • クエリは、キャッシュされたクエリと構文的に一致します。

キャッシュの有効性とリソースの効率的な使用を最大化するために、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 |

前の例に示す結果の作成に使用されたクエリの詳細については、「テーブル設計のチューニング」の「ステップ 2: システムパフォーマンスをテストしてベースラインを確定する」を参照してください。

コンパイル済みコード

リーダーノードは、完全に最適化されたコンパイル済みコードをクラスターのすべてのノードに分配します。クエリをコンパイルすると、インタープリタに伴うオーバーヘッドがなくなるので、実行速度 (特に複雑なクエリの場合) が向上します。コンパイル済みのコードはキャッシュされて、同じクラスターのセッション間で共有されるので、多くの場合、同じクエリーの 2 回目以降の実行は、パラメータが異なっていたとしても速くなります。

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