深入OceanBase内部机制：资源隔离实现的方式总结

码到三十五： 个人主页
心中有诗画，指尖舞代码，目光览世界，步履越千山，人间尽值得 !

- - 1. 为何HTAP需要资源隔离
  - 2. OceanBase的资源隔离机制概述
  - - 租户间资源隔离
    - 租户内资源隔离
    - 物理资源隔离
    - 大查询请求的隔离
    - 优先级调度
  - 3. 物理机器隔离
  - 4. 租户隔离
  - - 4.1 租户间资源隔离
    - - CPU隔离
      - 基于线程数的租户工作线程的 CPU 隔离
      - 基于 cgroup 的租户工作线程的 CPU 隔离
      - 内存隔离
      - IOPS 隔离
      - 验证磁盘 IO 隔离能力的实例
    - 4.2 租户内隔离
  - 5. 大查询队列
  - 总结

凭借卓越的高并发事务实时处理能力和对大规模数据实时业务决策的强大支持，HTAP技术已崛起为企业提升数据价值挖掘效率、显著降低总成本的首选方案。伴随着国内需求的迅猛增长，专注于HTAP的数据库正由初露锋芒逐渐发展为行业的主流趋势。

在HTAP领域，国产自研的原生分布式数据库OceanBase已经深耕了12年。HTAP数据库为实现不同租户之间以及同一租户内部OLTP和OLAP业务的硬件资源共享，对资源隔离技术提出了极高的要求。而针对HTAP数据库，最佳的资源隔离策略是采用物理隔离与逻辑隔离相结合的方式，二者相辅相成，共同确保系统的高效稳定运行。

1. 为何HTAP需要资源隔离

资源隔离并非新概念，在传统的物理资源隔离方案中，不同租户或同一租户内的OLAP和OLTP业务使用各自独立的副本，即行存副本专为OLTP设计，而列存副本则服务于OLAP，确保两者在物理资源上互不干扰。在不考虑成本因素的前提下，这种物理资源隔离方式无疑是最佳选择。

然而，在实际情况中，多数客户在考虑硬件成本和资源利用率时，更倾向于采用逻辑资源隔离方案，它允许不同租户或同一租户内的OLAP和OLTP共享物理资源。因此，适合HTAP的资源隔离策略并非仅限于物理或逻辑隔离，而是在两者间寻求最佳平衡。

基础软件应赋予用户更多选择自由，使其在各种场景下都能做出最适合自己的决策。因此，数据库产品应具备同时提供物理隔离和逻辑隔离等多级资源隔离能力的必要性。

2. OceanBase的资源隔离机制概述

OceanBase的资源隔离机制是一种技术和管理策略，旨在确保在OceanBase数据库系统中，不同租户、用户或查询之间在资源使用上实现有效的隔离，从而防止单一租户、用户或查询对整个系统或其他租户造成资源上的不公平占用或性能影响。这种机制有助于维护数据库系统的稳定性和性能，同时确保数据的安全性和隐私性。

在这里插入图片描述

OceanBase的资源隔离机制主要包括以下几个方面：

租户间资源隔离

每个租户在OceanBase中拥有独立的资源配额，如CPU、内存、存储等，确保租户之间在资源使用上互不干扰。
租户间的数据是完全隔离的，保证了数据的安全性和隐私性。

租户内资源隔离

在租户内部，可以进一步实现用户之间的资源隔离，通过为每个用户或用户组配置独立的资源限制，防止单一用户过度占用资源。
SQL级别的资源隔离允许对特定的查询或操作进行资源限制，以防止某些耗资源的查询影响到其他查询或操作的性能。

物理资源隔离

OceanBase可以部署在多个物理节点上，通过分布式架构实现物理资源层面的隔离。不同的租户可以被部署在不同的物理节点或服务器上，从而实现硬件资源的完全隔离。

大查询请求的隔离

对于可能消耗大量资源的查询请求，OceanBase具有相应的隔离和限制机制。例如，系统可以检测并限制那些可能对系统性能产生负面影响的查询，确保其他正常查询和服务不受影响。

优先级调度

OceanBase还支持基于优先级的资源调度，允许为高优先级的租户、用户或查询分配更多的资源，以确保关键业务的高可用性和响应速度。

通过这些多层次的资源隔离机制，OceanBase能够提供一个稳定、高效且安全的数据库服务环境，满足不同租户和用户的需求，同时保证系统的整体性能和可靠性。

3. 物理机器隔离

每个租户可以通过使用不同的服务器，来保证资源层面完全不会有任何影响。默认情况下，如果每个ZONE 有多个OBServer，那么OB会根据租户UNIT的资源配置将其均分到多个OBServer内，当然这个过程对于使用者来说是透明的，无需关注。

但是如果想要自定义UNIT到对应的节点上，也就是不同租户占用不同的机器，那么就需要关闭OB本身的均衡和迁移能力，比如关闭 enable_rebalance 和 enable_transfer，然后通过 ALTER SYSTEM MIGRATE UNIT 手动迁移UNIT 到想要的节点上，通过 ALTER SYSTEM TRANSFER PARTITION 语句用于将指定分区的迁移至指定的日志流。

这种方式可以按照自己需求来自定义分配，但是除非对OB有非常强的掌控力，否则不建议这个操作。因为这样操作以后，OB本身的负载均衡和迁移能力将不会再发挥作用。

4. 租户隔离

租户隔离分为租户间的隔离和租户内的隔离。

租户间主要是通过指定UNIT配置，给到这个租户对应的资源大小以及权重，然后OB 会根据配置调度整个实例的资源给到不同的租户。租户内的隔离主要分为用户资源隔离和SQL资源隔离，通过配置用户和SQL的资源来对租户内的资源进行分配及隔离。

4.1 租户间资源隔离

咱们熟知的物理资源一般可以分为两类：一类是弹性资源，比如CPU，磁盘带宽等；另一类是刚性资源，比如内存，磁盘空间等。弹性资源是可以抢占的，刚性资源一旦被占用，除非占有者主动释放，否则是无法抢占的。

租户间资源隔离包含了弹性资源以及刚性资源，比如CPU、IOPS以及内存与磁盘空间，通过UNIT划分控制。

CPU隔离

CPU的隔离通过UNIT CONFIG中的MIN_CPU和MAX_CPU来配置，可以通过配置最小占用、最大占用以及可选择性的开启超卖来实现。

OB的CPU隔离主要有两种方式：基于线程数和基于Cgroup。

基于线程数的租户工作线程的 CPU 隔离

OBServer 最基础的CPU隔离是通过用户态调度，控制活跃线程数来实现的。每个租户有独立的线程池，线程池的规格是由租户规格和一些配置参数来决定的。

在这里插入图片描述

由于 SQL 执行过程中可能会有 IO 等待、锁等待等，所以一个线程无法用满一个物理 CPU，故在缺省配置下，OBServer 节点会给每个 CPU 启动 4 个线程，4 这个倍数可以通过配置 cpu_quota_concurrency 来控制。这就意味着如果一个 Unit 的 MAX_CPU 是 10，那么它能同时运行的活跃线程是 40，最大物理 CPU 的占用是 400%。

但是这种方式的隔离存在一些问题，就是只能限制线程数但是不能完全限制CPU使用率，因为每个线程对CPU的占用这个不可控，所以只能做软隔离。

基于 cgroup 的租户工作线程的 CPU 隔离

OBServer 也支持配置 cgroup 来实现 CPU 的隔离优化。cgroup 能对线程的 CPU 使用率进行精准的限制，达到租户之间 CPU 强隔离的效果。
在这里插入图片描述

observer
  ├── tenant1
  │   └── tasks
  │         ├── thread1
  │         ├── thread2
  │         └── ...
  ├── tenant2
  │   └── tasks
  │         ├── thread1
  │         ├── thread2
  │         └── ...
  └── other

开启 cgroup 后最大的变化是不同租户的工作线程放到不同的 cgroup 目录内，租户间的 CPU 隔离效果会更好。最后的隔离效果如下：

如果一个 OBServer 上只有一个租户负载很高，其余租户比较空闲，那么这个负载高的租户的 CPU 也会受到 MAX_CPU 的限制。
延续上面的场景，如果有多个空闲的租户的负载上升了，导致物理 CPU 不够了，cgroup 会按照权重分配时间片。
cgroup 方式可以做到硬隔离，因为可以严格控制每个租户的cpu使用率，所以可以更好的保证cpu之间相互不影响，尤其是在不超卖的情况下。4.2.x版本以后，通过OCP创建的集群，默认会使用cgroup做CPU隔离。

内存隔离

内存空间等资源属于刚性资源，因为这类资源的描述是标量，一块内存被 A 占用了，就不能再分配给 B 使用。所以对于内存隔离就不过多赘述了。

IOPS 隔离

OBServer 内所有的 IO 都是异步 IO，并且是绕过 OS 的 direct IO，磁盘带宽（IOPS）的隔离是通过控制 OBServer 提交异步 IO 的时间间隔来实现的。

OBServer 的 IO隔离没有借助cgroup，而是自研实现的，底层算法可以简单理解为多个租户共用一组io线程，所有租户都根据IO线程来分配资源以及执行租户IO队列中的IO请求，所以不同租户之间的IO请求正常情况下没有冲突，也能通过IO线程保证各个租户IOPS的使用量。

租户的IOPS受三个配置影响，MIN_IOPS、MAX_IOPS 和 IOPS_WEIGHT。

OBServer 内部会统一按照 16 KB 读的 IOPS 值作为有效值进行处理，所以建议MIN_IOPS和MAX_IOPS 根据当前磁盘计算出来的 16KB读对应的值来配置。MIN_IOPS总和建议不超过机器磁盘的IOPS，MAX_IOPS可以根据实际情况配置，可以超过。MAX_IOPS需要大于等于MIN_IOPS，如果没有指定具体的值，那么MIN_IOPS 和 MAX_IOPS 的值均为 INT64_MAX。

多租户之间的资源分配与抢占可以总结为一句话：闲时共享，忙时隔离。空闲带宽可以给有需求的租户或io类别共享，但忙碌时，需要按weight的比例隔离。

举个例子，如果磁盘IO的IOPS为10000，其中，

租户A，MIN_IOPS：4000，MAX_IOPS：8000

租户B，MIN_IOPS：6000，MAX_IOPS：10000

假设两个租户当前使用的IOPS都能达到设置的 MIN_IOPS的值，他们只会占用各自 MIN_IOPS 的 IOPS 大小，因为已经达到了磁盘本身IOPS的上限。如果租户 A 现在只用了2000，租户B是可以挤占的，比如用到8000的 IOPS。当租户A需要的时候，它会挤占回来，以满足MIN_IOPS的需求，并且这个优先级最高。

所以说，如果租户B需要的IOPS是1w，但是租户A至少也需要4000的IOPS，那么这个时候租户B是会受到影响的，因为当前场景下IO是不满足需求的，所以说对于IO也要提前做好规划，如果单台机器的IO满足不了需求可以通过扩容机器的方式来满足。

如果磁盘IO的IOPS为12000，那么剩余的这2000IOPS 租户AB需要使用的话如何分配则根据IOPS_WEIGHT来做权重。

验证磁盘 IO 隔离能力的实例

为了验证磁盘 IO 隔离的能力，我们首先用单测做了一项仿真实验：我们设置 4 个租户，每个租户启动 64 个线程发送 IO 请求，IO 请求固定为 16KB 随机读，租户 1、2、4 的负载持续 20 秒，租户 3 的负载从第 10 秒开始，持续 10 秒。实验磁盘 IOPS 上限大概在 6w，如果不加限制，任意一个租户单独都可以打满磁盘。

首先验证租户间磁盘 IO 隔离，各租户的配置和实验结果如表 1 和图 1 所示：

磁盘已经打满时，新加入的租户 3 依然拥有 1 万 IOPS，因为其通过 MIN_IOPS 预留了 1 万；
租户 4 的 IOPS 没有超过 5 千，因为其通过 MAX_IOPS 设置了资源上限；
无论负载如何变化，租户 1 和租户 2 的 IOPS 比值大概为 2:1，正如权重比例要求。

4.2 租户内隔离

租户内资源隔离通过DBMS_RESOURCE_MANAGER系统包的CREATE_PLAN_DIRECTIVE接口进行配置，会对资源使用组的CPU和IO资源进行限制

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
    plan                      IN VARCHAR2, 
    group_or_subplan          IN VARCHAR2, 
    comment                   IN VARCHAR2 DEFAULT'', 
    mgmt_p1                   IN NUMBER   DEFAULT 100,
    utilization_limit         IN NUMBER   DEFAULT 100,
    MIN_IOPS                  IN NUMBER   DEFAULT 0,
    MAX_IOPS                  IN NUMBER   DEFAULT 100,
    WEIGHT_IOPS               IN NUMBER   DEFAULT 0,
);

其中，utilization_limit 表示CPU 资源使用比例上限。MIN_IOPS、MAX_IOPS和WEIGHT_IOPS用来配置管理IOPS。

目前支持配置租户内用户级和SQL 级的资源隔离，配置的方法可以参考官网：

配置用户级资源隔离：

https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000220910

配置SQL 级资源隔离：

https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000220909

5. 大查询队列

除了上面提到的方式，其实OB还支持大查询队列。

默认情况下，如果TP业务请求的数据库，突然过来AP相关的请求，很有可能会影响到TP的业务甚至整个集群的访问，所以为了避免这类问题，OB提供了一个大查询队列，这个大查询队列默认情况下只会占用 30% 的CPU资源，大查询判断的条件默认为执行时间超过 5s。对于后面进来的大查询，如果在计划缓存中存在，并且预估执行时间超过5s，那么会直接判断它是大查询，然后放到大查询队列中。以此来避免问题SQL或者AP查询对TP业务的影响。

在这里插入图片描述