Overview

OceanBase Database provides load balancing capabilities, including horizontal scaling and dynamic data balancing.

Horizontal scaling in OceanBase Database allows you to adjust the number of service nodes to scale in or out service capabilities. For example, you can increase the number of service nodes from one to two, thereby improving the service capabilities. Horizontal scaling also supports data redistribution. For example, when the number of service nodes is increased from one to two, the data needs to be evenly distributed on the two service nodes. When the number of service nodes is decreased from two to one, the data needs to be redistributed to the single service node.

Dynamic data balancing in OceanBase Database adjusts data distribution to implement dynamic load balancing among the service nodes, when the service nodes remain unchanged. For example, when tables and partitions are dynamically created and deleted, the number of partitions on each service node may vary drastically, resulting in unbalanced load among the service nodes. By using the dynamic partition balancing capability, partitions can be evenly distributed on each service node.

Horizontal scaling

In OceanBase Database, the storage capacity and read/write service capabilities of tenants are mainly determined by the following two aspects:

• The number of resource units that provide services on each zone.

  You can adjust the number of resource units to increase or decrease the number of service nodes, thereby achieving horizontal scaling of the read/write service capabilities and storage capacity.

  For more information about how to scale in or out a tenant by adjusting the number of resource units, see Modify the number of resource units for a tenant.

• The number of primary zones that provide read and write services.

  You can adjust the number of primary zones to increase or decrease the number of zones that provide read/write services, thereby achieving horizontal scaling of services among zones.

  For more information about how to scale in or out a tenant by adjusting the number of primary zones, see Modify the number of primary zones for a tenant.

You can adjust the numbers of resource units and primary zones to achieve horizontal scaling of read/write services among zones for a tenant. The load balancing feature adaptively adjusts the log stream and partition distribution based on your custom service capability settings.

Partition balancing

In partition balancing, OceanBase Database dynamically adjusts partition distribution when tables and partitions change, thereby achieving storage space and partition balancing among the service nodes.

OceanBase Database supports multiple table types, including non-partitioned tables, partitioned tables, and subpartitioned tables. The balancing strategies vary with the table type. OceanBase Database divides table partitions into groups and balances the numbers of partitions and storage space within each balancing group. The balancing groups are independent of each other, and partition distribution is adjusted adaptively within each balancing group. By default, OceanBase Database adopts the following partition balancing strategies:

• Partitioned tables: Each partitioned table is an independent balancing group. All partitions of the table are evenly distributed to each service node.

• Subpartitioned tables: All subpartitions of one partition form an independent balancing group. All subpartitions of each partition are evenly distributed to each service node.

• Non-partitioned tables: All non-partitioned tables are in one balancing group. All non-partitioned tables are evenly distributed to each service node.

OceanBase Database introduces the concept of table groups to facilitate the description of table data aggregation and dispersion.

A table group is a logical concept that represents a collection of tables. Tables in the same table group are adjacent to each other on the physical storage. Tables associated with each other often share the same partitioning rules. Partitions that adopt the same partitioning rules are placed together to implement partition wise joins, which greatly optimize read and write performance.

OceanBase Database introduced the SHARDING attribute in V4.2.0, which controls the aggregation and dispersion of table data within a table group. Valid values of the SHARDING attribute of a table group include NONE, PARTITION and ADAPTIVE.

You can choose a suitable value for the SHARDING attribute based on the scenario.

Scenario 1: Place all tables in a table group together

If you want to place any type of table on a single machine to meet the business needs of single-machine access, you can specify SHARDING = NONE.

A table group with SHARDING = NONE specified has the following features:

• Tables of any partition type, including partitioned, subpartitioned, and non-partitioned tables, can be added to the table group.
• All partitions of all tables in the table group are placed together. The system ensures that they are on the same machine.

Scenario 2: Horizontally scatter all table data in a table group

When a single machine cannot fully hold the data of a single service, you can spread the data across multiple machines to achieve horizontal scaling. In this case, specify SHARDING = PARTITION or SHARDING = ADAPTIVE.

A table group with SHARDING = PARTITION specified has the following features:

• Partitioned and subpartitioned tables can be added to the table group.

  • Partitioning method requirements: The partitioning method of these tables must be the same. For subpartitioned tables, the system verifies only the partitioning method. Therefore, both partitioned and subpartitioned tables can be added to the table group, only that their partitioning methods are the same.
  • Partition alignment rules: Partitions with the same partitioning key value are placed together, including partitions of partitioned tables and subpartitions under each partition of subpartitioned tables.

• All tables in a table group are scattered by partition. At the same time, subpartitions with the same subpartitioning key value of subpartitioned tables are placed together.

A table group with SHARDING = ADAPTIVE specified has the following features:

• Partitioned tables or subpartitioned tables can be added to the table group.

  • Partitioning method requirements: All tables must either be partitioned tables or subpartitioned tables. For partitioned tables, the partitioning methods must be the same. For subpartitioned tables, both the partitioning and subpartitioning methods must be the same.

  • Partition alignment rules:

    • Partitioned tables: Partitions with the same partitioning key value are placed together.
    • Subpartitioned tables: Partitions with the same partitioning key value and the same subpartitioning key value are placed together.

• Scattering is performed in an adaptive way. If all tables in a table group are partitioned tables, they are scattered by partition. If all tables in a table group are subpartitioned tables, they are scattered by subpartition under each partition.

For more information about table groups and supported operations, see Create and manage table groups (MySQL mode) and Create and manage table groups (Oracle mode).

Load balancing parameters

• enable_rebalance

  You can use the tenant-level parameter enable_rebalance in the sys tenant to control load balancing among tenants. You can use the parameter in a user tenant to control intra-tenant load balancing. The default value of this parameter is true.

  For more information about the enable_rebalance parameter, see enable_rebalance.

• enable_transfer

  You can use the tenant-level parameter enable_transfer to enable or disable partition transfer in a tenant. The default value is true.

  • If the value of enable_rebalance is false, the system does not perform automatic load balancing regardless of whether the value of enable_transfer is true or false.

  • If enable_rebalance is set to true and enable_transfer is set to true, when the tenant is scaled in or out, the system automatically adjusts the number of log streams in the tenant and performs operations such as log stream splitting, merging, and partition transfer to achieve leader and partition balancing within the tenant.

  • If enable_rebalance is set to true and enable_transfer is set to false, when the tenant is scaled in or out, the system does not transfer partitions and implements log stream balancing without changing the number of log streams.

  For more information about enable_transfer, see enable_transfer.

• partition_balance_schedule_interval

  You can use the tenant-level parameter partition_balance_schedule_interval to control the interval for generating partition load balancing tasks. If enable_rebalance is set to true, the system triggers a partition load balancing task at the interval specified by partition_balance_schedule_interval. The default value is 2H. The value range is [0s, + ∞). The value 0s indicates that partition balancing is disabled.

  For more information about partition_balance_schedule_interval, see partition_balance_schedule_interval.