Overview

This topic introduces 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 OceanBase Database V4.2.0, worker threads and most background threads are identified by tenant, and network threads are shared. If you are an administrator, you can configure the cgroup system directory and then use the DBMS_RESOURCE_MANAGER package to control the CPU and input/output operations per second (IOPS) resource usage of tenants.

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 resource management plan configs 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.

• Resource management plan config: A resource management plan config associates a resource group with a resource management plan and specifies how resources are allocated to this resource group.

For more information about the DBMS_RESOURCE_MANAGER package, see DBMS_RESOURCE_MANAGER (Oracle mode) and DBMS_RESOURCE_MANAGER (MySQL mode).

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. Take note of the following items:

  • 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.