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 in 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 within a zone or across 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 number 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 better describe table data aggregation and distribution.

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 aggregated together to implement partition-wise joins, which greatly optimize read and write performance.

The SHARDING attribute has been introduced since OceanBase Database V4.2.0 to control 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 select an appropriate value for the SHARDING attribute based on the scenario.

Scenario 1: Aggregate all tables in a table group together

If you want to aggregate any type of table on the same server to meet the business needs in standalone mode, you can use a table group with the SHARDING attribute set to NONE.

The table group with the SHARDING attribute set to NONE 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 aggregated together. The system ensures that they are on a single server.

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

When a single server cannot store the data of a single service, you can distribute the data across multiple servers to achieve horizontal scaling. In this case, you can use a table group with the SHARDING attribute set to PARTITION, or a table group with the SHARDING attribute set to ADAPTIVE.

The table group with the SHARDING attribute set to PARTITION has the following features:

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

  • Partitioning method requirements: All tables use the same partitioning method. For a subpartitioned table, only its partitioning method is verified. Therefore, the table group may contain both partitioned and subpartitioned tables, as long as their partitioning types are the same.
  • 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.

• All tables in a table group are distributed by partition. At the same time, all subpartitions in the corresponding partitions of subpartitioned tables are aggregated together.

The table group with the SHARDING attribute set to ADAPTIVE has the following features:

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

  • Partitioning method requirements: All tables are partitioned tables or subpartitioned tables. If all tables are partitioned tables, the tables must use the same partitioning type. If all tables are subpartitioned tables, the tables must use the same partitioning and subpartitioning types.

  • Partition alignment rule:

    • Partitioned tables: Partitions with the same partition value are aggregated together.
    • Subpartitioned tables: Partitions with the same partition value and the same subpartition value are aggregated together.

• Data is distributed in an adaptive way. If all tables in a table group are partitioned tables, data is distributed by partition. If all tables in a table group are subpartitioned tables, data is distributed by subpartition in each partition.

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

Load balancing parameters

• enable_rebalance

  You can specify the tenant-level parameter enable_rebalance in the sys tenant to control whether to enable load balancing among tenants, and specify the parameter in a user tenant to control whether to enable load balancing within the tenant. The default value is true.

• enable_transfer

  You can use the tenant-level parameter enable_transfer to specify whether to perform a partition transfer in a tenant. The default value is true. The following scenarios are present:

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

  • When the values of both the enable_rebalance parameter and the enable_transfer parameter are true, the system automatically adjusts the number of log streams when you perform scaling in a tenant. Specifically, the system automatically splits, merges, and transfers log streams to balance leaders and partitions in the tenant.

  • When the value of the enable_rebalance parameter is true and the value of the enable_transfer parameter is false, the system does not transfer log streams when you perform scaling in a tenant. In other words, the number of log streams is not changed. Instead, load balancing is achieved among the existing log streams of the tenant.

• partition_balance_schedule_interval

  Notice

  OceanBase Database provides a built-in scheduled partition balancing job since V4.2.4. We recommend that you do not use the partition_balance_schedule_interval parameter for partition balancing in OceanBase Database V4.2.4 and later (excluding V4.3.x). You can use the DBMS_BALANCE package to trigger the scheduled partition balancing job or manually trigger a partition balancing job.

  You can use the tenant-level parameter partition_balance_schedule_interval to specify the interval for triggering a partition balancing job. When the value of the enable_rebalance parameter is true, the system automatically triggers a partition load balancing job based on the value set for the partition_balance_schedule_interval parameter. When the value of the partition_balance_schedule_interval parameter is set to 0s, partition load balancing is disabled.