A table group is a logical collection concept used to organize a group of tables with strong business relevance. In OceanBase Database, by default, data from different tables is randomly distributed across different storage nodes. By creating a table group, you can explicitly define the physical proximity of this group of tables, thereby optimizing the performance of related queries and the convenience of data management.
SHARDING Attribute of Table Groups
In earlier versions (V3.x), table groups had strict partition definitions, which imposed strong restrictions on which tables could join a table group. Starting from V4.2.0, the SHARDING attribute was introduced for table groups, replacing the original partition concept. This attribute determines how the partitions corresponding to each table within the table group are aggregated and distributed across the cluster. These aggregated sets of partitions are called partition groups.
The SHARDING attribute has the following three modes, each corresponding to a different data distribution strategy:
SHARDING = NONE: Indicates no restrictions on the partitioning method for the tables joining the table group, and partitions are not aggregated between tables. In versions prior to V5.0.1 (excluding V4.4.2), theNONEsemantics also included all partitions on the same log stream without dispersion (aggregated on a single node). This semantics was removed in newer versions, and the specific distribution scope now depends on theSCOPEattribute.SHARDING = PARTITION: The data of each table in the table group is dispersed by partition (with partitions distributed across different nodes). For a subpartitioned table, all subpartitions under the same partition are aggregated on the same node.- Partition requirement: All tables must have the same partition definition. For subpartitioned tables, only the partition definition is verified. Therefore, partitioned tables and subpartitioned tables can coexist as long as they have the same partition definition.
- Partition alignment rule: Partitions with the same partition value are aggregated together, including: the partitions of a partitioned table and all subpartitions under the corresponding partition of a subpartitioned table.
SHARDING = ADAPTIVE: The data of each table in the table group is dispersed in an adaptive manner. That is, if a table in the table group is a partitioned table, it is dispersed by partition; if a table in the table group is a subpartitioned table, it is dispersed by subpartition.The partition requirements and partition alignment rules for tables in such a table group are as follows:
- Partition requirement: All tables in the table group must be either all partitioned tables or all subpartitioned tables. If they are partitioned tables, they must have the same partition definition. If they are subpartitioned tables, they must have the same partition and subpartition definitions.
- Partition alignment rule: If all tables in the table group are partitioned tables, partitions with the same partition value are aggregated together. If all tables in the table group are subpartitioned tables, subpartitions with the same partition value and subpartition value are aggregated together.
SUBPARTITION: Indicates that the tables joining the table group must be subpartitioned tables, and the partitioning methods (including partition key type, partition function, number of partitions, partition boundary values, etc.) must be the same for different tables. It also includes the following characteristics:Partition dispersion method: Subpartitions under a partition are dispersed.
Partition alignment method:
- Subpartition alignment across partitions: Subpartitions with the same partition key value under different partitions are bound to the same log stream.
- Global index alignment: Specifically, the subpartitions of a primary table and the partitions of a global index table are implicitly bound to the same log stream using the same partition key value, and this binding only occurs when the global index's partitioning method is exactly the same as the primary table's subpartitioning method.
Note
For V5.x versions, support for the
SHARDING = 'SUBPARTITION'attribute of table groups starts from V5.0.1.
SCOPE Attribute of Table Groups
For V5.x versions, starting from V5.0.1, OceanBase Database introduces the SCOPE attribute for table groups, which defines the distribution scope of the Partition Group formed after being aggregated by SHARDING within the cluster.
The SCOPE attribute has the following three possible values:
SERVER: Indicates that the Leaders of all Partition Groups are aggregated on the same node. This value provides the strongest data locality but may affect cluster load balancing.ZONE: Indicates that the Leaders of all Partition Groups are distributed within the same Zone and are dispersed across nodes within that Zone. This value balances data locality and load balancing within the Zone.CLUSTER: Indicates that the Leaders of all Partition Groups are dispersed across nodes within the cluster. This value maximizes the cluster's load balancing capability but may increase cross-node access.
Usage Scenarios for SCOPE = ZONE
- Cross-zone latency sensitivity: The leaders of related partitions need to be aggregated to the same zone to reduce cross-zone access latency.
- Load balancing within a zone: Within the same zone, the leaders of different partitions need to be distributed across different servers to avoid excessive load on a single server.
- Global index consistency: Ensuring that the leader of the primary table and the global index resides in the same zone guarantees local data access.
