AnalyticDB:テーブル分布の定義

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

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

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

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

例：

• ハッシュ配布

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

• ランダム分布は、配列結合または計算ノードのフィルタリングをサポートしていないため、選択しないことを推奨します。

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

配布キーの制限

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

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

  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列に基づいて再配布されると、そのデータはスキューされなくなります。