This topic describes resource isolation-related concepts, resource isolation types, and application scenarios.
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, tenant worker threads and most backend threads are tenant-specific, and network threads are shared. After the cgroup directory is configured, the administrator can control the CPU utilization and I/O operations per second (IOPS) of tenants by using the DBMS_RESOURCE_MANAGER package.
DBMS_RESOURCE_MANAGER package
In OceanBase Database, the procedural language (PL) package DBMS_RESOURCE_MANAGER is used to manage resource allocation in a database to implement resource isolation. The DBMS_RESOURCE_MANAGER package 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 plan directives. However, a resource management plan must not contain two identical plan directives.
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
OceanBase Database supports the following resource isolation types based on the resource usage granularity:
User-level resource isolation
User-level resource isolation is further categorized into user-based resource isolation and function-based resource isolation. Note that:
User-based resource isolation: specifies the mapping between a user and a resource group. All SQL statements executed by the specified user can use only the resources in the resource group mapped to this user. In this way, you can enable different users to perform different types of tasks.
Function-based resource isolation: specifies the mapping between a backend task and a resource group. In this way, resources are isolated for different tasks. At present, you can control the resources available for the backend tasks corresponding to the directed acyclic graph (DAG) thread.
The DAG thread corresponds to the following eight types of backend 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.