Overview

A table group is a logical concept. It represents a collection of tables. By default, data in different tables is randomly distributed with no direct relationship. By defining a table group, you can control the physical proximity of a group of tables.

Sharding attributes of table groups

In OceanBase Database V3.x, a table group is a collection of tables with defined partitions. Tables that are added to a table group must have the same partitioning method, which imposes strong restrictions on tables to be added to the group. From V4.2.0, the concept of partitions is no longer applicable to table groups. Instead, tables can be added to a table group by simply defining the SHARDING attribute, allowing you to flexibly add tables with different partitioning methods. If there is a need to restrict other tables from being added to the table group, the properties of the table group can be modified, enabling more flexible management of table groups.

The SHARDING attribute determines the way in which partitions of tables in a table group are aggregated or distributed in 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: No restriction is imposed on the partitioning method of tables in the table group. Partitions of tables in the table group are not aggregated. In versions earlier than V4.4.2 BP1, NONE also implies that all partitions are aggregated in a single server. This behavior is removed in later versions. The distribution range of partitions is determined by the SCOPE attribute.

• SHARDING = PARTITION: The data of each table in such a 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, the partition definition, rather than the subpartition definition, is verified. Therefore, a table group can contain both partitioned and subpartitioned tables only if 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 such a 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

In OceanBase Database V4.4.2 BP1 and later, the SCOPE attribute is introduced to define the distribution range of the partition groups formed after SHARDING aggregation.

The SCOPE attribute has the following three values:

• SERVER: All partition groups are aggregated on the same server. This value provides the strongest data locality but may affect cluster load balancing.
• ZONE: All partition groups are distributed within the same zone and scattered across different servers in the zone. This value balances data locality and load balancing within the zone.
• CLUSTER: All partition groups are scattered across different servers in the cluster. This value maximizes cluster load balancing but may increase cross-server access.

Use cases of SCOPE = ZONE

1. Cross-zone latency-sensitive applications: Aggregate leaders of related partitions in the same zone to reduce cross-zone access latency.
2. Load balancing within the zone: Disperse leaders of different partitions across different servers within the zone to avoid high load on a single server.
3. Global index consistency: Ensure that leaders of the main table and global indexes are in the same zone to maintain data locality.

References

• Create a table group

• Query information about a table group

• Add tables to a table group

• Modify the SHARDING attribute of a table group

• Manage tables in a table group

• Drop a table group