A table group is a logical concept that represents a collection of tables. In OceanBase Database, by default, data in different tables is randomly distributed across different storage nodes. By creating a table group, you can explicitly define the physical proximity of a group of tables, thereby optimizing the performance of join queries and simplifying data management.
Sharding attributes of table groups
In earlier versions (V3.x), table groups had strict partitioning requirements, which limited the ability to add tables to a group. Starting from V4.2.0, the concept of partitions was replaced by the SHARDING attribute. This attribute determines how partitions of tables in a table group are aggregated and distributed across the cluster. The set of aggregated partitions is called a partition group (Partition Group).
The SHARDING attribute has the following three modes, corresponding to different data distribution strategies:
SHARDING = NONE: Indicates no restrictions on the partitioning method of tables in the table group, and partitions are not aggregated. In versions earlier than V4.4.2 BP1,NONEalso implied that all partitions are aggregated on the same server (single-node aggregation). This behavior has been removed in newer versions, and the distribution range is now determined by theSCOPEattribute.SHARDING = PARTITION: The data of each table in the table group is scattered by partition. For a subpartitioned table in the table group, all subpartitions in a partition are aggregated together.- 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 in a table group as long as they have the same partition definition.
- Partition alignment rule: Partitions with the same partition value are aggregated together, including partitions of partitioned tables and all subpartitions in the corresponding partitions of subpartitioned tables.
SHARDING = ADAPTIVE: The data of each table in the table group is adaptively scattered. In other words, data in partitioned tables is scattered by partition, and data in subpartitioned tables is scattered by subpartition in each partition.Take note of the partition requirement and partition alignment rule for tables in such a table group:
- Partition requirement: Tables in such a table group are 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 definition and subpartition definition.
- Partition alignment rule: If all tables in such a table group are partitioned tables, partitions with the same partition value are aggregated together. If all tables in such a table group are subpartitioned tables, subpartitions with the same partition value and subpartition value are aggregated together.
The SCOPE attribute
Starting from V4.4.2 BP1, OceanBase Database introduced the SCOPE attribute for table groups. This attribute defines the distribution range of partition groups (Partition Groups) formed after aggregation by the SHARDING attribute.
The SCOPE attribute has the following three values:
SERVER: Indicates that all partition groups are aggregated on the same server. This value provides the strongest data locality but may affect cluster load balancing.ZONE: Indicates that all partition groups are distributed across different servers within the same zone. This value balances data locality and load balancing within the zone.CLUSTER: Indicates that all partition groups are distributed across different servers in the cluster. This value maximizes cluster load balancing but may increase cross-node access.
Use cases for SCOPE = ZONE
- Cross-zone latency-sensitive applications: Aggregate the leaders of related partitions in the same zone to reduce cross-zone access latency.
- Load balancing within a zone: Distribute the leaders of different partitions across different servers within the same zone to avoid overloading a single server.
- Global index consistency: Ensure that the leaders of the main table and global indexes are in the same zone to maintain data locality.