テナント内のロードバランシング

OceanBaseデータベースV3.xバージョンでは、レプリカはパーティション単位で複数ノードに分散配置されており、ロードバランシングモジュールはパーティションのリーダー切り替えやパーティションレプリカの移行などによってテナント内のパーティションロードバランシングを実現します。V4.xバージョンでは単一マシンログストリームアーキテクチャへとアップグレードされたことにより、レプリカはログストリーム単位で分散配置され、各ログストリームが多数のパーティションを担います。そのため、V4.2.xバージョンでは、ロードバランシングモジュールは直接パーティションの分散を制御することができず、まずLS（Log Stream、ログストリーム）の数とリーダーを均等化し、その後にログストリームの分散を基盤としてパーティションのロードバランシングを行う必要があります。

LSの均等化とパーティションのロードバランシングの優先順位は以下のとおりです：

LSの均等化 > パーティションのロードバランシング

LSの均衡（同種ゾーンモード）

LS数の均衡

ユーザーがテナントに対してUNIT_NUMの変更、PRIMARY_ZONEの第一優先ゾーンの変更、ローカリティの変更（PRIMARY_ZONEに影響）などの操作を実行すると、ロードバランシングモジュールのバックグラウンドスレッドは、LSの分割、LSの統合、LSグループの変更などの処理を即座に行い、LSの数と配置を変更します。これにより、ユーザーが変更した後のテナント状態、すなわち各テナントのUnitには1つのログストリームグループがあり、ログストリームグループ内のログストリームの数はPRIMARY_ZONEの第一優先ゾーンの数に等しく、リーダーがログストリームグループ内の各ゾーンに均等に分散される状態が保たれます。

同種ゾーンモードにおけるLS数の計算式は以下の通りです：

LS数 = UNIT_NUM * first_level_primary_zone_num

LS数の均衡が必要なシナリオは以下の表の通りです。

例1：以下の図のように、PRIMARY_ZONEの第一優先ゾーンがZ1, Z2からZ1に変更され、同時にUNIT_NUMが1から2に変更される必要があります。変更前後でLS数は変わらないため、LS2を新しく作成されたUnitに直接移行します。LS2はPRIMARY_ZONEの変更に伴いリーダーをZ1に切り替え、最終的にLS均衡が完了します。

例2：以下の図のように、PRIMARY_ZONE = Z1、UNIT_NUMが1から2に変更される際、各UnitにLSが存在するようにするため、LS2を分割して1/2のTabletを持ち出し、新しいUnitに移行します。

例3：以下の図のように、UNIT_NUM = 1、PRIMARY_ZONEの第一優先ゾーンがRANDOMからZ1,Z2に変更されます。リーダーがPRIMARY_ZONEの第一優先ゾーン上にのみ存在することを保証するため、均衡後のログストリーム上のTablet数も均衡させる必要があります。LS3が他のLSと同じLSグループにあるため、LS3から1/2のTabletをLS1に転送し、その後LS3をLS2に統合して、LS2に残りの1/2のTabletを負荷させることで、LS数を減らしつつTablet数の均衡を保つことができます。

LSリーダーの均衡

LSリーダーの均衡とは、LS数が均衡している前提の下で、LSリーダーをプライマリゾーン上に均等に分散させることです。例えば、ユーザーがテナントのPRIMARY_ZONEを変更した後、ロードバランシングのバックグラウンドスレッドはPRIMARY_ZONEの第一優先ゾーンに基づいてLS数を動的に調整し、その後LSのリーダー切り替えを行います。これにより、第一優先ゾーンの各ゾーンには必ず1つのLSリーダーが存在することが保証されます。

LSリーダーの自動均衡は、テナントレベルの構成パラメータenable_ls_leader_balanceによって制御され、デフォルトでは有効になっています。

例1：以下の図に示すように、UNIT_NUM = 1 の場合、PRIMARY_ZONE の第一優先順位が Z1 から Z1,Z2 に変更されます。PRIMARY_ZONE の第一優先順位を持つすべてのゾーンにリーダーが存在することを保証するために、同一ユニット内で新しいLSが分裂し、その後LSリーダーの均等化により新しいLSのリーダーが Z2 に切り替えられます。

例2：以下の図に示すように、UNIT_NUM = 1 の場合、PRIMARY_ZONE の第一優先順位が RANDOM から Z1,Z2 に変更されると、LS数の均等化により LS3 が他のLSに統合された後、残りのLSリーダーは自然に Z1 と Z2 に均等に分散します。追加のLSリーダー均等化は不要です。

LS バランシング（異種ゾーンモード）

現在のバージョンでは、OceanBaseデータベースはテナントの異種ゾーンモードもサポートしています。異種ゾーンモードでは、テナント内の各ゾーンのUnit数を異なる設定できますが、1つのテナントで使用できる UNIT_NUM の種類は最大2種類に制限されます。

異種ゾーンモードでは、ロードバランシングアルゴリズムがUnit単位で各ログストリームの分散を制御します。

• テナントの各ゾーン内では、各Unit上のログストリーム数が等しくなります。

• UNIT_NUM が同じゾーン内では、ログストリームは同種の方法で集約されます。

異種ゾーンモードでは、LS数の計算式は以下のとおりです：

LS数 = (テナントのすべてのUNIT_NUMの最小公倍数) * first_level_primary_zone_num

テーブル作成時のパーティションの割り当て

ユーザーがユーザーテーブルを作成する際、OceanBaseデータベースは一連の均等分散戦略を用いてパーティションを各ユーザーログストリームに分散または集約し、各ログストリーム上のパーティションの相対的な均衡を保証します。

Table Groupを指定するユーザーテーブル

ユーザーはTable Groupを指定することで、異なるテーブル間の集約・分散ルールを柔軟に設定できます。ユーザーテーブル作成時に、対応するSharding属性とSCOPE属性（V4.4.2 BP1以降のバージョンはテーブルグループのSCOPE属性をサポート）を持つTable Groupを指定した場合、新規ユーザーテーブルのパーティションはTable Groupのルールに従って対応するユーザーのLS上に割り当てられます。Table Groupのルールは以下の表のとおりです。

• V4.4.2 BP1（含まず）以前のバージョン

• V4.4.2 BP1以降のバージョン

  SHARDING / SCOPE属性値	SERVER	ZONE	CLUSTER
  NONE	テーブルグループ内のすべてのパーティションが同一ノード上に集約される（パーティション分散方式はSCOPE属性がサポートする以前のバージョンのSHARDING = NONEと同等）	テーブルグループ内のすべてのパーティションが特定のZone内で均等に分散される	テーブルグループ内のすべてのパーティションが各ノードに均等に分散される
  PARTITION	サポートされていない	現在はサポートされていない	パーティション単位で集約され、各パーティショングループがランダムに分散される。（パーティション分散方式はSCOPE属性がサポートする以前のバージョンのSHARDING = PARTITIONと同等）
  ADAPTIVE	サポートされていない	現在はサポートされていない	パーティションテーブル：パーティション単位で集約され、各パーティショングループがクラスタ全体に分散される。 サブパーティションテーブル：各パーティション単位でサブパーティションが集約され、各パーティショングループがクラスタ全体に集約される。 パーティション分散方式はSCOPE属性がサポートする以前のバージョンのSHARDING = ADAPTIVEと同等である。

Table Groupの詳細については、テーブルグループについてを参照してください。

通常のユーザーテーブル

Table Groupを指定せずに通常のユーザーテーブルを作成する場合、OceanBaseデータベースは新規パーティションをすべてのユーザーLS上に分散するデフォルト設定となります。具体的なルールは以下のとおりです。

• 非パーティションテーブル：新規パーティションは、パーティション数が最も少ないユーザーLSに割り当てられる。

• パーティションテーブル：パーティションテーブル：パーティションはRound Robinアルゴリズムにより、すべてのユーザーLS上に均等に分散される。

• サブパーティションテーブル：サブパーティションテーブル：各パーティション単位のすべてのサブパーティションは、Round Robinアルゴリズムにより、すべてのユーザーLS上に均等に分散される。

以下の例をいくつか挙げて説明します。

• 例1：MySQLモードで、それぞれtt1、tt2、tt3、tt4の4つの非パーティションテーブルを作成します。

  obclient [test]> CREATE TABLE tt1(c1 int);
  

  obclient [test]> CREATE TABLE tt2(c1 int);
  

  obclient [test]> CREATE TABLE tt3(c1 int);
  

  obclient [test]> CREATE TABLE tt4(c1 int);
  

  4つのテーブルのパーティション分布状況を照会します。

  obclient [test]> SELECT table_name,partition_name,subpartition_name,ls_id,zone FROM oceanbase.DBA_OB_TABLE_LOCATIONS WHERE table_name in('tt1','tt2','tt3','tt4') AND role='LEADER';
  

  クエリ結果は次のとおりです。

  +------------+----------------+-------------------+-------+------+
  | table_name | partition_name | subpartition_name | ls_id | zone |
  +------------+----------------+-------------------+-------+------+
  | tt1        | NULL           | NULL              |  1001 | z1   |
  | tt2        | NULL           | NULL              |  1002 | z2   |
  | tt3        | NULL           | NULL              |  1003 | z3   |
  | tt4        | NULL           | NULL              |  1001 | z1   |
  +------------+----------------+-------------------+-------+------+
  4 rows in set
  

• 例2：さらにパーティションテーブル tt5 を作成します。

  obclient [test]> CREATE TABLE tt5(c1 int) PARTITION BY HASH(c1) PARTITIONS 6;
  

  このパーティションテーブルの分布状況を確認します。

  obclient [test]> SELECT table_name,partition_name,subpartition_name,ls_id,zone FROM oceanbase.DBA_OB_TABLE_LOCATIONS WHERE table_name ='tt5' AND role='LEADER';
  

  クエリ結果は次のとおりです。このテーブルのパーティションは、Round Robinアルゴリズムにより、1001、1002、1003 などのログストリームに均等に分散されています。

  +------------+----------------+-------------------+-------+------+
  | table_name | partition_name | subpartition_name | ls_id | zone |
  +------------+----------------+-------------------+-------+------+
  | tt5        | p0             | NULL              |  1003 | z3   |
  | tt5        | p1             | NULL              |  1001 | z1   |
  | tt5        | p2             | NULL              |  1002 | z2   |
  | tt5        | p3             | NULL              |  1003 | z3   |
  | tt5        | p4             | NULL              |  1001 | z1   |
  | tt5        | p5             | NULL              |  1002 | z2   |
  +------------+----------------+-------------------+-------+------+
  6 rows in set
  

• 例3：サブパーティションテーブル tt8 を作成します。

  obclient [test]> CREATE TABLE tt8 (c1 int, c2 int, PRIMARY KEY(c1, c2)) 
      PARTITION BY HASH(c1) SUBPARTITION BY RANGE(c2) SUBPARTITION TEMPLATE 
      (SUBPARTITION p0 VALUES LESS THAN (1990), 
       SUBPARTITION p1 VALUES LESS THAN (2000),
       SUBPARTITION p2 VALUES LESS THAN (3000),
       SUBPARTITION p3 VALUES LESS THAN (4000),
       SUBPARTITION p4 VALUES LESS THAN (5000),
       SUBPARTITION p5 VALUES LESS THAN (MAXVALUE)) 
       PARTITIONS 2;
  

  テーブル tt8 のパーティション分布状況を確認します。

  obclient [test]> SELECT table_name,partition_name,subpartition_name,ls_id,zone FROM oceanbase.DBA_OB_TABLE_LOCATIONS WHERE table_name ='tt8' AND role='LEADER';
  

  クエリ結果は次のとおりです。このテーブルの次のレベルのすべてのサブパーティションは、Round Robinアルゴリズムにより、ユーザーのすべてのLSに均等に分散されています。

  +------------+----------------+-------------------+-------+------+
  | table_name | partition_name | subpartition_name | ls_id | zone |
  +------------+----------------+-------------------+-------+------+
  | tt8        | p0             | p0sp0             |  1001 | z1   |
  | tt8        | p0             | p0sp1             |  1002 | z2   |
  | tt8        | p0             | p0sp2             |  1003 | z3   |
  | tt8        | p0             | p0sp3             |  1001 | z1   |
  | tt8        | p0             | p0sp4             |  1002 | z2   |
  | tt8        | p0             | p0sp5             |  1003 | z3   |
  | tt8        | p1             | p1sp0             |  1002 | z2   |
  | tt8        | p1             | p1sp1             |  1003 | z3   |
  | tt8        | p1             | p1sp2             |  1001 | z1   |
  | tt8        | p1             | p1sp3             |  1002 | z2   |
  | tt8        | p1             | p1sp4             |  1003 | z3   |
  | tt8        | p1             | p1sp5             |  1001 | z1   |
  +------------+----------------+-------------------+-------+------+
  12 rows in set
  

特殊ユーザーテーブル

通常のユーザーテーブル以外に、ローカルインデックステーブル、グローバルインデックステーブル、レプリケーションテーブルといった特殊なユーザーテーブルがあり、それぞれ特別な割り当てルールを持っています。具体的には以下のとおりです：

• ローカルインデックステーブル：ユーザーテーブルのメインテーブルと同じパーティションルールを持ち、各パーティションはメインテーブルのパーティション分布に紐づけられます。

• グローバルインデックステーブル：デフォルトでは非パーティションテーブルであり、作成時にパーティション数が最も少ないユーザーLSに配置されます。

• レプリケーションテーブル：レプリケーションテーブルはブロードキャストログストリーム上にのみ存在します。

パーティションの均衡

LS均衡の基礎の上で、ロードバランシングモジュールはTransferを通じてパーティションTabletを異なるLSに分散または集約し、テナント内のパーティション均衡を実現します。パーティション均衡タスクSCHEDULED_TRIGGER_PARTITION_BALANCEはDBMS_BALANCE.TRIGGER_PARTITION_BALANCEサブプログラムによって制御され、デフォルトでは毎日00:00に一度パーティション均衡が実行されます。パーティション均衡に関する操作の詳細については、定期パーティション均衡タスクの設定を参照してください。

パーティション均衡戦略の優先順位は以下のとおりです：

パーティション属性の整合性 > テーブルグループとパーティションの重み均衡 > パーティション数の均衡 > パーティションディスクの均衡

パーティション属性の整合性

Table Groupの整合性

ユーザーがSQLステートメントを使用してテーブルのTable Group属性、Table GroupのSharding属性、またはSCOPE属性を変更する場合（V4.4.2 BP1以降のバージョンではテーブルグループのSCOPE属性をサポート）、期待されるパーティション分散を実現するには、バックグラウンドで実行されているパーティション均衡タスクの完了を待つ必要があります。手動でDBMS_BALANCE.TRIGGER_PARTITION_BALANCEサブプログラムを呼び出すことで、パーティション均衡をトリガーし、迅速に整合性を取ることができます。

Table Group内のテーブルのパーティション分散ルールについては、本記事のTable Groupを指定したユーザーテーブルの内容を参照してください。

Table Groupの詳細については、Table Groupについてを参照してください。

duplicate_scopeの整合性

OceanBaseデータベースの現在のバージョンでは、レプリケーションテーブルの属性変更をサポートしています。レプリケーションテーブルはブロードキャストログストリーム上にのみ存在できます。ユーザーがduplicate_scope属性を変更した後、期待された属性で使用するには、パーティション均衡の実行完了を待つ必要があります。手動でDBMS_BALANCE.TRIGGER_PARTITION_BALANCEサブプログラムを呼び出すことで、パーティション均衡をトリガーし、迅速に整合性を取ることができます。

レプリケーションテーブル属性変更の詳細な操作については、レプリケーションテーブル属性の変更（MySQLモード）およびレプリケーションテーブル属性の変更（Oracleモード）を参照してください。

Table Groupの重み均衡

OceanBaseデータベースのMySQLモードでは、DatabaseをSharding = 'NONE'のTable Groupにバインドすることで、ユーザーテーブルの集約を実現します。現在、同一Database内のユーザーテーブルの自動集約および複数Database間のユーザーテーブル集約をサポートしています。

Sharding = 'NONE'のTable Groupに重みを設定することでTable Groupの重み均衡を実現し、そのグループ内のテーブルを重みに応じて分散配置できます。

Table Groupの重み均衡は、パーティション均衡(PARTITION_BALANCE)タスクの一つのプロセスであり、ユーザーテナントは手動でトリガーするか、定期的なパーティション均衡タスクの実行を待つことができます。

パーティションの重み均等化（非テーブルグループ）

パーティションの重みとは、ユーザーが設定するCPU、メモリ、ディスクなどのリソースを各パーティションが占有する相対的な割合です。整数値のみをサポートし、取り得る範囲は[1, +∞)です。デフォルトでは、パーティションには重みが設定されていません。

非テーブルグループのパーティション重み均等化は、パーティション均等化タスクのプロセスの一つです。ユーザーがテーブルにパーティションの重みを設定した後、手動でパーティション均等化タスクを実行するか、定期的なパーティション均等化タスクの実行を待機することで実現できます。パーティション重み均等化アルゴリズムは、パーティションの移動と交換により、各ユーザーログストリーム上のパーティションの重みの合計の分散を可能な限り小さくします。

パーティションの重みが設定されているテーブルのみがパーティション重み均等化に参加します。テーブル内でパーティションの重みが設定されていないパーティションについては、引き続きパーティション数に応じて均等化されます。

パーティション重み均等化の適用

非テーブルグループのパーティション重みは主にパーティションのホットスポット分散に適用され、主に以下の2つのシナリオをサポートします：

• パーティションテーブル内のホットスポットパーティションの分散

• 非パーティションテーブル間のパーティションホットスポットの分散

パーティションの重みを設定する際は、最大で3段階に分けることを推奨します：

• 大重み = 100% * パーティション数

• 中重み = 50% * パーティション数

• 小重み = 1

以下では、いくつかの適用シナリオの例を通じて、パーティション重み均等化の適用方法を紹介します。

パーティションテーブル内のホットスポットパーティションの分散

例えば、パーティションテーブル t1 があり、テーブルには合計6個のパーティションがあると仮定します。テーブル作成後のパーティションの分布は以下のとおりです。

以下の適用シナリオがあります：

• 適用シナリオ1：少数のホットスポットの分散

  パーティションテーブル t1 内でホットスポットである p0 と p3 の2つのパーティションのみを分散させる必要がある場合、重みの段階が最も少ない原則に基づき、「小重み = 1」という1つの重み段階のみを使用して解決できます。

  パーティションの重みを p0 = 1、p3 = 1 に設定します。パーティション均等化の計算時には、この2つのパーティションのみが対象となり、残りのパーティションは重み均等化には参加せず、引き続きパーティション数に応じて均等化され、可能な限り動かされません。パーティション均等化（手動でのトリガーまたは定期的な均等化の待機）後の全体的なパーティションの分布は以下のとおりです。

• 適用シナリオ2：すべてのパーティションを重みに従って分布

  一次パーティションテーブル t1 において、パーティション p0 のトラフィックが最も多く、p1、p2、p3 がそれに続き、その他のパーティションのトラフィックは少ないと仮定します。トラフィックを分散させたい場合、以下の3段階の重みを使用できます：

  • 大重み = 100% × 一次パーティションテーブルのパーティション数 = 6

  • 中重み = 50% × 一次パーティションテーブルのパーティション数 = 3

  • 小重み = 1

  まず、テーブルレベルのパーティション重みを1に設定し、重みによるパーティション均等化の範囲をテーブル全体とします。次に、個々のパーティションの重みを p0 = 6、p1 = 3、p2 = 3、p3 = 3 と個別に設定します。パーティション均等化後の全体的なパーティション分布は以下のとおりです。

• 適用シナリオ3：ホットスポットパーティションの均等化とグループ内での専有化

  一次パーティションテーブル t1 の6つのパーティション間でトラフィックが極めて不均衡であり、p0 と p3 の2つの超大規模パーティションが存在すると仮定します。この場合、テーブル内の他のパーティションがこれら2つの超大規模パーティションの読み書きに影響を与えないようにしたいと考えています。以下の2段階の重みを使用できます：

  • 大重み = 100% × 一次パーティションテーブルのパーティション数 = 6

  • 小重み = 1

  まず、テーブルレベルのパーティション重みを1に設定し、重みによるパーティション均等化の範囲をテーブル全体とします。次に、個々のパーティションの重みを p0 = 6、p3 = 6 と個別に設定します。パーティション均等化後の全体的なパーティション分布は以下のとおりです。

非パーティションテーブルのホットスポット分散

例えば、以下の6つの非パーティションテーブルがあり、テーブル作成後の分布が以下のようになっているとします。

以下の適用シナリオがあります：

• 適用シナリオ1：少数のホットスポットの分散

  非パーティションテーブル non_part_t1 と non_part_t4 が同一のログストリーム上の2つのホットスポットであり、分散が必要であると仮定します。重みの段階が最も少ない原則に基づき、「小重み = 1」という1つの重み段階のみを使用して解決できます。

  非パーティションテーブルのテーブルレベル重みを non_part_t1 = 1、non_part_t4 = 1 に設定します。パーティション均等化後の分布は以下のとおりです。

• 適用シナリオ2：トラフィック分布に応じた分散

  各非パーティションテーブルのトラフィックが既知であり、non_part_t1 が最も多く、non_part_t2、non_part_t3 がそれに続き、non_part_t4、non_part_t5、non_part_t6 が最も少ないと仮定します。トラフィックに応じて分散させたいと考えています。以下の3段階のトラフィックを使用できます：

  • 大重み = 100% × 一次パーティションテーブルのパーティション数 = 6

  • 中重み = 50% × 一次パーティションテーブルのパーティション数 = 3

  • 小重み = 1

  対応するテーブルのテーブルレベルパーティションの重みを non_part_t1 = 6、non_part_t2 = 3、non_part_t3 = 3、non_part_t4 = 1、non_part_t5 = 1、non_part_t6 = 1 に設定した後、パーティションの均衡処理を行った結果、分布は以下のようになります。

パーティションの重みがテーブルグループに与える影響

パーティションの重みを持つテーブルはテーブルグループに追加できます。テーブルグループにおいて、パーティションの重みを持つテーブルが存在する場合、パーティションの均衡処理はパーティショングループ内の加重合計に基づいて分布を計算します。パーティションの重みを持つテーブルをテーブルグループに追加した後の具体的な影響は、次の表のとおりです。

• V4.4.2 BP1（含まれない）以前のバージョン

  テーブルグループの SHARDING プロパティ	元のパーティション分布方式	パーティションの重みを設定した後の影響
  NONE	全部が一つのグループに集約される	影響なし
  PARTITION	各テーブルのパーティション内で値が同じパーティションが集約される（同一のパーティショングループ内）。パーティション間は分散される。	数個の重み付けされたパーティションがテーブルグループ全体の分布に影響を与える。
  ADAPTIVE	テーブルグループ内のすべてがパーティションテーブルの場合、各テーブルのパーティション内で値が同じパーティションが集約される（同一のパーティショングループ内）。パーティション間は分散される。 テーブルグループ内のすべてがサブパーティションテーブルの場合、各テーブルのサブパーティション内で値が同じパーティションが集約される（同一のパーティショングループ内）。サブパーティション間は分散される。	テーブルグループ内のすべてがパーティションテーブルの場合、数個の重み付けされたパーティションがテーブルグループ全体の分布に影響を与える。現在、サブパーティションテーブルに対するパーティションの重み設定はサポートされていない。

  以下の簡単な例を用いて説明します。テーブルグループ内のあるテーブルのパーティションにパーティションの重みを設定した場合、テーブルグループ全体の分布に与える影響を示します。

  假定します。現在、SHARDING = PARTITION のテーブルグループがあり、その中に t1、t2 の2つのパーティションテーブルがあります。各テーブルにはそれぞれ6つのパーティションがあり、各テーブルのパーティションは1つのパーティショングループにバインドされています。元のパーティション分布は以下のとおりです。

  まず、パーティションテーブル t1 のすべてのパーティションの重みを1に設定し、次に t1_p0=6、t1_p1=6 を設定します。パーティションの均衡処理後、テーブルグループ内のパーティション分布は以下のとおりです。

• V4.4.2 BP1 以降のバージョン

  テーブルグループの SHARDING プロパティと SCOPE プロパティ	元のパーティション分布方式	パーティションの重みを設定した後の影響
  SHARDING = 'NONE' + SCOPE = 'SERVER'	全部が一つのグループに集約される	影響なし
  SHARDING = 'PARTITION' + SCOPE = 'CLUSTER'	各テーブルのパーティション内で値が同じパーティションが集約される（同一のパーティショングループ内）。パーティション間は分散される。	数個の重み付けされたパーティションがテーブルグループ全体の分布に影響を与える。
  SHARDING = 'ADAPTIVE' + SCOPE = 'CLUSTER'	テーブルグループ内のすべてがパーティションテーブルの場合、各テーブルのパーティション内で値が同じパーティションが集約される（同一のパーティショングループ内）。パーティション間は分散される。 テーブルグループ内のすべてがサブパーティションテーブルの場合、各テーブルのサブパーティション内で値が同じパーティションが集約される（同一のパーティショングループ内）。サブパーティション間は分散される。	テーブルグループ内のすべてがパーティションテーブルの場合、数個の重み付けされたパーティションがテーブルグループ全体の分布に影響を与える。現在、サブパーティションテーブルに対するパーティションの重み設定はサポートされていない。

  説明

  SHARDING = 'NONE' + SCOPE = 'ZONE' および SHARDING = 'NONE' + SCOPE = 'CLUSTER' のテーブルグループは、パーティションレベルまたはテーブルレベルの重みをサポートしていません。

パーティション数の均衡

パーティション数の均衡とは、すべてのユーザーのLS上におけるユーザーテーブルのパーティション数を均等にすること（数値の偏差を1以内に抑える）を目標とします。

実装上、OceanBaseデータベースでは「均衡グループ」という概念を用いて分散関係を記述し、分散させる必要があるパーティションを同一の均衡グループ内に分類します。グループ内均衡とグループ間均衡を組み合わせることで、パーティション数の均衡を実現します。

Table Groupが存在しない場合、均衡グループの分割方法は以下のとおりです：

均衡処理の段階では、システムはまずすべての均衡グループに対してグループ内均衡を行います。これは、グループ内のパーティションを均等に分散することです。その後、グループ内均衡の基礎の上で、パーティション数が最も多いLSから一部のパーティションを転送し、グループ間均衡を行うことで、パーティション数の均衡を実現します。

例えば、既存の4つのテーブルのすべてのパーティションがLS1上にあり、3つの均衡グループに分かれている場合：

• 均衡グループ1：非パーティションテーブル non_part_t1、non_part_t2

• 均衡グループ2：パーティションテーブルの2つのパーティション part_one_t3_p0、part_one_t3_p1

• 均衡グループ3：セカンダリパーティションテーブルの4つのパーティション part_two_t4_p0s0、part_two_t4_p0s1、part_two_t4_p1s0、part_two_t4_p1s1

初期配置では、パーティションの分布は8-0-0です。

グループ内均衡後、パーティションの分布は4-4-0となり、各均衡グループは均衡に達していますが、全体としては均衡していません。

グループ間均衡後、パーティションの分布は3-3-2となり、パーティション数が最も多いLS1、LS2からそれぞれ1つのパーティションを、パーティション数が最も少ないLS3に転送することで、全体として均衡が達成されます。

Table Groupが存在する場合、各Table Groupは独立した均衡グループとなります。システムはTable Groupが要求する集約されたパーティションを結合し、1つのパーティションと見なします。その後、同様のグループ内均衡およびグループ間均衡の方法で、パーティション数の均衡を図ります。Table Groupが存在する場合、テナント内のすべてのパーティション数が完全に均等になるとは限りません。

Table Groupが存在する場合の均衡グループの分割方法は以下のとおりです：

• V4.4.2 BP1（含まず）以前のバージョン

  テーブルグループのSHARDINGプロパティ	均衡グループの分割	分布方法
  SHARDING = 'NONE'	テーブルグループ全体が1つの均衡グループ	テーブルグループ内のすべてのパーティションは1つのログストリーム上に分布します
  SHARDING = 'PARTITION'	すべてのテーブルのパーティションが1つの均衡グループ	最初のテーブルのパーティションをすべてのログストリームに均等に分散し、後続のテーブルは最初のテーブルと集約されます
  SHARDING = 'ADAPTIVE'	すべてがパーティションテーブルの場合：すべてのテーブルのパーティションが1つの均衡グループ すべてがセカンダリパーティションテーブルの場合：すべてのテーブルの同一のパーティションキーを持つパーティションの下のすべてのセカンダリパーティションが1つの均衡グループ	すべてがパーティションテーブルの場合：最初のテーブルをすべてのログストリームに均等に分散し、後続のテーブルは最初のテーブルと集約されます。 すべてがセカンダリパーティションテーブルの場合：最初のテーブルの各パーティションに含まれるすべてのセカンダリパーティションをすべてのログストリームに均等に分散し、後続のテーブルは最初のテーブルと集約されます。

  例えば、上記の均衡後に、新たにsharding = 'NONE'のTable Group tg1を追加する場合、このグループにはnon_part_t5_in_tg1、non_part_t6_in_tg1、non_part_t7_in_tg1、non_part_t8_in_tg1、non_part_t9_in_tg1の5つの非パーティションテーブルが含まれます。tg1内のすべてのテーブルは必ず結合されるため、均衡後のテーブルのパーティション分布は4-4-5となります。

• V4.4.2 BP1以降のバージョン

  テーブルグループのSHARDINGプロパティとSCOPEプロパティ	均等なグループ分割	分布方式
  SHARDING = 'NONE' + SCOPE = 'SERVER'	テーブルグループ全体が1つの均衡グループ	テーブルグループ内のすべてのパーティションが1つのノードに配置される
  SHARDING = 'NONE' + SCOPE = 'ZONE'	テーブルグループ全体が1つの均衡グループ	テーブルグループ内のすべてのパーティションが特定のゾーン内に均等に分散する
  SHARDING = 'NONE' + SCOPE = 'CLUSTER'	テーブルグループ全体が1つの均衡グループ	テーブルグループ内のすべてのパーティションが各ノードに均等に分散する
  SHARDING = 'PARTITION' + SCOPE = 'CLUSTER'	すべてのテーブルのパーティションが1つの均衡グループ	最初のテーブルはすべてのログストリームに均等に分散し、後続のテーブルは最初のテーブルに集約される
  SHARDING = 'ADAPTIVE' + SCOPE = 'CLUSTER'	すべてがパーティションテーブルの場合：すべてのテーブルのパーティションが1つの均衡グループ すべてがサブパーティションテーブルの場合：すべてのテーブルの同じパーティションキーを持つパーティションのすべてのサブパーティションが1つの均衡グループ	すべてがパーティションテーブルの場合：最初のテーブルはすべてのログストリームに均等に分散し、後続のテーブルは最初のテーブルに集約される。 すべてがサブパーティションテーブルの場合：最初のテーブルの各パーティションのすべてのサブパーティションがすべてのログストリームに均等に分散し、後続のテーブルは最初のテーブルに集約される。

SCOPE = 'ZONE' のテーブルグループ

V4.4.2バージョンでは、OceanBaseデータベースはV4.4.2 BP1バージョンから、テーブルグループが SCOPE プロパティをサポートしています。テーブルグループ内のパーティションの配置方法は、SHARDING プロパティと SCOPE プロパティによって共同で決定されます。ここで、SHARDING プロパティは、テーブルグループ内の各テーブル間で対応するパーティションの集約方式を決定し、集約された一連のパーティションをパーティショングループ（Partition Group）と呼び、これが分散の最小単位です。SCOPE プロパティは、テーブルグループ内のすべての集約後のPartition Groupの配置範囲を決定します。

数量均衡

SCOPE = 'ZONE'（すなわち SHARDING = 'NONE' + SCOPE = 'ZONE'）のテーブルグループでは、各Zoneが負担するテーブルグループの数が可能な限り均等になります。テーブルグループ内のすべてのパーティションは、Round Robin方式でプライマリZoneが同じ各ログストリームに均等に分散されます。

以下、簡単な例を通じて SCOPE = 'ZONE' テーブルグループの分散効果を示します。

あるテナントのローカリティが FULL{1}@z1, FULL{1}@z2（2F1A）、UNIT_NUM = 2 であり、かつ PRIMARY_ZONE = 'z1,z2' であると仮定します。このテナントには以下のようなテーブルが存在します：

• 非パーティションテーブル：nonpart_1、nonpart_2、nonpart_3、nonpart_4

• パーティション1テーブル：part_1、part_2

• サブパーティションテーブル：subpart_1、subpart_2

• グローバルインデックステーブル：global_index_1、global_index_2、global_index_3、global_index_4

現在、このテナントに tablegroup1、tablegroup2 の2つのテーブルグループを作成します。

obclient> CREATE TABLEGROUP tablegroup1 SHARDING = 'NONE', SCOPE = 'ZONE';

obclient> CREATE TABLEGROUP tablegroup2 SHARDING = 'NONE', SCOPE = 'ZONE';

その後、対応するテーブルやパーティションをこれら2つのテーブルグループに追加します。

obclient> ALTER TABLEGROUP tablegroup1 ADD TABLE nonpart_1,nonpart_2,part_1,subpart_1,global_index_1, global_index_2;

obclient> ALTER TABLEGROUP tablegroup2 ADD TABLE nonpart_3,nonpart_4,part_2,subpart_2,global_index_3, global_index_4;

パーティションの均衡化後の分散効果は以下のとおりです：

比重均衡

SCOPE = 'ZONE' のテーブルグループでは、重み（MySQLモードのみで設定可能）を設定することで、ホットなテーブルグループを異なるZoneに分散させることができます。

以下、例を挙げて説明します。現在のテナントに SHARDING = NONE かつ SCOPE = 'ZONE' のテーブルグループが6つあると仮定します。重みを設定する前の分散状況は以下のとおりです。

• アプリケーションシナリオ1：少数のホットスポットの分散

  TG1とTG4が同一Zone内の2つのホットなテーブルグループであり、分散が必要な場合を想定します。重みの段階が最も少ない原則に基づき、「小さな重み = 1」という1つの重み段階だけを使用して解決できます。

  テーブルグループの重みをTG1 = 1、TG4 = 1に設定した後の分散状況は以下のとおりです。

• 適用シナリオ2：トラフィック分布に基づく分散

  ユーザーが事前に各テーブルグループのトラフィックを把握しており、TG1が最も多く、TG2とTG3がそれに続き、TG4、TG5、TG6が最も少ない場合、トラフィックに応じて分散させたいと考えます。

  3段階の重みを使用できます：

  1. 大重み = 100% × 重み付けしたいテーブルグループ数 = 6

  2. 中重み = 50% × 重み付けしたいテーブルグループ数 = 3

  3. 小重み = 1

  対応する重みをTG1 = 6、TG2 = 3、TG3 = 3、TG4 = 1、TG5 = 1、TG6 = 1と設定した後、パーティションの均等化により以下の分布が得られます。

ディスクの均等化

SCOPE = 'ZONE' のテーブルグループについては、各ゾーンの SCOPE = 'ZONE' テーブルグループの数と重みが均衡を保つ前提で、システムは異なるゾーン間で SCOPE = 'ZONE' のテーブルグループを自動的に交換し、各ゾーンの SCOPE = 'ZONE' テーブルグループのディスク容量の総量を可能な限り均等にします。

ゾーン間の SCOPE = 'ZONE' テーブルグループのディスク容量の総量の差が一定の条件に達した場合にのみ、テーブルグループの交換が開始されます。同時に満たす必要がある条件は以下の通りです：

1. テーブルグループのディスク容量の総量の差が、最大のゾーンの総量の zone_disk_balance_tolerance_percentage/100を超えること。デフォルト値は10%です。

   テナントレベルの構成パラメータ zone_disk_balance_tolerance_percentage は、ゾーン間のテーブルグループディスク均等化アルゴリズムの不均衡に対する許容度を制御します。値の範囲は[0, 100]です。値が 100 の場合、ゾーン間のディスク均等化は無効になります。

2. 最大のゾーンのディスク容量の総量が 50 GB * ログストリームグループ数 を超えること。

交換される SCOPE = 'ZONE' テーブルグループについては、以下の条件も満たす必要があります：

1. テーブルグループの重み値が同じであること。

2. 交換後、2つのゾーン間のディスク容量の差が縮まること。

以下の例で説明します。現在、6つの SCOPE = 'ZONE' テーブルグループがあり、重みは設定されていません。テーブルグループ数の均等化後の分布状況は以下の通りです。この時点では、ZONE3のディスク使用率が最も高いです。

ディスク均等化がトリガーされると、まずディスク使用率が最大と最小のZONE3とZONE2の間で、TG3とTG2のテーブルグループを交換します。交換後の分布状況は以下の通りです。

次に、ZONE1とZONE3の間で、TG2とTG4のテーブルグループを交換します。交換後の分布状況は以下の通りです。

この時点で、さらに交換を進めることはできず、テーブルグループのディスク均等化は終了します。

パーティションディスクの均衡化

パーティション数またはパーティション重みの均衡を基盤として、ロードバランシングモジュールは可能な限りパーティションを交換することで、各ログストリーム間のディスク使用量の差がクラスタレベル構成パラメータ balancer_tolerance_percentage で設定された割合を超えないようにします。単一パーティションのディスク使用量が過大な場合、この均衡効果が得られない可能性があります。

少量データシナリオでの頻繁な均衡を避けるため、現在のバージョンではパーティションディスク均衡がトリガーされるしきい値は「50GB」です。個々のLSのディスク使用量がこのしきい値を下回る場合、ディスク均衡はトリガーされません。

パーティション均衡の判断方法

パーティション均衡はユーザーテーブルの主テーブルに対する均衡であり、クエリ時には table_type='USER TABLE' を指定する必要があります。パーティションディスクの均衡は主にビュー CDB_OB_TABLET_REPLICAS の data_size フィールドによって判断されます。

• パーティション数均衡のクエリ方法

  obclient [test]> SELECT svr_ip,svr_port,ls_id,count(*) FROM oceanbase.CDB_OB_TABLE_LOCATIONS WHERE tenant_id=xxx AND role='leader' AND table_type='USER TABLE' GROUP BY svr_ip,svr_port,ls_id;
  

• パーティションディスク均衡のクエリ方法

  obclient [test]> SELECT a.svr_ip,a.svr_port,b.ls_id,sum(data_size)/1024/1024/1024 as total_data_size FROM oceanbase.CDB_OB_TABLET_REPLICAS a, oceanbase.CDB_OB_TABLE_LOCATIONS b WHERE a.tenant_id=b.tenant_id AND a.svr_ip=b.svr_ip AND a.svr_port=b.svr_port AND a.tablet_id=b.tablet_id AND b.role='leader' AND b.table_type='USER TABLE' AND a.tenant_id=xxxx GROUP BY svr_ip,svr_port,ls_id;
  

パーティションの集約後の分散シナリオ

パーティションの均衡は、システムの負荷バランスを動的に維持する継続的なプロセスです。業務の実際の運用において、システムはリアルタイムの負荷状態に応じてパーティションの集約と再分散を行い、リソース利用効率とパフォーマンスの最適なバランスを実現します。一般的なパーティションの集約後の分散シナリオは以下の通りです：

• テナントの水平スケールイン後のスケールアウト。例えば、テナントの UNIT_NUM 数を N -> 1、次に 1 -> N に変更します。

• テナントの PRIMARY_ZONE の第一優先順位の数がまず少なくなり、その後増加する場合。例えば、テナントの PRIMARY_ZONE を RANDOM -> zone1、次に zone1 -> RANDOM に変更します。

• 大量のテーブルを NONE のシャーディング属性を持つテーブルグループに追加した後、そのテーブルをテーブルグループから削除する場合。

既存のログストリーム均衡およびパーティション均衡アルゴリズムでは、パーティションの集約後の分散後、パーティションテーブル内の連続するパーティションが同一のログストリームに集まったり、同一データベース下の非パーティションテーブルが同一のログストリームに集まったりする現象が発生します。この問題を解決するため、OceanBaseデータベースはパーティション均衡アルゴリズムを最適化しました：

• 非パーティションテーブルについては、パーティションの集約後の分散後、同一データベース下の複数の非パーティションテーブルが各ユーザーのログストリーム上に分散配置され、パーティション数に応じて均衡されます。これにより、同一データベース下の非パーティションテーブルが同一のログストリーム上に連続して配置されることを防ぎます。

• パーティションテーブルについては、パーティションの集約後の分散後、同一パーティションテーブルの連続するパーティションがラウンドロビン方式で各ユーザーのログストリーム上に分散配置され、数に応じて均衡されます。これにより、パーティションテーブルのパーティションが同一のログストリーム上に連続して配置されることを防ぎます。