データパーティションは、テーブル作成ステートメントに基づいて作成される論理オブジェクトであり、テーブルデータを分割および管理するメカニズムです。各テナントは複数のUnitで構成され、ログストリームは一定のルールに従ってこれらのUnitに分散配置されます。これにより、各ログストリームに属するデータパーティションがUnit上にどのように分布するかが決定されます。このセクションでは、データ及びそのトラフィックの分布ルールについて説明します。
OceanBaseデータベースは、通常テーブルとパーティションテーブルをサポートしています。パーティションテーブルはさらに、パーティションテーブルとサブパーティションテーブルに分類され、パーティションテーブルは1つ以上のパーティションで構成されます。通常テーブルは1つのパーティションで構成され、パーティションテーブルの特殊なケースと見なすことができます。OceanBaseデータベースの基本的なパーティション戦略には、範囲 (Range) パーティション、リスト (List) パーティション、ハッシュ (Hash) パーティション、Key パーティションなどがあります。
同一ゾーンモードと異種ゾーンモード
OceanBaseデータベース V4.x より前のバージョン（V4.2.5 を除く、V4.2.5 BP5 以降の BP バージョンを含む）では、テナント管理に制限が加えられ、同一テナント内のすべてのゾーンのUnit数が同じであることが求められました。これが同一ゾーンモードです。
現在のバージョンでは、この制限が緩和され、同一テナント内のすべてのゾーンのUnit数が同じである必要はなくなりました。これにより、テナントの異種ゾーンモードがサポートされるようになりました。
注意
通常、既存のテナントやアップグレードされたテナントは、デフォルトで同一ゾーンモードに設定されています。異種ゾーンモードを有効にするには、テナントレベルの構成パラメータ zone_deploy_mode の値を hetero（異種ゾーンモード）に変更する必要があります。変更後は、homo（同一ゾーンモード）に戻すことはできません。
同一ゾーンモードと比較して、異種ゾーンモードの主な使用上の違いは以下のとおりです：
ログストリームの分布はUnit Groupに束縛されなくなり、各ゾーンのレプリカが対称的なUnit上に限定される必要がなくなりました。均等化アルゴリズムはUnitの粒度で各ログストリームの分布を制御します：
テナントの各ゾーン内では、各Unit上のログストリーム数が等しくなります（異なるゾーン間では、Unit上のログストリーム数が異なる場合があります）。
UNIT_NUMが同じゾーン内では、そのログストリームは同一の方法で集約されます。
テナント内の各リソースプールの
UNIT_NUMは異なる場合がありますが、最大でも2種類の異なるUNIT_NUMしかサポートされません。ALTER RESOURCE POOLステートメントを使用して、テナント内の特定のリソースプールのUNIT_NUMを個別に変更し、リソースプール単位でのスケーリングを実現できます。ALTER RESOURCE TENANTステートメントを使用してUNIT_NUMを減らしてスケールインする際、UNIT_GROUPを指定して削除することはサポートされません。ログストリームの運用コマンドである
ALTER SYSTEM CREATE LSおよびALTER SYSTEM MODIFY LSを使用する際、UNIT_GROUPパラメータを指定することはサポートされません。
Unit Groupの紹介
テナントの同一ゾーンモードでは、同一テナント内のすべてのゾーンのUnit数が同じであることが求められます。システムは各ゾーンのUnitに番号を付けており、異なるゾーン間で同じ番号 (UNIT_GROUP_ID) を持つUnitが1つのUnit Groupを形成します。Unit Groupには以下の特性があります：
各Unit Groupには一意のIDが割り当てられ、システムテナントは
oceanbase.DBA_OB_UNITSビューのUNIT_GROUP_IDフィールドでこのIDを確認できます。1つのログストリームは必ず1つのUnit Groupに属し、そのUnit GroupのUnit上にのみ配置されます。したがって、Unit Group内のすべてのUnitはログストリーム単位で同じデータパーティションを分散して保持し、それによって一連のデータを定義します。同時に、各ゾーンのサービス能力が同等であることが求められます。
ゾーンごとにテナントのUnit数を個別に設定することはサポートされておらず、Unit Group単位で全体を調整する必要があります。例えば、テナントの水平方向へのリソース拡張を行う場合、Unit数を増やすにはすべてのゾーンを一斉に拡張する必要があります。同様に、テナントのスケールインが必要な場合も、Unit Group単位でまとめてUnitを削除する必要があります。Unit Groupの仕組みにより、異なるゾーン上のデータ分布が同種であることが保証されます。
sysテナントでは、oceanbase.DBA_OB_UNITSビューを使用して、すべてのUnitとそれらが属するUnit Groupを照会できます。例：
obclient(root@sys)[oceanbase]> SELECT UNIT_ID, TENANT_ID, UNIT_GROUP_ID, ZONE, SVR_IP, SVR_PORT FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = 1004;
実行結果は次のとおりです：
+---------+-----------+---------------+--------------+-------------+----------+
| UNIT_ID | TENANT_ID | UNIT_GROUP_ID | ZONE | SVR_IP | SVR_PORT |
+---------+-----------+---------------+--------------+-------------+----------+
| 1004 | 1004 | 1003 | sa128_obv4_1 | xx.xx.xx.47 | 2882 |
| 1005 | 1004 | 1003 | sa128_obv4_2 | xx.xx.xx.81 | 2882 |
| 1006 | 1004 | 1003 | sa128_obv4_3 | xx.xx.xx.19 | 2882 |
+---------+-----------+---------------+--------------+-------------+----------+
3 rows in set
ログストリームグループの紹介
ログストリームグループの概念は、Primary Zoneが複数のZoneに分散される場合に対応するために導入されました。Primary Zoneが単一のZoneの場合、テナントのUNIT_LIST内には単一のログストリームを作成するだけで済みます。Primary Zoneが複数のZoneの場合、テナントのUNIT_LIST内に複数のログストリームを作成し、サービス能力の水平スケーリングを実現する必要があります。これらのログストリームは同じ分散属性を持ち、共に1つのログストリームグループを形成します。ログストリームグループ内のログストリームの数は、Primary ZoneのZoneの数に等しくなります。
したがって、ログストリームは1つのログストリームグループに属し、変更することはできません。ログストリームグループ内のすべてのログストリームは対応するUNIT_LIST上に分散され、ログストリームのLeaderはPrimary Zone上に分散されます。
ログストリームグループ内のログストリームの数は、テナントのPrimary Zone構成の変更に応じて動的に変化します。
sysテナントでは、oceanbase.CDB_OB_LSビューを使用して、クラスタ内のすべてのテナントのログストリームと、それらが属するログストリームグループを確認できます。例：
obclient(root@sys)[oceanbase]> SELECT TENANT_ID, LS_ID, STATUS, PRIMARY_ZONE, LS_GROUP_ID, UNIT_LIST FROM oceanbase.CDB_OB_LS where TENANT_ID=1004;
実行結果は次のとおりです：
+-----------+-------+--------+--------------+-------------+-----------+
| TENANT_ID | LS_ID | STATUS | PRIMARY_ZONE | LS_GROUP_ID | UNIT_LIST |
+-----------+-------+--------+--------------+-------------+-----------+
| 1004 | 1 | NORMAL | z1;z2 | 0 | |
| 1004 | 1001 | NORMAL | z1;z2 | 1001 | 1013,1014 |
| 1004 | 1008 | NORMAL | z1;z2 | 1007 | 1025,1026 |
| 1004 | 1013 | NORMAL | z2;z1 | 1001 | 1013,1014 |
| 1004 | 1014 | NORMAL | z2;z1 | 1007 | 1025,1026 |
+-----------+-------+--------+--------------+-------------+-----------+
5 rows in set
まとめ
以上の内容から、このセクションで紹介した多くの細かい概念をまとめます：
Unitは物理リソースの抽象化であり、各Unitはノード上の一定の物理リソース（CPU、メモリ、ストレージ容量などのリソース項目）を占有します。Unitはリソーススケジューリングの基本単位であり、同一Zone内の異なるノード間でUnitの配置を調整することで、ノードのロードバランシングや災害復旧を実現できます。
各テナントは複数のUnitで構成されており、テナントのUnit NumberとPrimary Zoneを設定することで、業務トラフィックを担うUnitの集合を定義します。各Unitは1つのノード上に配置されるため、テナント容量の水平スケーリングを容易に実現できます。
ログストリームは、複数のデータパーティションと順序付けられたRedoLogストリームを含む一連のデータを定義します。Paxosプロトコルによりマルチレプリカのログ同期が実現され、レプリカ間のデータ一貫性が保証されることで、データの高可用性が実現されます。ログストリームはトランザクションのコミット単位でもあり、トランザクションの変更が単一のログストリーム内で完了する場合は1段階の原子的コミットを採用できます。トランザクションの変更が複数のログストリームにまたがる場合は、OceanBaseデータベースが最適化した2段階コミットプロトコルを使用して原子的コミットを完了し、ログストリームは分散トランザクションの参加者となります。ログストリームには位置属性と役割属性があり、ログストリーム内のすべてのデータパーティションはその属性を継承します。
テナントは同種ゾーンモードと異種ゾーンモードをサポートしています。
同種ゾーンモードでは：
システムは各ZoneのUnitに番号を付与し、同じ番号を持つUnitが1つのUnit Groupを形成します。Unit Groupは一連のログストリームを定義し、これらのログストリームはそのUnit GroupのUnit上にのみ配置されます。
ログストリームグループとUnit Groupは1対1で対応しており、各ログストリームグループ内のログストリームの数はPrimary ZoneのZoneの数によって決定されます。したがって、Primary ZoneのZoneリスト内の各Zoneには、ログストリームグループ内の1つのログストリームのLeaderが配置される可能性があります。
テナントが
unit_num =2、primary_zone ='Z1,Z2,Z3'に設定されている場合、そのテナントは2つのUnit Group、2つのログストリームグループ、6つのログストリームを定義します。以下の図のようになります。
異種ゾーンモードでは：
システムはUnitの粒度で各ログストリームの配置を制御します。テナントの各Zone内では、各Unit上のログストリームの数は等しくなります（異なるZone間では、Unit上のログストリームの数が異なる場合があります）。
ログストリームグループ内のすべてのログストリームは対応するUNIT_LISTに分散配置され、ログストリームのリーダーはプライマリゾーンに分散しています。
以下の図のように、テナントが2つのゾーンを持ち、
unit_num =1とunit_num =2に設定され、かつprimary_zone ='zone1'の場合、バランス状態ではユーザーログストリームの総数は2です。ここでLS1の UNIT_LIST は(UNIT1, UNIT2)、LS2の UNIT_LIST は(UNIT1, UNIT3)です。図からわかるように、
LS1とLS2はzone1内では同一のUnit上に配置されていますが、zone2内では異なるUnitに配置されています。これにより、異種ゾーン下では、各ゾーン内のログストリームのレプリカの分散・集約方法が異なり得ることが示されています。
OceanBaseデータベースは、複数のレベルでデータとトラフィックを複数のノードに柔軟に分散し、Unitはゾーン内のノード間で移行可能であるため、ノードのロードバランシングや災害復旧が実現できます。