This topic describes the background, concept, maintenance elements, and types of resource isolation.
Background
OceanBase Database is a multi-tenant database system. It isolates resources among tenants to prevent resource contention and ensure stable business operation.
In OceanBase Database, resource units are the basic units for allocating resources to tenants. A resource unit is equivalent to a Docker container. You can create multiple resource units on a node. Each resource unit created on the node occupies a part of the physical resources of this node, including CPU and memory resources. The resource allocation information is recorded in an internal table for the reference of database administrators (DBAs).
A tenant can distribute its resource units across multiple nodes but can deploy only one resource unit on each node. The resource units of a tenant are independent of each other. At present, OceanBase Database does not summarize the resource usage information of resource units for global resource control. In other words, if the resources of a tenant on a node are insufficient, the tenant cannot contend for resources of another tenant on another node.
In resource isolation, a node controls the allocation of resources between local resource units. Similar technologies are Docker containers and VMs. However, OceanBase Database does not rely on Docker containers or VMs but isolates resources within the database.
OceanBase Database implements the isolation and management of resources between tenants, such as CPU, memory, and input/output operations per second (IOPS). However, different users and background tasks in the same tenant also require resource isolation. For example, background migration or major compaction tasks should not occupy excessive resources to avoid affecting business. In addition, large queries should not affect the response time in transaction processing.
Concept
Control group (cgroup) is a mechanism provided by the Linux kernel to aggregate or divide, based on specialized behavior, a series of tasks and their subtasks into different groups that are graded based on resources, thereby providing a unified framework for system resource management.
In the current OceanBase Database version, the worker threads and most background threads are identified by partition, and network threads are shared. In this case, you can use your administrator account to configure cgroup directories and then use the resource isolation feature to control the CPU utilization and IOPS of tenants.
Maintenance elements
The resource isolation feature of OceanBase Cloud Platform (OCP) is used to maintain the following elements:
Resource groups: A resource group is a collection of sessions that are grouped based on resource requirements. The system allocates resources to a resource group rather than to individual sessions.
Resource management plans: A resource management plan is a container of plan directives and specifies how resources are allocated to resource groups. You can activate a specific resource management plan to control the allocation of resources. A resource management plan can contain multiple resource management plan configs. However, a resource management plan must not contain two identical resource management plan configs.
Plan directives: A plan directive associates a resource group with a resource management plan and specifies how resources are allocated to this resource group.
Resource isolation types
OCP supports three resource isolation types:
User-level resource isolation
After the mapping between a user and a resource group is specified, all SQL statements executed by the user can use only the resources in the resource group mapped to this user. This way, you can designate different users to perform different types of tasks.
Background task-level resource isolation
After the mapping between a type of background tasks and a resource group is specified, resources are isolated for these tasks. At present, resource isolation is supported for eight types of background tasks.
compaction_high: mini merge and DDL KV merge tasks
ha_high: tasks with high priorities and requiring high reliability, such as replication, rebuild, and recovery tasks
compaction_mid: minor merge tasks
ha_mid: tasks with medium priorities and requiring high reliability, such as migration tasks
compaction_low: major merge tasks
ha_low: tasks with low priorities and requiring high reliability, such as backup and backup cleanup tasks
ddl: tasks that are performed in scenarios such as unique index verification and data completion upon column deletion.
ddl_high: minor compactions for DDL MemTables
SQL statement-level resource isolation
SQL statement-level resource isolation is more fine-grained than user-level resource isolation. If multiple accounts exist in the business system, when an order of an account is processed, a transaction is enabled to execute a batch of SQL statements related to this account. Generally, the account is specified in the WHERE clause. Different accounts may involve different amounts of data. If accounts involving a large amount of data use up the CPU resources, the orders of accounts involving a small amount of data cannot be processed. You can bind SQL statements for processing different orders with different resource groups. In this way, SQL statements for different orders can use resources in different resource groups.