メニュー
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. To look for redistribution steps in the query plan, execute an EXPLAIN command followed by the query. This example uses Query 2 from our set of test queries.

    Copy
    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;

    The following shows a portion of the query plan. Look for labels that begin with DS_BCAST or DS_DIST labels

    Copy
    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 indicates that the inner join table was broadcast to every slice. A DS_DIST_BOTH label, if present, would indicate that both the outer join table and the inner join table were redistributed across the slices. Broadcasting and redistribution can be expensive steps in terms of query performance. You want to select distribution strategies that reduce or eliminate broadcast and distribution steps. For more information about evaluating the EXPLAIN plan, see クエリパターンの評価.

  2. Distribute the fact table and one dimension table on their common columns.

    The following diagram shows the relationships between the fact table, LINEORDER, and the dimension tables in the SSB schema.

    Each table can have only one distribution key, which means that only one pair of tables in the schema can be collocated on their common columns. The central fact table is the clear first choice. For the second table in the pair, choose the largest dimension that commonly joins the fact table. In this design, LINEORDER is the fact table, and PART is the largest dimension. PART joins LINEORDER on its primary key, p_partkey.

    Designate lo_partkey as the distribution key for LINEORDER and p_partkey as the distribution key for PART so that the matching values for the joining keys will be collocated on the same slices when the data is loaded.

  3. Change some dimension tables to use ALL distribution.

    If a dimension table cannot be collocated with the fact table or other important joining tables, you can often improve query performance significantly by distributing the entire table to all of the nodes. ALL distribution guarantees that the joining rows will be collocated on every slice. You should weigh all factors before choosing ALL distribution. Using ALL distribution multiplies storage space requirements and increases load times and maintenance operations.

    CUSTOMER, SUPPLIER, and DWDATE also join the LINEORDER table on their primary keys; however, LINEORDER will be collocated with PART, so you will set the remaining tables to use DISTSTYLE ALL. Because the tables are relatively small and are not updated frequently, using ALL distribution will have minimal impact on storage and load times.

  4. Use EVEN distribution for the remaining tables.

    All of the tables have been assigned with DISTKEY or ALL distribution styles, so you won't assign EVEN to any tables. After evaluating your performance results, you might decide to change some tables from ALL to EVEN distribution.

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

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

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

次のステップ

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