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

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リーダーが存在し、かつそれぞれのゾーンに1つのみのLSリーダーが配置されることが保証されます。

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

例1：以下の図のように、UNIT_NUM = 1の場合、PRIMARY_ZONEの第一優先順位がZ1からZ1,Z2に変更されたとき、PRIMARY_ZONEの第一優先順位を持つすべてのゾーンにリーダーが存在するようにするため、同一Unit内で新しい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属性のTable Groupを指定した場合、新規ユーザーテーブルのパーティションはTable Groupのルールに従って対応するユーザーのLSに割り当てられます。Table Groupのルールは次の表のとおりです。

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に1回パーティション均等化が実行されます。パーティション均等化に関する操作については、定期パーティション均等化タスクの設定を参照してください。

パーティション均等化ポリシーの優先順位は以下のとおりです：

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

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

Table Groupの整合性

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

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

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

duplicate_scopeの整合性

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

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

テーブルグループとパーティションのワークロード均等化

テーブルグループの重み均衡

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

Sharding = 'NONE'のテーブルグループに重みを設定することでテーブルグループの重み均衡を実現し、自動集約されたDatabase内のユーザーテーブルを重みに応じて分散させることができます。テーブルグループの重み均衡は、パーティション均衡(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 に設定した後、パーティションの均等化後の分布は以下のとおりです。

  

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

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

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

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

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

パーティション数の均等化

パーティション数の均等化の目標は、すべてのユーザーの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が存在する場合の均衡グループの分割方法は以下のとおりです：

例えば、上記の均衡後に、新たに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となります。

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

パーティション数またはパーティションの重みが均等になっていることを前提として、ロードバランシングモジュールは可能な限りパーティションを交換することで、各ログストリーム間のディスク使用量の差がクラスタレベル構成パラメータ 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 にします。

• 大量のテーブルを SHARDING 属性が NONE のテーブルグループに追加した後、そのテーブルをテーブルグループから削除する場合。

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

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

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