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/)を参照してください。
# ソートキー
**注記**
`SORTKEY AUTO` を使用してテーブルを作成することをお勧めします。その場合、Amazon Redshift は自動テーブル最適化を使用してソートキーを選択します。詳細については、「[自動テーブル最適化](t_Creating_tables.md)」を参照してください。このセクションの残りの部分では、ソート順について詳しく説明します。
テーブルの作成時に、代わりにその 1 つ以上の列を*ソートキー*として定義することもできます。データが空のテーブルに最初にロードされると、行がディスク上にソート順に格納されます。ソートキー列に関する情報がクエリプランナーに渡され、プランナはこの情報を使用して、データのソート方法を利用するプランを構築します。詳細については、「[CREATE TABLE](r_CREATE_TABLE_NEW.md)」を参照してください。ソートキーを作成する際のベストプラクティスについては、「[最良のソートキーの選択](c_best-practices-sort-key.md)」を参照してください。
ソートは、範囲が制限された述語を効率的に処理することができます。Amazon Redshift は、列データを 1 MB のディスクブロックに保存します。各ブロックの最小値と最大値がメタデータの一部として格納されます。範囲が制限された述語をクエリが使用する際には、クエリプロセッサはこの最小値と最大値を使用します。これにより、テーブルスキャン中に多数のブロックをすばやくスキップすることができます。例えば、日付でソートされた 5 年間のデータがテーブルに保存されており、クエリによって 1 か月間の日付範囲が指定されているとします。この場合、スキャンからディスクブロックの最大 98% を削除できます。データがソートされない場合は、より多くの (場合によっては、すべての) ディスクブロックをスキャンする必要があります。
複合キーまたはインターリーブソートキーを指定できます。複合ソートキーは、クエリ述語が、ソートキー列のサブセットの順序である*プレフィックス*を使用する場合に効果的です。インターリーブソートキーは、ソートキーの各列に同じ重み付けをするため、クエリ述語が任意の順序でソートキーを構成する列のサブセットを使用できます。
選択されたソートキーがクエリパフォーマンスに与える影響を把握するには、[EXPLAIN](r_EXPLAIN.md) コマンドを使用します。詳細については、「[クエリプランと実行ワークフロー](c-query-planning.md)」を参照してください。
ソートタイプを定義するには、CREATE TABLE または CREATE TABLE AS ステートメントで INTERLEAVED または COMPOUND キーワードを使用します。デフォルトは COMPOUND です。INSERT、UPDATE、または DELETE オペレーションを使用してテーブルを定期的に更新する場合は、COMPOUND を使用することをお勧めします。INTERLEAVED ソートキーは最大 8 列で使用できます。データとクラスターのサイズに応じて、VACUUM REINDEX は、インターリーブソートキーを分析する目的で追加パスを作成するため、VACUUM FULL よりも大幅に実行時間が長くなります。インターリーブテーブルでは、ソート操作およびマージ操作の時間が長くなる場合があります。これは、インターリーブソートでは、複合ソートよりも多くの行の再調整が必要になる可能性があるためです。
テーブルのソートキーを表示するには、[SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md) システムビューに対してクエリを実行します。
**Topics**
+ [多次元データレイアウトのソート](t_Sorting_mutidimensional-sort-key.md)
+ [複合ソートキー](t_Sorting_data-compound.md)
+ [インターリーブソートキー](t_Sorting_data-interleaved.md)
# 多次元データレイアウトのソート
多次元データレイアウトソートキーは、ワークロード内の反復述語に基づく AUTO ソートキータイプの一つです。ワークロードに反復述語がある場合、Amazon Redshift は反復述語を満たすデータ行をコロケーションすることでテーブルスキャンのパフォーマンスを向上させることができます。多次元データレイアウトソートキーでは、テーブルのデータを厳密な列順序で保存する代わりに、ワークロードに現れる反復述語を分析してデータを格納します。1 つのワークロードに複数の反復述語が見られる場合があります。ワークロードによっては、このようなソートキーを使用すると多くの述語のパフォーマンスが向上します。Amazon Redshift は、このソートキーメソッドを `AUTO` ソートキーで定義されたテーブルに使用すべきかどうかを自動的に判断します。
例えば、データを列の順序でソートしたテーブルがあるとします。多くのデータブロックを調べて、それらがワークロードの述語を満たしているかどうかを判断する必要があるかもしれません。ただし、データが述語順にディスクに保存されている場合は、クエリを満たすためにスキャンする必要があるブロックの数が少なくなります。このような場合は、多次元データレイアウトソートキーを使用すると便利です。
クエリが多次元データレイアウトキーを使用しているかどうかを確認するには、[SYS\$1QUERY\$1DETAIL](SYS_QUERY_DETAIL.md) ビューの `step_attribute` 列を参照してください。値が `multi-dimensional` の場合、クエリには多次元データレイアウトが使用されています。
Amazon Redshift が多次元データレイアウトソートキーを使用しないようにするには、`SORTKEY AUTO` 以外の別のテーブルソートキーオプションを選択します。SORTKEY オプションの詳細については、「[CREATE TABLE](r_CREATE_TABLE_NEW.md)」を参照してください。
# 複合ソートキー
複合キーは、ソートキー定義内にリストされているすべての列で構成されています。順序はリストされている順です。複合ソートキーは、クエリのフィルターがソートキーのプレフィックスを使用してフィルターや結合などの条件を適用する場合に便利です。複合ソートを実行する利点は、クエリがセカンダリソート列のみに依存しプライマリ列を参照しない場合には薄くなります。COMPOUND はデフォルトのソート形式です。
複合ソートキーで、結合、GROUP BY および ORDER BY 操作、PARTITION BY や ORDER BY を使用したウィンドウ関数の速度が上がる場合があります。例えば、データが結合列で分散および事前にソートされる場合は、ハッシュ結合よりも迅速なことの多いマージ結合が適しています。複合ソートキーは、圧縮の向上にも役立ちます。
すでにデータが含まれているソート済みテーブルに行を追加すると、未ソートのリージョンが増加し、パフォーマンスに大きな影響が生じます。影響は、テーブルがインターリーブソートを使用する場合、特にソート列が日付やタイムスタンプの列など一定間隔で増加するデータを含む場合、いっそう大きくなります。定期的に VACUUM 操作を実行してください。特に大量のデータをロードした後は、データを再ソートし再分析するために必要です。詳細については、「[未ソートリージョンのサイズを管理する](vacuum-managing-vacuum-times.md#r_vacuum_diskspacereqs)」を参照してください。バキューム処理を実行してデータを再ソートした後は、ANALYZE コマンドを実行してクエリプランナー用の統計メタデータを更新することをお勧めします。詳細については、「[テーブルを分析する](t_Analyzing_tables.md)」を参照してください。
# インターリーブソートキー
インターリーブソートキーは、ソートキー内の各列または列のサブセットに同じ重み付けをします。複数のクエリが 1 つのフィルターで異なる列を使用する場合、インターリーブソート形式を使用することで、多くの場合これらのクエリのパフォーマンスが向上します。クエリがセカンダリソート列で制限述語を使用する場合、インターリーブソートは複合ソートに比べて大幅にクエリのパフォーマンスが向上します。
**重要**
ID 列、日付、タイムスタンプなど、一定間隔で増加する属性を持つ列で、インターリーブソートキーを使用しないでください。
インターリーブソートキーの実行によって得られるパフォーマンスの改善は、ロードの増分とバキューム処理の回数によって異なります。
インターリーブソートは、例えば `select c_name from customer where c_region = 'ASIA'` のように WHERE 句のソートキー列をフィルタリングする非常に選択的なクエリの場合に最も効果的です。インターリーブソートの効果は、制限されたソート済み列の数で向上します。
インターリーブソートは大きなテーブルに対してより効果的です。ソートは各スライスに適用されます。したがって、スライスごとに 1 MB のブロックを複数必要とする大きなテーブルの場合、インターリーブソートが最も効果的です。ここで、クエリプロセッサは、制限述語を使用してブロックのかなりの割合をスキップできます。テーブルが使用するブロック数を表示するには、[STV\$1BLOCKLIST](r_STV_BLOCKLIST.md) システムビューに対してクエリを実行します。
単一の列を並べ替える場合、列の値に長い共通プレフィックスがある場合は、インターリーブソートの方が複合ソートよりもパフォーマンスがいい場合があります。例えば、URL は一般的に「http://www」で始まります。複合ソートキーはプレフィックスから使用する文字数に制限があるため、大量のキーの重複が発生します。インターリーブソートは、ゾーンのマッピング値に内部圧縮方式を使用するため、長い共通プレフィックスがある列の値をよりよく識別できます。
小さな Amazon Redshift プロビジョニングクラスターを Amazon Redshift Serverless に移行すると、Redshift はインターリーブソートキーと DISTSTYLE KEY の両方を持つテーブルを複合ソートキーに変換します。ただし、インターリーブソートキーのみを持つテーブルは変更されません。分散スタイルの詳細については、「[データディストリビューションスタイルの操作](https://docs.aws.amazon.com//redshift/latest/dg/t_Distributing_data.html)」を参照してください。
**VACUUM REINDEX**
すでにデータが含まれているソート済みテーブルに行を追加すると、パフォーマンスが時間とともに悪化することがあります。この悪化は複合ソートとインターリーブソートの両方で発生しますが、インターリーブテーブルでより影響が大きくなります。VACUUM はソート順序を復元しますが、インターリーブテーブルの場合は操作に時間がかかります。これは、新規のインターリーブデータのマージを行う際に各データブロックの変更が必要になる場合があるためです。
テーブルが最初にロードされると、Amazon Redshift がソートキー列の値の分散を分析し、その情報を基に適切なインターリービングをソートキー列に実行します。テーブルが大きくなるにつれて、ソートキー列の値の分散は、特に日付またはタイムスタンプ列で、変化したり不均等になったりします。不均等が大きくなりすぎると、パフォーマンスに影響を与えます。ソートキーを再分析してパフォーマンスを復元するには、REINDEX キーワードとともに VACUUM コマンドを実行します。インターリーブテーブルの場合、データに対して追加の分析パスを取る必要があるため、VACUUM REINDEX は標準の VACUUM よりも時間がかかります。キーの分散スキューおよび直近のインデックス再作成時間を表示するには、[SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md) システムビューにクエリを実行します。
VACUUM の実行頻度および VACUUM REINDEX の実行時期についての詳細は、「[インデックスを再生成するかどうかの決定](vacuum-managing-vacuum-times.md#r_vacuum-decide-whether-to-reindex)」を参照してください。