すべてのプロダクト
Search
ドキュメントセンター

AnalyticDB:テーブル分布の定義

最終更新日:Sep 29, 2024

このトピックでは、AnalyticDB for PostgreSQLでテーブル配布スキームを選択する方法について説明します。

テーブル配布スキームの選択

AnalyticDB for PostgreSQLは、ハッシュ配布、ランダム配布、レプリケート配布の3つのテーブル配布スキームをサポートしています。

CREATE TABLE <table_name> (...) [ DISTRIBUTED BY (<column>  [,..] ) | DISTRIBUTED RANDOMLY | DISTRIBUTED REPLICATED ]
説明

AnalyticDB for PostgreSQL V4.3は、ハッシュ分布とランダム分布のみをサポートします。 レプリケートされたディストリビューションは、AnalyticDB for PostgreSQL V6.0の新機能です。

CREATE TABLEステートメントは、テーブル配布スキームを指定する次の句をサポートしています。

配布スキーム

説明

ハッシュ分布

分割 (列, [ ... ])

データ行は、配布列の値のハッシュ値に基づいて計算ノードに分散されます。 同一のハッシュ値を有する行は、同じ計算ノードに割り当てられる。 データが計算ノード間で均等に分散されるようにするには、主キーなどの一意のキーを配布キーとして使用することをお勧めします。

AnalyticDB for PostgreSQLのデフォルトのテーブル配布スキームはハッシュ配布です。 テーブルを作成するときにDISTRIBUTED句を指定しない場合、テーブルはそのプライマリキー、またはシステムが配布キーとして適切と見なす最初のキーを使用します。 適切な配布キーが識別されない場合、システムはランダム配布を使用する。

ランダム分布

分配されたランダム

データ行は、ラウンドロビンアルゴリズムを使用して、すべての計算ノードに均等に分散されます。 同一のハッシュ値を有する行は、異なる計算ノードに割り当てられてもよい。

ハッシュ分布の実装に適した列がテーブルに含まれていない場合にのみ、ランダム分布を使用することをお勧めします。

複製配布

分布した複製

各計算ノードは、完全なテーブルデータのコピーを格納する。

ユースケースで大きなテーブルが小さなテーブルと頻繁に結合される場合は、小さなテーブルにレプリケートされた配布を指定して、結合パフォーマンスを向上させることができます。

例:

  • ハッシュ配布

    CREATE TABLE products (name varchar(40), 
                           prod_id integer,
                           supplier_id integer)
                           DISTRIBUTED BY (prod_id);                
  • ランダム配布

    CREATE TABLE random_stuff (things text,
                               doodads text,
                               etc text)
                               DISTRIBUTED RANDOMLY;
  • レプリケーション済み配布

    CREATE TABLE replicated_stuff (things text,
                               doodads text,
                               etc text)
                               DISTRIBUTED REPLICATED;

限られた数の配布キーの値に基づいてデータをフィルタリングするクエリの場合、AnalyticDB For PostgreSQLには、値を含む行を格納するノードのみを含めることができます。 たとえば、prod_idを配布キーとして使用するproductsという名前のテーブルのデータをクエリする場合、次のクエリは、prod_idの値が101の行を含む計算ノードにのみ送信されます。 これにより、クエリのパフォーマンスが向上します。

select * from products where prod_id = 101;

配布キーの選択

クエリのパフォーマンスを向上させるには、次のルールに基づいてテーブル配布キーを選択することを推奨します。

  • データが均等に分散される列を選択します。 そうしないと、一部の計算ノードが他の計算ノードよりもはるかに多くのデータを含むデータスキューが発生する可能性があります。 これにより、計算ノードの負荷が高まり、応答時間が長くなります。 したがって、ブール型、時刻型、または日付型の配布列を選択しないことをお勧めします。

  • 値がクエリ条件として頻繁に使用される列を選択します。 これにより、AnalyticDB for PostgreSQLは、クエリリクエストを送信する前に、配布キーに基づいて計算ノードをフィルタリングできます。

  • 配布キーは複数の列に設定できます。 例:

    create table t1(c1 int, c2 int) distributed by (c1,c2);
  • ランダム分布は、配列結合または計算ノードのフィルタリングをサポートしていないため、選択しないことを推奨します。

  • 次の図に示すように、コロケート結合を実装できるように、テーブルの結合に頻繁に使用される分布列を選択します。 結合キーが分配キーと同じである場合、結合は、データ移動なしに関連する計算ノード内で完了することができる。 配布キーがクエリ内の結合キーと異なる場合、システムは、テーブルを結合できるようになる前に、再配布モーションまたはブロードキャストモーションを実行しなければならない。 再配布された参加とブロードキャスト参加の両方が、コロケートされた参加よりもネットワークのオーバーヘッドを引き起こします。

Collocated joinRedistributed joinBroadcast join

配布キーの制限

  • テーブルの配布キーとして定義されている列は更新できません。

  • テーブルの配布キーは、主キーまたは一意のキーの一部である必要があります。 例:

    create table t1(c1 int, c2 int, primary key (c1)) distributed by (c2);
    説明

    この例では、主鍵c1は、配布鍵c2を含まない。 その結果、ステートメントの実行は失敗し、システムは次のエラーを報告します。

    ERROR: PRIMARY KEY and DISTRIBUTED BY definitions incompatible
  • ジオメトリの列またはカスタムデータ型をテーブルの配布キーとして使用することはできません。

データスキューのトラブルシューティング

特定のテーブルでクエリのパフォーマンスが低いことが判明した場合は、不適切な配布キーが指定されているかどうかを確認します。 例:

create table t1(c1 int, c2 int) distributed by (c1);

次の文を実行して、各計算ノードに分散している行数を確認します。

select gp_segment_id,count(1) from  t1 group by 1 order by 2 desc;
 gp_segment_id | count  
---------------+--------
             2 | 131191
             0 |     72
             1 |     68
(3 rows)

一部の計算ノードが他のノードよりも大幅に多くの行を格納する場合、データスキューが存在します。 この場合、配布キーを、データが均等に配布されている列に変更します。 次のALTER TABLE文を実行して、c2列を配布キーとして指定します。

alter table t1 set distributed by (c2);

t1テーブルの配布キーがc2列に変更されます。 t1テーブルがc2列に基づいて再配布されると、そのデータはスキューされなくなります。