メニュー
Amazon Redshift
データベース開発者ガイド (API Version 2012-12-01)

ステップ 4: 分散スタイルを選択する

テーブルにデータをロードすると、そのテーブルの分散スタイルに従って、Amazon Redshift がテーブルの行を各ノードスライスに分散します。ノードあたりのスライスの数は、クラスターのノードサイズによって決まります。たとえば、このチュートリアルで使用している dc1.large クラスターにはそれぞれが 2 つのスライスを持つ 4 つのノードがあるため、クラスターには合計 8 つのスライスがあります。ノードはいずれも並列クエリ実行に関与し、スライス間で分散されたデータを処理します。

クエリを実行すると、必要に応じて結合と集計を実行するために、クエリオプティマイザによって行がコンピューティングノードに再分散されます。再分散では、結合する特定の行を送信するか、またはテーブル全体をすべてのノードにブロードキャストすることが必要となる場合があります。

これらの目標を達成するには、分散スタイルを割り当てる必要があります。

  • 結合テーブルの行をコロケーションする

    結合列の行が同じスライスにあるときは、クエリの実行中に移動するデータを減らす必要があります。

  • クラスター内のスライス間でデータを均等に分散させます。

    データが均等に分散されている場合、ワークロードをすべてのスライスに均等に割り当てることができます。

これらの目標は場合によって競合することがあり、いずれの戦略が全体的なシステムパフォーマンスに最良の選択であるかを評価する必要があります。たとえば、均等な分散により、列内のすべての一致する値が同じスライスに配置される可能性があります。クエリでその列に対して等価フィルターを使用する場合、それらの値のあるスライスではワークロードの分散が不均等になります。テーブルが分散キーに基づいてコロケーションされる場合、スライスでは行の分散が不均等になることがあります。これは、キーがテーブル全体で不均等に分散されるためです。

このステップでは、データ分散の目標に関連して SSB テーブルの分散を評価し、テーブルに最適な分散スタイルを選択します。

分散スタイル

テーブルの作成時、EVEN、KEY、ALL という 3 つの分散スタイルのいずれかを指定します。

キー分散

行の分散は、特定の列に含まれている値に従って行われます。リーダーノードは、複数の一致する値を同じノードスライスに配置しようと試みます。結合キーに基づいてテーブルのペアを分散する場合、リーダーノードは、結合列に含まれている値に従って行をスライスにコロケーションします。これによって、共通の列からの一致する値が物理的にまとめて格納されるようになります。

ALL 分散

テーブル全体のコピーがすべてのノードに分散されます。EVEN 分散または KEY 分散によってテーブルの一部の行のみが各ノードに配置されている場合、ALL 分散を行うと、テーブルが関与しているあらゆる結合ですべての行が確実にコロケーションされるようになります。

均等な分散

行は、特定の列の値に含まれている値にかかわらず、ラウンドロビン方式で複数のスライス間で分散させます。EVEN 分散は、テーブルが結合に関与していない場合や、KEY 分散と ALL 分散のどちらを選択すべきかが明確でない場合に適切なスタイルです。EVEN 分散はデフォルトの分散スタイルです。

詳細については、「分散スタイル」を参照してください。

分散スタイルを選択するには

クエリを実行すると、必要に応じて結合と集計を実行するために、クエリオプティマイザによって行がコンピューティングノードに再分散されます。クエリの実行前にデータを適切な場所に配置することで、再分散処理の影響を最小限に抑えることができます。

最初の目標は、結合テーブル内の一致する行がコロケーションされるように、つまり、同じノードスライスに配置されるようにデータを分散することです。

  1. クエリプランの再分散処理を探すには、クエリの実行前に EXPLAIN コマンドを実行します。この例では、テストクエリセットの Query 2 を使用しています。

    Copy to clipboard
    explain select sum(lo_revenue), d_year, p_brand1 from lineorder, dwdate, part, supplier where lo_orderdate = d_datekey and lo_partkey = p_partkey and lo_suppkey = s_suppkey and p_category = 'MFGR#12' and s_region = 'AMERICA' group by d_year, p_brand1 order by d_year, p_brand1;

    以下に示しているのは、クエリプランの一部です。DS_BCAST または DS_DIST のラベルで始まるラベルを探します。

    Copy to clipboard
    QUERY PLAN XN Merge (cost=1038007224737.84..1038007224738.54 rows=280 width=20) Merge Key: dwdate.d_year, part.p_brand1 -> XN Network (cost=1038007224737.84..1038007224738.54 rows=280 width=20) Send to leader -> XN Sort (cost=1038007224737.84..1038007224738.54 rows=280 width=20) Sort Key: dwdate.d_year, part.p_brand1 -> XN HashAggregate (cost=38007224725.76..38007224726.46 rows=280 -> XN Hash Join DS_BCAST_INNER (cost=30674.95..38007188507.46 Hash Cond: ("outer".lo_orderdate = "inner".d_datekey) -> XN Hash Join DS_BCAST_INNER (cost=30643.00..37598119820.65 Hash Cond: ("outer".lo_suppkey = "inner".s_suppkey) -> XN Hash Join DS_BCAST_INNER Hash Cond: ("outer".lo_partkey = "inner".p_partkey) -> XN Seq Scan on lineorder -> XN Hash (cost=17500.00..17500.00 rows=56000 -> XN Seq Scan on part (cost=0.00..17500.00 Filter: ((p_category)::text = -> XN Hash (cost=12500.00..12500.00 rows=201200 -> XN Seq Scan on supplier (cost=0.00..12500.00 Filter: ((s_region)::text = 'AMERICA'::text) -> XN Hash (cost=25.56..25.56 rows=2556 width=8) -> XN Seq Scan on dwdate (cost=0.00..25.56 rows=2556

    DS_BCAST_INNER は、内部結合テーブルがすべてのスライスにブロードキャストされたことを示します。DS_DIST_BOTH ラベルがある場合、外部結合テーブルと内部結合テーブルの両方がスライス全体に再分散されたことを示します。ブロードキャストと再分散は、クエリパフォーマンスの観点ではコストの高い処理になることがあります。ブロードキャストと分散の処理を減らすか無くすような分散戦略の選択が必要になります。EXPLAIN プランの評価方法の詳細については、「クエリパターンの評価」を参照してください。

  2. ファクトテーブルと 1 つのディメンションテーブルをそれらの共通の列に基づいて分散させます。

    以下の図に示しているのは、SSB スキーマ内のファクトテーブル、LINEORDER、ディメンションテーブル間の関係です。

    各テーブルに使用できる分散キーは 1 つのみです。つまり、スキーマ内の 1 組のテーブルのみをそれらの共通の列に基づいてコロケーションできます。中央のファクトテーブルをまず選択するのは明らかです。その組となる 2 つ目のテーブルには、ファクトテーブルを一般的に結合する最大サイズのディメンションを選択します。この設計では、LINEORDER がファクトテーブルであり、PART が最大サイズのディメンションです。PART はそのプライマリキー p_partkey に基づいて LINEORDER に結合されます。

    LINEORDER の分散キーとして lo_partkey、PART の分散キーとして p_partkey を指定します。これにより、結合キーの一致する値がデータのロード時に同じスライスにコロケーションされるようになります。

  3. ALL 分散を使用するように一部のディメンションテーブルを変更します。

    ディメンションテーブルをファクトテーブルなどの重要な結合テーブルとコロケーションできない場合は、テーブル全体をすべてのノードに分散させることにより、パフォーマンスを大幅に向上できることがよくあります。すべての分散で確実に、結合行がすべてのスライスにコロケーションされるようになります。ALL 分散の選択前にすべての要因を比較検討する必要があります。ALL 分散を使用すると、ストレージの領域要件が増え、ロード時間が長くなり、メンテナンスオペレーションが多くなります。

    CUSTOMER、SUPPLIER、DWDATE では、プライマリキーに基づいて LINEORDER テーブルを結合します。ただし、LINEORDER は PART とコロケーションされるため、DISTSTYLE ALL を使用するように残りのテーブルを設定します。テーブルが比較的小さく頻繁に更新されないため、ALL 分散を使用することでストレージとロード時間への影響が最小限に抑えられます。

  4. 残りのテーブルに EVEN 分散を使用します。

    すべてのテーブルに DISTKEY または ALL 分散スタイルを割り当てたため、EVEN はいずれのテーブルにも割り当てていません。パフォーマンスの結果を評価した後、一部のテーブルの分散スタイルを ALL から EVEN に変更することもできます。

以下のチューニングの表に示しているのは、選択した分散スタイルです。

テーブル名 ソートキー 分散スタイル
LINEORDER lo_orderdate lo_partkey
PART p_partkey p_partkey
CUSTOMER c_custkey ALL
SUPPLIER s_suppkey ALL
DWDATE d_datekey ALL

詳細については、「最適な分散スタイルの選択」を参照してください。

次のステップ

ステップ 5: 圧縮エンコードを確認する