OceanBase 为什么要多一层 Unit 和 ResourcePool?Tenant 直接分 CPU 内存不行吗?多租户资源模型一次讲透

很多 Oracle DBA 第一次碰 OceanBase 资源管理都会懵：既然最终都是给 Tenant 分 CPU、内存、IOPS，为什么不直接配置给 Tenant，中间还要多 Unit 和 Resource Pool 两层？第一反应往往是"OceanBase 把简单问题搞复杂了"。

真相恰恰相反：Unit 和 Resource Pool 正是 OceanBase 能同时搞定"资源隔离、资源规格、资源数量、节点放置、扩缩容、负载均衡"的关键。

官方文档把资源规格（DBA_OB_UNIT_CONFIGS）、资源池（DBA_OB_RESOURCE_POOLS）、资源单元（DBA_OB_UNITS）、租户（DBA_OB_TENANTS）四张视图拆得清清楚楚。

这篇用 18 张手绘 ASCII 架构图，从"为什么不直接给 Tenant 分资源"讲起，把「Unit 是资源落地、Resource Pool 是资源组织」这条主线一次讲透，让你再看 DBA_OB_UNITS / UNIT_NUM / ZONE_LIST 不再发懵。

很多 Oracle DBA 第一次接触 OceanBase 的资源管理时，都会有一个很自然的问题：既然最终都是给 Tenant 分 CPU、内存、IOPS，为什么不直接把资源配置给 Tenant？为什么中间还要设计 Unit 和 Resource Pool 两层？

甚至第一次看到：

复制代码

Tenant   ↓Resource Pool   ↓Unit

很多人会觉得这是"人为把简单问题复杂化了"。

实际上恰恰相反。

Unit 和 Resource Pool 的存在，是 OceanBase 多租户架构能够同时解决"资源隔离、资源规格、资源数量、节点放置、扩缩容和负载均衡"的关键。

如果把这两个概念真正理解了，OceanBase 的租户资源模型基本就通了。

先不要急着记概念，先想一个问题

假设一台服务器有：

复制代码

CPU      32 CoreMemory   128 GB

现在集群里有两个租户：

复制代码

Tenant A：核心交易业务Tenant B：报表业务

我们希望：

复制代码

Tenant A    CPU     8 Core    Memory  32 GBTenant B    CPU     4 Core    Memory  16 GB

最直接的设计当然是：

复制代码

Tenant A → 8C / 32GTenant B → 4C / 16G

看起来完全够用。

但是数据库真正运行起来以后，问题马上出现：

问题一：这个 8C / 32G 是"规格"还是"实际资源"？

例如：

复制代码

8C / 32G

到底表示：

Tenant A 应该拥有 8C/32G？
一个节点上的 8C/32G？
Tenant A 在每个节点都拥有 8C/32G？
还是整个 Tenant 总共 8C/32G？

如果不把"资源规格"和"资源实例"拆开，定义马上就会变得模糊。

OceanBase 实际上把

三个问题拆开了

理解 OceanBase 资源模型，建议不要只看：

复制代码

TenantResource PoolUnit

而是完整地看：

复制代码

Unit Config     ↓Resource Pool     ↓Unit     ↓Tenant

分别回答四个问题：

OceanBase 官方文档也明确将资源规格、资源池、资源单元和租户分别定义，并分别对应 DBA_OB_UNIT_CONFIGS、DBA_OB_RESOURCE_POOLS、DBA_OB_UNITS 和 DBA_OB_TENANTS。

所以真正应该理解成：

复制代码

                 Tenant                    │          使用哪些资源？                    │                    ▼             Resource Pool          ┌─────────┴─────────┐          │                   │       Unit 1              Unit 2          │                   │       8C/32G              8C/32G          │                   │       OBServer             OBServer

而：

复制代码

8C / 32G

这个"8C / 32G"本身，又来自：

复制代码

Unit Config

第一层：Unit 到底是什么？

先回答最核心的问题：Unit 不是一个抽象的数字，而是 OceanBase 真正进行资源分配和隔离的基本单元。

官方文档将 Unit 定义为租户管理中非常重要的概念，Unit 是 CPU、内存、存储空间、IOPS 等资源的集合；同时它还具有节点、Zone、Region 等位置属性，并作为资源调度的基本单位。

可以把它理解成：Unit = 一份真正被放到某个节点上的数据库资源容器。

例如：

复制代码

Unit Config名称：S1CPU：4 CoreMemory：8 GBIOPS：10000

这只是一个"规格"。

真正创建出来以后：

复制代码

OBServer 01   │   └── Unit 101       ├── CPU 4C       ├── Memory 8G       └── IOPS 10000

这个时候，才真正产生了一份资源。

所以：

复制代码

Unit Config ≠ Unit

这是第一层非常重要的认知。

Unit 为什么不能直接等同于 Tenant？

因为一个 Tenant 可能需要多个 Unit。

例如一个租户：

复制代码

Tenant A

可能部署在三个节点：

复制代码

OBServer 01    └── Unit A1OBServer 02    └── Unit A2OBServer 03    └── Unit A3

三个 Unit 可以拥有相同规格：

复制代码

A1 = 4C / 8GA2 = 4C / 8GA3 = 4C / 8G

那么 Tenant A 实际使用的资源就是多个 Unit 的集合。

OceanBase 官方文档明确说明，一个租户可以在多个节点上放置多个 Unit，但一个租户在同一个节点上只能有一个 Unit；Unit 是节点本地资源隔离的基本单位。

因此：

复制代码

Tenant  │  ├── Unit  ├── Unit  └── Unit

这是非常重要的关系。

那么 Resource Pool 又是干什么的？

这里才是很多 DBA 真正容易困惑的地方。

如果 Unit 已经代表资源了，为什么还要 Pool？

答案是：Unit 解决"资源实例"，Resource Pool 解决"这一组 Unit 应该如何组织和分配"。

Resource Pool 本质上把几个重要信息绑定在一起：

复制代码

Resource Pool      │      ├── Unit Config      │      ├── Unit 数量      │      └── Zone 范围

例如：

复制代码

CREATE RESOURCE POOL pool_aUNIT = 'S1',UNIT_NUM = 2,ZONE_LIST = ('zone1');

它表达的不是：创建一个资源。

而是：在 zone1 中，按照 S1 这个规格创建 2 个 Unit。

OceanBase 官方文档对 CREATE RESOURCE POOL 的定义也是：资源池描述可以分配给租户的资源单元集合；资源池中的 Unit 规格由 UNIT 指定，UNIT_NUM 指定每个目标 Zone 中创建的 Unit 数量，ZONE_LIST 指定资源池的 Zone 范围。

这时候就能看出：Pool 和 Unit

解决的是两个完全不同的问题

例如：

复制代码

Unit ConfigS14C / 8G

然后：

复制代码

Resource Poolpool_AUNIT      = S1UNIT_NUM  = 2ZONE_LIST = zone1

最终形成：

复制代码

                  Resource Pool                     pool_A                       │                 ┌─────┴─────┐                 │           │              Unit A1     Unit A2                 │           │              4C / 8G     4C / 8G                 │           │            OBServer 01   OBServer 02

所以：

Unit 回答："这一份资源在哪里？"

Pool 回答："这一组资源按照什么规格、多少份、放在哪些 Zone？"

这就是为什么必须拆成两层。

如果没有 Resource Pool，会发生什么？

我们可以做一个反向推导。

假设 OceanBase 只有：

复制代码

Tenant   ↓Unit

那么创建 Tenant 时可能需要直接描述：

复制代码

Tenant ACPU       = 4Memory    = 8GUnit Num  = 2Zone      = zone1

如果未来又出现：

复制代码

Tenant Azone1 → 4C / 8Gzone2 → 8C / 16G

那么 Tenant 层就必须开始管理：

复制代码

规格+数量+Zone+Unit

更麻烦的是，一个 Tenant 可能还需要多个资源池。

Resource Pool 真正解决的是"资源组织"

例如一个租户：

复制代码

Tenant A

可能有两个 Resource Pool：

复制代码

Tenant A│├── Pool 1│     ├── Zone 1│     └── Zone 2│└── Pool 2      └── Zone 3

每个 Pool 又可以对应自己的 Unit 规格和数量。

因此：

复制代码

Tenant   │   ├──────── Resource Pool 1   │              │   │              ├── Unit   │              └── Unit   │   └──────── Resource Pool 2                  │                  ├── Unit                  └── Unit

所以 Pool 并不是简单的"Unit 分组"。

它实际上承担的是：把资源规格、资源数量和资源部署范围组织成一个可以分配给 Tenant 的资源集合。

为什么不能直接让 Tenant 绑定 Unit？

这是理解设计思想最关键的一步。

假设：

复制代码

Tenant A

直接绑定：

复制代码

Unit 1Unit 2Unit 3

那么谁来回答：

复制代码

这三个 Unit 是不是同一种规格？

谁来回答：

复制代码

应该在几个 Zone 创建？

谁来回答：

复制代码

每个 Zone 创建几个？

谁来回答：

复制代码

这个租户的这一组资源应该作为一个整体管理吗？

如果全部交给 Tenant，Tenant 就会承担：

复制代码

资源规格管理+资源实例管理+节点部署管理+Zone管理+资源数量管理

最终 Tenant 和底层资源管理高度耦合。

OceanBase 的设计选择是：

复制代码

Tenant   │   │ 使用   ▼Resource Pool   │   │ 生成/组织   ▼Unit   │   │ 使用规格   ▼Unit Config

每一层只负责自己的事情。

从 DBA 角度，可以把它类比成"模板---资源池---实例"

如果你是传统数据库 DBA，可以暂时用一个比较容易理解的模型：

复制代码

Unit Config    ↓"资源规格模板"Resource Pool    ↓"按照这个模板，准备多少份资源，放到哪些 Zone"Unit    ↓"真正落到节点上的资源实例"Tenant    ↓"最终使用这些资源的数据库服务"

因此：

复制代码

Unit Config    = WhatResource Pool    = How many + WhereUnit    = Actual resourceTenant    = Who uses it

这个模型非常适合教学。

为什么 OceanBase 不直接做成

"Tenant → Resource"？

因为 OceanBase 的目标不是单纯给一个数据库实例分配资源。

它需要解决的是：一个集群中多个租户如何共享基础设施，同时保持资源隔离，并能够进行扩展、迁移和负载均衡。

官方文档明确指出，OceanBase 的 Unit 是资源分配和资源隔离的基本单位；一个节点可以存在多个 Unit，每个 Unit 占用节点的一部分 CPU、内存等物理资源，租户之间通过 Unit 实现资源隔离。

因此它的核心思想实际上是：

复制代码

                   Cluster                      │          ┌───────────┴───────────┐          │                       │      Tenant A                Tenant B          │                       │       Pool A                   Pool B          │                       │      ┌───┴───┐               ┌───┴───┐      │       │               │       │    Unit    Unit            Unit    Unit      │       │               │       │     4C/8G  4C/8G           8C/16G 8C/16G      │       │               │       │    Node1   Node2            Node1   Node2

同一个物理节点上：

复制代码

Node1│├── Tenant A / Unit A1│      4C / 8G│└── Tenant B / Unit B1       8C / 16G

这时候，Unit 才是资源隔离真正落地的地方。

Unit 为什么又是 OceanBase 扩展能力的基础？

这一点非常重要。

传统数据库往往是：

复制代码

数据库实例     ↓加 CPU加内存     ↓继续扩容

最终会遇到：单机容量上限。

而 OceanBase 的 Unit 天然带有位置属性。

因此：

复制代码

一个 Unit     ↓一个节点上的资源

当一个 Tenant 从：

复制代码

1 Unit

扩展到：

复制代码

2 Unit

就可以进一步利用多个节点的资源。

官方文档也明确指出，Unit 是集群扩展和负载均衡的基本单位；对于单 Unit 租户，如果遇到容量瓶颈，可以通过扩展为多 Unit 利用多节点资源。

所以：Unit 不只是"资源隔离单位"，同时还是 OceanBase 水平扩展的重要基础。

为什么 Pool 对扩容同样重要？

例如现在：

复制代码

Tenant A    │    └── Pool A          │          ├── Unit 1          └── Unit 2

如果需要扩展资源，本质上可以理解为：

复制代码

每一层只负责自己的事情。

也就是：

Pool │ └── 管理一组具有共同资源属性和部署规则的 Unit

因此 OceanBase 才能够把：

复制代码

资源规格资源数量资源位置资源实例租户

资源规格资源数量资源位置资源实例租户分别管理。

这两层还有一个非常

重要的价值：资源隔离

OceanBase 官方文档对资源隔离的描述非常明确。

一个节点可以创建多个 Unit，每个 Unit 会占用该节点的一部分 CPU、内存等资源；资源隔离是节点本地的资源控制行为。

官方文档还明确说明，内存、CPU，以及部分 SQL、事务、Clog 等模块存在租户间隔离机制。所以从 DBA 的角度：

复制代码

Node│├── Unit A│     └── Tenant A│├── Unit B│     └── Tenant B│└── Unit C      └── Tenant C

这实际上是在做：把一个大的物理服务器切成多个数据库资源边界。

这就是 OceanBase 多租户真正有价值的地方。

最终把四层关系一次性看懂

到这里，可以把整个模型压缩成下面这张图：

复制代码

                   OceanBase Cluster                           │                           ▼                        Tenant                           │                  使用 Resource Pool                           │             ┌─────────────┴─────────────┐             │                           │        Resource Pool A             Resource Pool B             │                           │       ┌─────┴─────┐                 ┌───┴────┐       │           │                 │        │     Unit        Unit              Unit     Unit       │           │                 │        │       ▼           ▼                 ▼        ▼    OBServer    OBServer          OBServer OBServer       │       └────── 每个 Unit 使用一个 Unit Config ──────┘                         │                         ▼                  4C / 8G / IOPS

对应关系就是：

复制代码

Unit Config    ↓定义"每份资源多大"Resource Pool    ↓定义"需要多少份、在哪些 Zone"Unit    ↓真正创建出来的资源实例Tenant    ↓最终使用这些资源的数据库服务

所以为什么一定要有 Unit + Pool？

现在可以直接回答最开始的问题。

如果只有 Unit

你只能比较容易表达："我有一份资源。"

但很难优雅地表达："我要按照这个规格，在这些 Zone 上创建这么多份资源，并把这一整组资源作为一个资源集合交给某个租户。"

如果只有 Pool

你可以描述："我要一组资源。"

但必须有真正落地的资源实例，才能知道：

复制代码

到底占用了哪个节点的多少 CPU？哪个节点的多少内存？这个资源单元在哪里？

因此：

复制代码

Pool = 资源组织Unit = 资源落地

两者缺一不可。

站在 Oracle DBA 的角度，应该怎么理解？

如果从传统 Oracle DBA 思维切换到 OceanBase，可以这样建立映射：

复制代码

Oracle                         OceanBaseInstance                  Tenant   │                         │   │                    Resource Pool   │                         │   │                       Unit   │                         │Server CPU/Memory       Physical Resource

但这里不要机械地做一一对应。

OceanBase 的 Tenant 并不是简单的 Oracle Instance 替代物，Unit 也不是传统意义上的 Instance。

更准确的理解是：OceanBase 把"数据库服务"和"底层物理资源管理"进行了显式解耦。

传统数据库 DBA 更容易关注：

复制代码

数据库    ↓进程    ↓CPU / Memory / IO

这也是为什么刚接触 OceanBase 时，会觉得资源模型比传统数据库复杂。

实际上不是"复杂了一层"。

而是：OceanBase 把传统数据库里很多隐含的资源管理关系显式化了。

最重要的一句话

如果这篇文章只记住一句话，我建议记住：Unit 解决"资源如何真正落地"，Resource Pool 解决"这些资源如何被组织并分配给租户"。

进一步展开就是：

复制代码

Unit Config    ↓一份资源是什么规格？Resource Pool    ↓需要多少份？部署在哪些 Zone？Unit    ↓这些资源实际落在哪个节点？Tenant    ↓谁最终使用这些资源？

所以 OceanBase 的资源模型并不是：

复制代码

Tenant  ↓分 CPU、内存

而是：

复制代码

                    Tenant                       │                       ▼               Resource Pool              /       |       \             /        |        \          Unit      Unit      Unit            \         |         /             \        |        /                Physical Resource

这套设计的核心价值，就是把"资源规格、资源集合、资源实例、数据库服务"四个不同的问题拆开管理。

一旦理解这一点，后面再学习：

复制代码

DBA_OB_UNIT_CONFIGS

DBA_OB_RESOURCE_POOLS

DBA_OB_UNITS

DBA_OB_TENANTS

UNIT_NUM

ZONE_LIST

租户扩容
Unit 迁移
资源均衡
CPU / Memory / IOPS 隔离

就不再是单纯背概念，而是能沿着一条完整的架构逻辑理解。

写在最后

这篇文章只记一句话就值：

① Unit 解决"资源如何真正落地"，是节点本地资源隔离的基本单位；

② Resource Pool 解决"这些资源如何被组织并分配给租户"，把 Unit Config + UNIT_NUM + ZONE_LIST 绑成一组可整体交付的资源集合；

③ Pool = 资源组织，Unit = 资源落地，两者缺一不可，缺了任一层 Tenant 都会和底层资源管理高度耦合。

落到 DBA 视角：Unit 不只是资源隔离单位，还是 OceanBase 水平扩展的基础------单 Unit 租户遇容量瓶颈，扩成多 Unit 就能吃多节点资源；而 Pool 把"规格+数量+Zone"组织好，避免 Tenant 层越来越臃肿。

传统 Oracle 的"Instance ≈ 数据库服务"在 OB 里被显式解耦成 Tenant → Resource Pool → Unit → Physical Resource 四层，看似多一层，实则是把隐含的资源管理关系讲明白了。

安呀智数据坊｜我们能做什么

无论你是业务系统的技术负责人，还是数据部门的第一响应人，我们都能为你提供可靠的支持：

数据库类型支持

Oracle / MySQL / PostgreSQL / SQL Server 等主流数据库

核心服务内容

性能优化 / 故障处理 / 数据迁移 / 备份恢复 / 版本升级 / 补丁管理

系统性支持

深度巡检 / 高可用架构设计 / 应用层兼容评估 / 运维工具集成

专项能力补充

定制课程培训 / 甲方团队辅导 / 复杂问题协作排查 / 紧急救援支持

【安呀智数据坊·应急响应中心】

数据库故障往往发生在那 1% 的不可控时刻。

如果你正面临生产库崩溃、误操作导致数据丢失，且通过常规手段无法解决，请直接联系我们。

服务承诺： 我们秉承**"问题解决为先，方案闭环为本"**的服务理念。

安全底线： 全程签署企业级保密协议（NDA），保障数据安全是我们的第一铁律。

技术支援： 拥有 Oracle ACE 专家带队的"十五年数据库急诊"团队。

本文涉及关键词：

OceanBase Unit、OceanBase Resource Pool、OceanBase 多租户、DBA_OB_UNITS、DBA_OB_RESOURCE_POOLS、DBA_OB_UNIT_CONFIGS、DBA_OB_TENANTS、UNIT_NUM、ZONE_LIST、Unit Config、OceanBase 资源隔离、OceanBase 租户扩容、OBServer、OceanBase 资源管理、Tenant 资源模型、节点放置、负载均衡、OceanBase 架构、Unit 迁移、资源池、Oracle DBA 学 OceanBase、多租户资源模型

大家好，我是刘峰，安丫科技创始人，一名专注数据库实战的技术讲师与顾问。

我拥有 Oracle OCM 和 PostgreSQL ACE 双认证 ，同时是 PostgreSQL 中国分会官方授权讲师。

技术栈覆盖主流商业库 Oracle、SQL Server、MySQL，开源库 PostgreSQL，以及国产数据库 OceanBase、达梦、瀚高等产品。

过去十余年，我深度参与了电信、金融、政务、制造、互联网等多个行业的数据库项目。

完整经历过从传统 Oracle、MySQL 架构向 PostgreSQL、分布式数据库、国产信创库的技术演进与迁移实战。

项目交付内容涵盖数据库安装部署、备份恢复、巡检监控、高可用建设、性能调优、版本升级、异构迁移以及运维规范建设等多个方向。

在性能优化与故障诊断方面，我积累了大量实战经验。

从慢查询诊断、执行计划分析、索引优化、参数调优，到故障根因定位、应急处理，能够快速定位问题并给出可落地的解决方案。

特别是在跨数据库平台的性能对比与优化适配上，形成了一套相对系统的方法论。

除项目交付外，我也长期投入企业数据库技术培训工作。

面向 DBA 团队、开发团队和运维团队开展专题课程，内容包括 PostgreSQL 运维与调优、Oracle 数据库管理、MySQL 性能优化、国产数据库迁移适配、SQL 调优方法论、故障案例分析等。原文链接：OceanBase 为什么要多一层 Unit 和 ResourcePool?Tenant 直接分 CPU 内存不行吗?多租户资源模型一次讲透