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

ソートキーの選択

テーブルの作成時に、その 1 つ以上の列をソートキーとして定義することができます。データが空のテーブルに最初にロードされると、行がディスク上にソート順に格納されます。ソートキー列に関する情報がクエリプランナーに渡され、プランナはこの情報を使用して、データのソート方法を利用するプランを構築します。

ソートは、範囲が制限された述語を効率的に処理することができます。Amazon Redshift は、列データを 1 MB のディスクブロックに格納します。各ブロックの最小値と最大値がメタデータの一部として格納されます。範囲が制限された述語をクエリが使用する場合、クエリプロセッサは最小値と最大値を使用して、テーブルスキャン中に多数のブロックをすばやくスキップすることができます。たとえば、日付でソートされた 5 年間のデータがテーブルに格納され、クエリによって 1 か月間の日付範囲が指定される場合、最大 98% のディスクブロックをスキャンから除外できます。データがソートされない場合は、より多くの (場合によっては、すべての) ディスクブロックをスキャンする必要があります。

複合キーまたはインターリーブソートキーを指定できます。複合ソートキーは、クエリ述語が、ソートキー列のサブセットの順序であるプレフィックスを使用する場合に効果的です。インターリーブソートキーは、ソートキーの各列に同じ重み付けをするため、クエリ述語が任意の順序でソートキーを構成する列のサブセットを使用できます。複合ソートキーおよびインターリーブソートキーの使用例については、「ソート形式の比較」を参照してください。

選択されたソートキーがクエリパフォーマンスに与える影響を把握するには、EXPLAIN コマンドを使用します。詳細については、「クエリプランと実行ワークフロー」を参照してください。

ソートタイプを定義するには、CREATE TABLE または CREATE TABLE AS ステートメントで INTERLEAVED または COMPOUND キーワードを使用します。デフォルトは COMPOUND です。INTERLEAVED ソートキーは最大 8 列で使用できます。

テーブルのソートキーを表示するには、SVV_TABLE_INFO システムビューに対してクエリを実行します。

複合ソートキー

複合キーは、ソートキー定義内にリストされているすべての列で構成されています。順序はリストされている順です。複合ソートキーは、クエリのフィルタがソートキーのプレフィックスを使用してフィルタや結合などの条件を適用する場合に便利です。複合ソートを実行する利点は、クエリがセカンダリソート列のみに依存しプライマリ列を参照しない場合には薄くなります。COMPOUND はデフォルトのソート形式です。

複合ソートキーで、結合、GROUP BY および ORDER BY 操作、PARTITION BY や ORDER BY を使用したウィンドウ関数の速度が上がる場合があります。たとえば、データが結合列で分散および事前にソートされる場合は、ハッシュ結合よりも迅速なことの多いマージ結合が適しています。複合ソートキーは、圧縮の向上にも役立ちます。

すでにデータが含まれているソート済みテーブルに行を追加すると、未ソートのリージョンが増加し、パフォーマンスに大きな影響が生じます。影響は、テーブルがインターリーブソートを使用する場合、特にソート列が日付やタイムスタンプの列など一定間隔で増加するデータを含む場合、いっそう大きくなります。定期的に VACUUM 操作を実行してください。特に大量のデータをロードした後は、データを再ソートし再分析するために必要です。詳細については、「未ソートリージョンのサイズを管理する」を参照してください。バキューム処理を実行してデータを再ソートした後は、ANALYZE コマンドを実行してクエリプランナー用の統計メタデータを更新することをお勧めします。詳細については、「テーブルを分析する」を参照してください。

インターリーブソートキー

インターリーブソートキーは、ソートキー内の各列または列のサブセットに同じ重み付けをします。複数のクエリが 1 つのフィルタで異なる列を使用する場合、インターリーブソート形式を使用することで、多くの場合これらのクエリのパフォーマンスが向上します。クエリがセカンダリソート列で制限述語を使用する場合、インターリーブソートは複合ソートに比べて大幅にクエリのパフォーマンスが向上します。

重要

ID 列、日付、タイムスタンプなど、一定間隔で増加する属性を持つ列で、インターリーブソートキーを使用しないでください。

インターリーブソートキーの実行によって得られるパフォーマンスの改善は、ロードの増分とバキューム処理の回数によって異なります。

インターリーブソートは、たとえば select c_name from customer where c_region = 'ASIA' のように WHERE 句のソートキー列をフィルタリングする非常に選択的なクエリの場合に最も効果的です。インターリーブソートの効果は、制限されたソート済み列の数で向上します。

インターリーブソートは大きなテーブルに対してより効果的です。ソートは各スライスに適用されるので、スライスごとに 1 MB のブロックを複数必要とする大きなテーブルで、クエリプロセッサが制限述語を使用して多くのブロックをスキップできる場合に最も効果的です。テーブルが使用するブロック数を表示するには、STV_BLOCKLIST システムビューに対してクエリを実行します。

単一の列を並べ替える場合、列の値に長い共通プレフィックスがある場合は、インターリーブソートの方が複合ソートよりもパフォーマンスがいい場合があります。たとえば、URL は一般的に「http://www」で始まります。複合ソートキーはプレフィックスから使用する文字数に制限があるため、大量のキーの重複が発生します。インターリーブソートは、ゾーンのマッピング値に内部圧縮方式を使用するため、長い共通プレフィックスがある列の値をよりよく識別できます。

VACUUM REINDEX

すでにデータが含まれているソート済みテーブルに行を追加すると、パフォーマンスが時間とともに悪化することがあります。この悪化は複合ソートとインターリーブソートの両方で発生しますが、インターリーブテーブルでより影響が大きくなります。VACUUM はソート順序を復元しますが、インターリーブテーブルの場合は操作に時間がかかります。これは、新規のインターリーブデータのマージを行う際に各データブロックの変更が必要になる場合があるためです。

テーブルが最初にロードされると、Amazon Redshift がソートキー列の値の分散を分析し、その情報を基に適切なインターリービングをソートキー列に実行します。テーブルが大きくなるにつれて、ソートキー列の値の分散は、特に日付またはタイムスタンプ列で、変化したり不均等になったりします。不均等が大きくなりすぎると、パフォーマンスに影響を与えます。ソートキーを再分析してパフォーマンスを復元するには、REINDEX キーワードとともに VACUUM コマンドを実行します。データに対して追加の分析パスを取る必要があるため、VACUUM REINDEX はインターリーブテーブルに対する標準の VACUUM よりも時間がかかります。キーの分散スキューおよび直近のインデックス再作成時間を表示するには、SVV_INTERLEAVED_COLUMNS システムビューにクエリを実行します。

VACUUM の実行頻度および VACUUM REINDEX の実行時期についての詳細は、「インデックスを再生成するかどうかの決定」を参照してください。