このトピックでは、 でコロケーション結合機能がどのように実装されているか、およびクエリ最適化のために結合方法を選択する際にこの機能をどのように使用するかについて説明します。 ApsaraDB for SelectDBまた、クエリ最適化のために結合方法を選択する際にこの機能を使用する方法についても説明します。
概要
コロケーション結合機能は、一部の結合クエリに対してローカル最適化を提供し、ノード間のデータ転送時間を短縮し、クエリを高速化します。初期設計、実装、およびパフォーマンスの詳細については、「Issue 245」をご参照ください。コロケーション結合機能は改訂されており、その設計と使用方法は初期設計とは少し異なります。
テーブルのコロケーションプロパティは、クロス クラスタ レプリケーション (CCR) では同期できません。テーブルに is_being_synced = true (テーブルが CCR からコピーされたことを示す)が含まれている場合、コロケーションプロパティはテーブルから削除されます。
用語
コロケーション グループ (CG): 1 つ以上のテーブルが含まれます。同じ CG 内のテーブルは、同じコロケーション グループ スキーマ (CGS) と同じタブレット分散を持ちます。
CGS: CG 内のテーブルと、コロケーションに関連する一般的なスキーマ情報を記述します。 CGS には、バケット列の型とバケット数が含まれます。
しくみ
コロケーション結合機能は、同じ CGS を持つテーブルで構成される CG を形成し、これらのテーブルのタブレットが同じバックエンド (BE) ノードに配置されるようにします。このようにして、CG 内のテーブルがバケット列に基づいて結合されると、ローカル データ結合を実行して、ノード間のデータ転送時間を短縮できます。
テーブルのデータは、バケット列の値に対してハッシュ化を実行し、バケット数に対してモジュロ演算を実行した後、最終的にバケットに分類されます。たとえば、テーブルのバケット数が 8 で、[0, 1, 2, 3, 4, 5, 6, 7] であるとします。このようなシーケンスをバケット シーケンスと呼びます。各バケットには 1 つ以上のタブレットがあります。テーブルが単一パーティション テーブルの場合、バケットには 1 つのタブレットのみが含まれます。テーブルが複数パーティション テーブルの場合、バケットには複数のタブレットが含まれます。
テーブルのデータ分散を同じにするには、CG 内のテーブルのバケット列とバケット数が同じであることを確認する必要があります。バケット列は、テーブル作成ステートメントの DISTRIBUTED BY HASH(col1, col2, ...) で指定された列です。バケット列は、値を使用してテーブルのデータを異なるタブレットにハッシュする列を決定します。 CG 内のテーブルのバケット列の型と数がまったく同じであり、バケット数が同じであることを確認する必要があります。このようにして、複数のテーブルのタブレットを同じ方法で分散できます。
CG 内のテーブルでは、パーティションの数、スコープ、およびパーティション列の型が同じである必要はありません。
バケット列とバケット数が決定されると、CG 内のテーブルは同じバケット シーケンスを持ちます。たとえば、バケット シーケンスが [0, 1, 2, 3, 4, 5, 6, 7] で、BE ノードが [A, B, C, D] であるとします。次の図は、考えられるデータ分散を示しています。
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| 0 | | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | | 7 |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| A | | B | | C | | D | | A | | B | | C | | D |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+CG 内のすべてのテーブルのデータは、上記のルールに基づいて分散されます。これにより、同じバケット列の値を持つデータが、ローカル データ結合のために同じ BE ノードに配置されます。
基本的な使い方
テーブルの作成
テーブルを作成するときに、PROPERTIES に "colocate_with" = "group_name" を指定できます。これは、テーブルがコロケーション テーブルであり、指定された CG に属していることを示します。
例:
CREATE TABLE tbl (k1 int, v1 int sum)
DISTRIBUTED BY HASH(k1)
BUCKETS 8
PROPERTIES(
"colocate_with" = "group1"
);指定された CG が存在しない場合、ApsaraDB for SelectDB は現在のテーブルのみを含む CG を自動的に作成します。 CG が既に存在する場合、ApsaraDB for SelectDB は現在のテーブルが CGS 要件を満たしているかどうかを確認します。満たしている場合、テーブルが作成され、CG に追加されます。さらに、CG の既存のデータ分散ルールに基づいて、テーブルのタブレットとレプリカが作成されます。 CG はデータベースに属し、CG の名前はデータベース内で一意です。内部的には、CG は dbId_groupName 形式のフルネームで格納されます。ただし、ユーザーには groupName のみが認識されます。
ApsaraDB for SelectDB はデータベース間の CG をサポートしています。テーブルを作成するときに、CG 名に __global__ プレフィックスを追加して、グローバル CG を指定できます。例:
CREATE TABLE tbl (k1 int, v1 int sum)
DISTRIBUTED BY HASH(k1)
BUCKETS 8
PROPERTIES(
"colocate_with" = "__global__group1"
);__global__ プレフィックスが付いた CG はデータベースに属さなくなり、名前はグローバルに一意になります。グローバル CG を作成することで、データベース間のコロケーション結合を実装できます。
テーブルの削除
永続的な削除とは、テーブルがごみ箱から削除されることを意味します。一般に、DROP TABLE ステートメントを実行してテーブルを削除した後、テーブルはごみ箱に移動され、1 日間そこに留まり、その後永続的に削除されます。 CG 内の最後のテーブルが永続的に削除されると、CG は自動的に削除されます。
テーブルのクエリ
コロケーション テーブルは、通常のテーブルと同じ方法でクエリできます。テーブルのコロケーション プロパティはユーザーには認識されません。システムは、コロケーション結合を使用するクエリ プランを自動的に生成します。次の例は、コロケーション テーブルをクエリする方法を示しています。
テーブルを作成します。
tbl1 テーブルを作成します。
CREATE TABLE `tbl1` ( `k1` date NOT NULL COMMENT "", `k2` int(11) NOT NULL COMMENT "", `v1` int(11) SUM NOT NULL COMMENT "" ) ENGINE=OLAP AGGREGATE KEY(`k1`, `k2`) PARTITION BY RANGE(`k1`) ( PARTITION p1 VALUES LESS THAN ('2019-05-31'), PARTITION p2 VALUES LESS THAN ('2019-06-30') ) DISTRIBUTED BY HASH(`k2`) BUCKETS 8 PROPERTIES ( "colocate_with" = "group1" );tbl2 テーブルを作成します。
CREATE TABLE `tbl2` ( `k1` datetime NOT NULL COMMENT "", `k2` int(11) NOT NULL COMMENT "", `v1` double SUM NOT NULL COMMENT "" ) ENGINE=OLAP AGGREGATE KEY(`k1`, `k2`) DISTRIBUTED BY HASH(`k2`) BUCKETS 8 PROPERTIES ( "colocate_with" = "group1" );テーブルが結合されているクエリのクエリ プランを表示します。
DESC SELECT * FROM tbl1 INNER JOIN tbl2 ON (tbl1.k2 = tbl2.k2); +----------------------------------------------------+ | Explain String | +----------------------------------------------------+ | PLAN FRAGMENT 0 | | OUTPUT EXPRS:`tbl1`.`k1` | | | PARTITION: RANDOM | | | | RESULT SINK | | | | 2:HASH JOIN | | | join op: INNER JOIN | | | hash predicates: | | | colocate: true | | | `tbl1`.`k2` = `tbl2`.`k2` | | | tuple ids: 0 1 | | | | | |----1:OlapScanNode | | | TABLE: tbl2 | | | PREAGGREGATION: OFF. Reason: null | | | partitions=0/1 | | | rollup: null | | | buckets=0/0 | | | cardinality=-1 | | | avgRowSize=0.0 | | | numNodes=0 | | | tuple ids: 1 | | | | | 0:OlapScanNode | | TABLE: tbl1 | | PREAGGREGATION: OFF. Reason: No AggregateInfo | | partitions=0/2 | | rollup: null | | buckets=0/0 | | cardinality=-1 | | avgRowSize=0.0 | | numNodes=0 | | tuple ids: 0 | +----------------------------------------------------+コロケーション結合が有効な場合、HASH JOIN ノードには
colocate: trueが含まれます。次の例は、コロケーション結合が有効でないクエリ プランを示しています。
+----------------------------------------------------+ | Explain String | +----------------------------------------------------+ | PLAN FRAGMENT 0 | | OUTPUT EXPRS:`tbl1`.`k1` | | | PARTITION: RANDOM | | | | RESULT SINK | | | | 2:HASH JOIN | | | join op: INNER JOIN (BROADCAST) | | | hash predicates: | | | colocate: false, reason: group is not stable | | | `tbl1`.`k2` = `tbl2`.`k2` | | | tuple ids: 0 1 | | | | | |----3:EXCHANGE | | | tuple ids: 1 | | | | | 0:OlapScanNode | | TABLE: tbl1 | | PREAGGREGATION: OFF. Reason: No AggregateInfo | | partitions=0/2 | | rollup: null | | buckets=0/0 | | cardinality=-1 | | avgRowSize=0.0 | | numNodes=0 | | tuple ids: 0 | | | | PLAN FRAGMENT 1 | | OUTPUT EXPRS: | | PARTITION: RANDOM | | | | STREAM DATA SINK | | EXCHANGE ID: 03 | | UNPARTITIONED | | | | 1:OlapScanNode | | TABLE: tbl2 | | PREAGGREGATION: OFF. Reason: null | | partitions=0/1 | | rollup: null | | buckets=0/0 | | cardinality=-1 | | avgRowSize=0.0 | | numNodes=0 | | tuple ids: 1 | +----------------------------------------------------+HASH JOIN ノードには、コロケーション結合が有効でない理由が含まれています:
colocate: false, reason: group is not stable。EXCHANGE ノードも生成されます。
CG 情報の表示
クラスタに存在する CG に関する情報を表示できます。例:
SHOW PROC '/colocation_group';
+-------------+--------------+--------------+------------+----------------+----------+----------+
| GroupId | GroupName | TableIds | BucketsNum | ReplicationNum | DistCols | IsStable |
+-------------+--------------+--------------+------------+----------------+----------+----------+
| 10005.10008 | 10005_group1 | 10007, 10040 | 10 | 3 | int(11) | true |
+-------------+--------------+--------------+------------+----------------+----------+----------+次の表は、パラメータについて説明しています。
パラメータ | 説明 |
GroupId | クラスタ全体で一意の CG の識別子。前半はデータベース ID、後半は CG ID です。 |
GroupName | CG のフルネーム。 |
TabletIds | CG 内のテーブルの ID。 |
BucketsNum | バケット数。 |
ReplicationNum | レプリカの数。 |
DistCols | バケット列の型。 |
IsStable | CG が安定しているかどうかを示します。安定性の定義については、このトピックの「 |
CG のデータ分散を表示します。例:
SHOW PROC '/colocation_group/10005.10008';
+-------------+---------------------+
| BucketIndex | BackendIds |
+-------------+---------------------+
| 0 | 10004 |
| 1 | 10003 |
| 2 | 10002 |
| 3 | 10003 |
| 4 | 10002 |
| 5 | 10003 |
| 6 | 10003 |
| 7 | 10003 |
+-------------+---------------------+パラメータ | 説明 |
BucketIndex | バケットのインデックス。 |
BackendIds | バケット内のタブレットが存在する BE ノードの ID。 |
上記のコマンドを実行するには、管理者ロールの権限が必要です。通常のユーザーはこれらのコマンドを実行できません。
テーブルのコロケーション プロパティの変更
既存のテーブルのコロケーション プロパティを変更できます。例:
ALTER TABLE tbl SET ("colocate_with" = "group2");テーブルが CG に追加されていない場合、システムはスキーマを確認し、テーブルを指定された CG に追加します。 CG が存在しない場合、システムは自動的に CG を作成します。
テーブルが CG に既に追加されている場合、システムは元の CG からテーブルを削除し、指定された CG にテーブルを追加します。 CG が存在しない場合、システムは自動的に CG を作成します。
次のステートメントを実行して、テーブルのコロケーション プロパティを削除することもできます。
ALTER TABLE tbl SET ("colocate_with" = "");その他の操作
ADD PARTITION ステートメントを実行してコロケーション テーブルにパーティションを追加したり、レプリカの数を変更したりすると、ApsaraDB for SelectDB は変更が CGS に違反していないかどうかを確認します。違反している場合、ApsaraDB for SelectDB は変更を拒否します。
高度な使い方
FE 構成項目
disable_colocate_relocateApsaraDB for SelectDB でコロケーション レプリカの自動修復を無効にするかどうかを指定します。デフォルト値は false で、この機能が有効になっていることを示します。このパラメータは、通常のテーブルではなく、コロケーション テーブルのレプリカ修復にのみ影響します。
disable_colocate_balanceApsaraDB for SelectDB でコロケーション レプリカの自動バランス調整を無効にするかどうかを指定します。デフォルト値は false で、この機能が有効になっていることを示します。この構成項目は、通常のテーブルではなく、コロケーション テーブルのレプリカ バランス調整にのみ影響します。
上記の構成項目を動的に変更できます。これらの構成項目の設定方法の詳細については、HELP ADMIN SHOW CONFIG; および HELP ADMIN SET CONFIG; ステートメントを実行してください。
disable_colocate_joinコロケーション結合機能を無効にするかどうかを指定します。デフォルト値は false で、この機能が有効になっていることを示します。
use_new_tablet_scheduler新しいレプリカ スケジューリング ロジックを有効にするかどうかを指定します。デフォルト値は true で、このロジックが有効になっていることを示します。
HTTP RESTful API
ApsaraDB for SelectDB は、CG の表示と変更に使用できる、コロケーション結合関連の HTTP RESTful API 操作をいくつか提供しています。
これらの API 操作は FE ノードで実装されており、fe_host:fe_http_port にリクエストを送信することで呼び出すことができます。管理者ロールの権限が必要です。
クラスタのすべてのコロケーション情報を表示します。例:
GET /api/colocate JSON 形式で内部コロケーション情報を返します。 { "msg": "success", "code": 0, "data": { "infos": [ ["10003.12002", "10003_group1", "10037, 10043", "1", "1", "int(11)", "true"] ], "unstableGroupIds": [], "allGroupIds": [{ "dbId": 10003, "grpId": 12002 }] }, "count": 0 }CG を Stable または Unstable としてマークします。例:
CG を Stable としてマークします。
DELETE /api/colocate/group_stable?db_id=10005&group_id=10008 戻り値: 200CG を Unstable としてマークします。
POST /api/colocate/group_stable?db_id=10005&group_id=10008 戻り値: 200
CG のデータ分散を設定します。
この API 操作を呼び出して、CG のデータ分散を強制的に設定できます。返された結果では、Body フィールドには、ネストされた配列で表されるバケット シーケンスと、バケット内のタブレットが存在する BE ノードの ID が含まれています。
POST /api/colocate/bucketseq?db_id=10005&group_id=10008 Body: [[10004],[10003],[10002],[10003],[10002],[10003],[10003],[10003],[10003],[10002]] 戻り値: 200説明このコマンドを使用するには、FE 構成項目
disable_colocate_relocateとdisable_colocate_balanceを true に設定する必要があります。これにより、システムのコロケーション レプリカの自動修復とバランス調整が無効になります。そうでない場合、手動変更後、コロケーション レプリカはシステムによって自動的に修復およびバランス調整されます。
コロケーション レプリカのバランス調整と修復
コロケーション テーブルのレプリカ分散は、CGS で指定された分散ルールに従う必要があります。したがって、コロケーション レプリカのバランス調整と修復は、通常のタブレットの場合とは異なります。
CG には Stable プロパティがあります。 Stable プロパティの値が true の場合、CG 内のテーブルのすべてのタブレットは変更されておらず、コロケーション結合機能を使用できます。 Stable プロパティの値が false の場合、CG 内の一部のテーブルのタブレットは修復または移行中です。この場合、影響を受けるテーブルのコロケーション結合は通常の結合にダウングレードされます。
レプリカの修復
レプリカは、指定された BE ノードにのみ格納できます。 BE ノードがダウンしているか、廃止されている場合、BE ノードは使用できません。この場合、BE ノードを別の BE ノードに置き換える必要があります。 ApsaraDB for SelectDB は、使用できない BE ノードを置き換えるために、負荷が最も低い BE ノードを探します。交換後、元の BE ノードのすべてのタブレットを修復する必要があります。移行中、CG は Unstable としてマークされます。
レプリカのバランス調整
ApsaraDB for SelectDB は、コロケーション テーブルのテーブルをすべての BE ノードに均等に分散します。通常のテーブルのレプリカは、レプリカ レベルでバランス調整されます。この場合、負荷が低い BE ノードは、レプリカごとに個別に検出されます。ただし、コロケーション テーブルのレプリカはバケット レベルでバランス調整されます。この場合、バケット内のすべてのレプリカが一緒に移行されます。
ApsaraDB for SelectDB は、単純なバランス調整アルゴリズムを使用します。このアルゴリズムは、レプリカの実際のサイズではなく、レプリカの数に基づいて、バケット シーケンスをすべての BE ノードに均等に分散します。
現在のコロケーション レプリカのバランス調整および修復アルゴリズムは、異種デプロイメントを使用する ApsaraDB for SelectDB インスタンスではうまく機能しない場合があります。異種デプロイメントとは、BE ノードのディスク容量、ディスク数、またはディスクの種類が同じではないことを示します。ディスクの種類には、SSD と HDD が含まれます。異種デプロイメントの場合、小容量 BE ノードと大容量 BE ノードが同じ数のレプリカを格納する場合があります。
CG が Unstable 状態の場合、CG 内のテーブルの結合は通常の結合にダウングレードされます。この場合、クラスタのクエリ パフォーマンスが大幅に低下する可能性があります。システムがレプリカを自動的にバランス調整しないようにするには、FE 構成項目
disable_colocate_balanceを true に設定して自動バランス調整を無効にします。後で自動バランス調整が必要な場合は、構成項目を手動で false に設定できます。