Resource isolation overview

This topic provides an overview of resource isolation, including the concepts, methods, and application scenarios.

cgroup

Control group (cgroup) is a mechanism provided by the Linux kernel. This mechanism can integrate (or separate) a series of tasks and their subtasks into different groups according to resource division levels, thereby providing a unified framework for system resource management.

In OceanBase Database V4.2.1, worker threads and most background threads are identified by tenant, while network threads are shared threads. After configuring the cgroup directory, the administrator can control the CPU and IOPS usage through the DBMS_RESOURCE_MANAGER system package.

DBMS_RESOURCE_MANAGER system package

In OceanBase Database, the PL's DBMS_RESOURCE_MANAGER system package is used to manage resource allocation in the database to achieve resource isolation. This package is mainly 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.

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