このトピックでは、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);
ランダム分布は、配列結合または計算ノードのフィルタリングをサポートしていないため、選択しないことを推奨します。
次の図に示すように、コロケート結合を実装できるように、テーブルの結合に頻繁に使用される分布列を選択します。 結合キーが分配キーと同じである場合、結合は、データ移動なしに関連する計算ノード内で完了することができる。 配布キーがクエリ内の結合キーと異なる場合、システムは、テーブルを結合できるようになる前に、再配布モーションまたはブロードキャストモーションを実行しなければならない。 再配布された参加とブロードキャスト参加の両方が、コロケートされた参加よりもネットワークのオーバーヘッドを引き起こします。
配布キーの制限
テーブルの配布キーとして定義されている列は更新できません。
テーブルの配布キーは、主キーまたは一意のキーの一部である必要があります。 例:
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列に基づいて再配布されると、そのデータはスキューされなくなります。