Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。
# Amazon Redshift のパフォーマンス
このトピックでは、パフォーマンスを向上させる Amazon Redshift のコンポーネントについて説明します。これらのコンポーネントを理解することで、Amazon Redshift のパフォーマンスを調整し、パフォーマンスの低下をトラブルシューティングするのに役立ちます。
Amazon Redshift では、以下のパフォーマンス機能を採用することによって、極めて高速のクエリ実行を実現しています。
**Topics**
+ [超並列処理](#massively-parallel-processing)
+ [列指向データストレージ](#columnar-data-storage)
+ [データ圧縮](#data-compression)
+ [クエリオプティマイザ](#query-optimizer)
+ [結果のキャッシュ](#result-caching)
+ [コンパイル済みコード](#compiled-code)
## 超並列処理
超並列処理 (MPP) により、大量のデータに対して非常に複雑なクエリを高速で実行できます。複数のコンピューティングノードがすべてのクエリ処理を行って、最終的に結果が集計されます。各ノードの各コアは、同じコンパイル済みクエリセグメントをデータ全体の一部分に対して実行します。
Amazon Redshift では、テーブルの行がコンピューティングノードに分散され、これによりデータの並列処理が可能となっています。各テーブルに対して適切な分散キーを選択することにより、データの分配を最適化して、ワークロードを分散し、ノード間のデータの移動を低減できます。詳細については、「[最適な分散スタイルの選択](c_best-practices-best-dist-key.md)」を参照してください。
フラットファイルからのデータのロードでは、複数のノードにワークロードを分散させることで並列処理を活用しながら、複数のファイルから同時に読み取ります。テーブルへのデータのロード方法の詳細については、「[データをロードするための Amazon Redshift のベストプラクティス](c_loading-data-best-practices.md)」を参照してください。
## 列指向データストレージ
データベーステーブルの列指向ストレージはディスク全体の必要な I/O を大幅に減らすため、分析クエリのパフォーマンスの最適化の重要な要因となっています。詳細については、「[列指向ストレージ](c_columnar_storage_disk_mem_mgmnt.md)」を参照してください。
列が適切にソートされていると、クエリプロセッサは大きいデータブロックのサブセットをすばやく除外できます。詳細については、「[最良のソートキーの選択](c_best-practices-sort-key.md)」を参照してください。
## データ圧縮
データ圧縮により必要なストレージが減るので、ディスク I/O が減少し、クエリのパフォーマンスが向上します。クエリを実行すると、圧縮されたデータがメモリに読み込まれ、クエリの実行時に圧縮解除されます。メモリにロードするデータを少なくできるので、Amazon Redshift は、より多くのメモリをデータ分析のために割り当てられるようになります。列指向ストレージでシーケンシャルに格納される類似のデータに対して、Amazon Redshift では、列指向のデータ型と明示的に結び付けられた適応型圧縮エンコーディングを利用しています。テーブルの列でデータの圧縮を有効にする最良の方法は、テーブルにデータをロードする際に、Amazon Redshift で最適な圧縮エンコーディングが適用されるようにすることです。自動データ圧縮の詳細については、「[自動圧縮ありでテーブルをロードする](c_Loading_tables_auto_compress.md)」を参照してください。
## クエリオプティマイザ
Amazon Redshift のクエリ実行エンジンには、MPP 対応で、列指向データストレージも利用するクエリオプティマイザが組み込まれています。Amazon Redshift のクエリオプティマイザでは、複数テーブルの結合、サブクエリ、および集計処理が含まれることが多い、複雑な分析クエリを処理するための、多くの強化機能と拡張機能が実装されています。クエリの最適化の詳細については、「[クエリパフォーマンスのチューニング](c-optimizing-query-performance.md)」を参照してください。
## 結果のキャッシュ
クエリの実行時間を短縮し、システムパフォーマンスを向上させるために、Amazon Redshift は特定の種類のクエリの結果をリーダーノード上のメモリにキャッシュします。ユーザーがクエリを送信すると、Amazon Redshift は結果キャッシュ内で、有効性がありキャッシュされているクエリ結果のコピーをチェックします。結果のキャッシュに一致するものが見つかった場合、Amazon Redshift はキャッシュ済みの結果を使用して、クエリは実行しません。結果のキャッシュはユーザーに対して透過的です｡
結果のキャッシュはデフォルトでオンになっています。現在のセッションで結果のキャッシュをオフにするには、[enable\$1result\$1cache\$1for\$1session](r_enable_result_cache_for_session.md) パラメータを `off` に設定します。
Amazon Redshift は、次の条件がすべて満たされた場合に、新しいクエリに対してキャッシュ内の結果を適用します。
+ クエリを発行したユーザーは、クエリで使用されるオブジェクトへのアクセス許可を持っています。
+ クエリ内のテーブルまたはビューは変更されていません。
+ クエリでは、GETDATE のような、実行するたびに評価する必要がある関数は使用されません。
+ クエリは Amazon Redshift Spectrum の外部テーブルを参照しません。
+ クエリの結果に影響を与える構成パラメータは変更されません。
+ クエリは、キャッシュされたクエリと構文的に一致します。
キャッシュの有効性を最大化し、リソースを最も効率的に使用をするため、Amazon Redshift では、サイズの大きなクエリ結果セットの一部をキャッシュしていません。Amazon Redshift は、クエリ結果をキャッシュするかどうかを、さまざまな要因に基づいて決定します。それらの要因とは、キャッシュ内のエントリ数や、Amazon Redshift クラスターのインスタンスタイプなどです。
クエリで結果のキャッシュを使用するかどうかを決定するには､[SVL\$1QLOG](r_SVL_QLOG.md) システムビューをクエリします。クエリで結果キャッシュが使用された場合、source\$1query 列はソースクエリのクエリ ID を戻します。結果のキャッシュが使用されない場合、source\$1query 列の値は 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 |
```
## コンパイル済みコード
コードコンパイル – Amazon Redshift は、クエリ実行プランごとに最適化されたコードを生成してコンパイルします。コンパイル済みコードは、インタプリタを使用してオーバーヘッドを排除するため、高速で実行されます。コンパイルされたコードのパフォーマンス上の利点を維持しながら、新しいクエリのレイテンシーを最小限に抑えるために、Amazon Redshift はコンポジションと呼ばれる手法を使用します。コンポジションは、新しいクエリを即座に処理するために既存のロジックを軽量に配置し、同時に高度に最適化されたクエリ固有のコードをバックグラウンドでコンパイルします。これにより、クエリ実行のクリティカルパスからコンパイルが削除されるため、新しいクエリはより高速に開始され、後続のクエリと同様の高速なパフォーマンスで実行されます。
また、Amazon Redshift はサーバーレスコンパイルサービスを使用することで、Amazon Redshift クラスターのコンピューティングリソースを超えてクエリコンパイルをスケールします。コンパイルされたコードセグメントは、クラスターにローカルにキャッシュされるだけでなく、クラスターの再起動後も持続する、事実上無制限のリモートキャッシュにも保存されます。同じクエリをそれ以降に実行すると、コンパイルフェーズをスキップできるため、高速になります。スケーラブルなコンパイルサービスを使用することで、Amazon Redshift はコードを並行してコンパイルし、常に高速のパフォーマンスを実現します。