作为一款分布式云原生数据库，客户经常会问到的问题是“我如何规划我的OceanBase？”，“我如何通过现有的信息来设计OceanBase架构”，“我如何根据业务增长规划我的OceanBase数据库”这些问题随着现在大量客户新业务系统采用OceanBase而出现，那我们该如何通过一定的性能数据来进行规划客户的资源并且允许客户进行资源扩容而实现计算能力扩容又可以降低客户迁移成本呢，我们期望通过本文给出一些可参考的建议。
一.OceanBase资源管理说明
需要首先了解OceanBase如何对资源进行管理，这样才能更好的根据实际需求来设计实际架构方案。
1.OceanBase跨服务器资源使用
OceanBase中具体的管理对象为租户，租户是一个逻辑概念，在 OceanBase 里是资源分配的单位。
可以看作OB-oracle 模式租户相当于Oracle DB一套，OB-mysql 模式相当于mysql instace。
每个租户利用不同的资源池（Resource Pool）来限定所占资源量，而资源池的定义由资源单元规格（Resource Unit ）定义具体多少C多少G内存。Resource Unit 的资源规格定义是不能超过单OBserver可分配规格。
当了解OceanBase 架构后，Resource Pool 是可以设置多个Resource Unit 提供服务的，以图为例，一个典型的4-4-4架构OceanBase集群，绿色的Unit 在一个zone中有2个，这2个Unit 组合起来一起累加资源量为整个Resource Pool资源量
至此可以看到OceanBase 的一个租户是可以跨OB服务器来占用资源，这样OceanBase的租户也可以跨OB服务器来存储数据表
2.OceanBase跨服务器资源的影响
分布式事务
OceanBase使用全局一致性锁来保证当出现跨OB服务器事务时，全局一致。有了全局一致性锁，分区表的全局索引成为可能，并且可以实现跨OB服务器的分布式事务。
OceanBase默认表或者分区表的某个分区称为partition，partition无法再分割，所以不会出现一个表跨OB服务器的情况。
什么时候会出现分布式事务呢？
一般来说，当一个租户资源跨OB服务器时，就有可能发生：
例如 事务A 涉及表X和表Y，表X在OB1而表Y在OB2，则事务A就会出现分布式事务
例如 分区表W下有多个分区P1...Pn。则有可能发生P1和P2 不在一个OB服务器的情况，这样在事务跨分区时会出现分布式事务。
一般来说都要尽量避免出现分布式事务，本身全局一致性在抗高并发会导致性能的下降。
分库分表
分库分表一般采用ODP组件来进行配置，ODP对应用侧是一个逻辑表，而对物理侧一般来说对应的物理表拆分根据规则可以描述为：
n租户x库y表。表示逻辑库分布在n个租户上。
如果不同租户分布在不同OBserver上提供服务，则逻辑表实质也可以跨多服务器。
此时需要注意，针对ODP逻辑表的事务，一般需要和SOFA的分布式事务相结合进行。
在分库分表场景中，一般来说OceanBase租户不会将Resource Unit 设置为大于1，这样主要为了防止出现中间件层分布式事务处理，而数据库层又出现跨OBserver的分布式事务。
所以根据这个原则，分库分表场景中OceanBase物理租户无法跨OB服务器，每个租户可用最大自资源限定为服务器最大可承载量。
二.OceanBase资源规划考虑点
1. 数据分片如何实施
目前OceanBase能提供的数据分片方案有2种方案：分区表和借助ODP产品的分库分表方案。
根据实际经验来说，不同的方案适用的场景也是有不同：
分区表适合场景
OceanBase的分区表和Oracle分区表类似提供了Range，Hash，List等分区方案。
适用数据表有明确的时间属性，并且随时间数据量增大：例如交易历史表，交易历史明细表，比较适合使用Range时间分区，利用Range时间分区可以使得数据表有明确的生命周期维护方案。
ODP分库分表适合场景
ODP产品一般来说，数据迁移不方便，而采用逻辑表1张对接实际n张物理表，
适用数据量很大而采用类似ID进行分片例如人员信息表、物品信息表。
对数据增长有预期，提前进行规划也可以考虑ODP。
一些限制条件
a.客户实施具体需求，而ODP目前只支持OB-mysql，而分区表则都可以
b.去O场景中如果原应用不经过改造，一般平迁数据库的话，使用OB-oracle适配，则只能使用分区表
c.ODP对应的物理实际租户我们设定是不会跨OB服务器（如果可以跨服务器则场景极为复杂）
d.而分区表不同的分区可以跨不同OB服务器
2. 如何满足业务增长量需求
在实际业务数据库架构设计时，需要综合考虑客户业务增长需求，提前为客户预估容量或者预留扩容空间。
而本身OB服务器单服务器性能是有上限的，这个决定了数据分片规划和实际OB服务器承载量--是否需要跨OB服务器实现
另外需要注意的是如果采用ODP分库分表方案，1个业务多租户情况下，由于1个租户设置为不跨OB服务器，这样相当于极限情况下最终多少个租户=最终多少OB服务器。
3. 是否会突破单机性能需求
从以上可以看到，OB服务器的单服务器承载量也对规划有相当大的影响。
以现在标准OB阿里云机型来说
以经验来说，基本资源瓶颈是CPU和内存，磁盘一般不会成为瓶颈
PV62.22 适用非常多客户的阿里云底座场景机器，一般单OB服务器可以用80C 700G左右资源可分配给业务使用。
（请注意⚠️ 由于不同的时间硬件配置不同，造成估算差异。例如Q5O1.22 机型则只有56C 384G左右内存。）
如果经过测算，业务量会突破单OB服务器或者需要额外需要数据分片，则需要规划时候同时考虑数据分片需求
以下列表列出了部分阿里云平台OceaenBase标准机型的硬件配置，
★机型 |
PV62.22 (中配) |
PV62S3.22 （高配） |
PN68M2P2.22 |
★服务器外观 |
机架式，2路服务器 |
机架式，2路服务器 |
机架式，2路服务器 |
★cpu规格 |
[Intel_Xeon_Platinum8260]*2 |
[Intel_Xeon_Platinum8260]*2 |
[Intel_Xeon_Gold5218]*2 |
★cpu核数 |
[24]*2 |
[24]*2 |
[16]*2 |
★cpu架构 |
x86_64 |
x86_64 |
x86_64 |
★内存(GB) |
768 |
768 |
384 |
★内存规格 |
ECC DDR4 RDIMM 频率 ≥2666MHz |
ECC DDR4 RDIMM 频率 ≥2666MHz |
ECC DDR4 RDIMM 频率 ≥2666MHz |
★内置硬盘 |
240G[240G_sata_ssd]*1 3840G[3840G_nvme_ssd]*4 |
240G[240G_sata_ssd]*1 3840G[3840G_nvme_ssd]*12 |
240G[240G_sata_ssd]*2 8000G[8T_sata_hdd]*12 1920G[1920G_nvme_ssd]*2 |
★硬盘规格 |
NVMe_SSD: 企业级主流品牌型号，接口类型为U.2 盘或 AIC 皆可 擦写寿命： >=0.7DWPD 5年; 带掉电保护功能：即有连续数据写入的情况下，异常掉电不丢数据 SATA_SSD: 市场主流品牌，企业级SATA SSD硬盘(普通SATA SSD或m.2 SATA SSD, >= 240G) |
NVMe_SSD: 企业级主流品牌型号，接口类型为U.2 盘或 AIC 皆可 擦写寿命： >=0.7DWPD 5年; 带掉电保护功能：即有连续数据写入的情况下，异常掉电不丢数据 SATA_SSD: 市场主流品牌，企业级SATA SSD硬盘(普通SATA SSD或m.2 SATA SSD, >= 240G) |
NVMe_SSD: 企业级主流品牌型号，接口类型为U.2 盘或 AIC 皆可 擦写寿命： >=0.7DWPD 5年; 带掉电保护功能：即有连续数据写入的情况下，异常掉电不丢数据 SATA_HDD: 企业级SATA硬盘,>=7200rpm SATA_SSD: 市场主流品牌，企业级SATA SSD硬盘(普通SATA SSD或m.2 SATA SSD, >= 240G) |
★磁盘控制器类型 |
sas卡（none-raid）*1 或板载AHCI，non-raid直通，满足机型磁盘配置需求，采用板载AHCI直出或以下芯片型号的标准卡或自研卡：SAS3008it、SAS3408it、SAS3216、SAS3416it |
sas卡（none-raid）*1 或板载AHCI，non-raid直通，满足机型磁盘配置需求，采用板载AHCI直出或以下芯片型号的标准卡或自研卡：SAS3008it、SAS3408it、SAS3216、SAS3416it |
sas卡（none-raid）*1 或板载AHCI，non-raid直通，满足机型磁盘配置需求，采用板载AHCI直出或以下芯片型号的标准卡或自研卡：SAS3008it、SAS3408it、SAS3216、SAS3416it |
★网卡要求 |
10GE: 双端口10G光口独立网卡，主控芯片型号Intel 82599，并满配兼容多模模块（SFP+），支持PXE，支持DPDK应用（兼容2.2版本），支持SRIOV技术，支持特定五元组（源IP地址，源端口，目的IP地址，目的端口和传输层协议）分流到SRIOV VF。 |
10GE: 双端口10G光口独立网卡，主控芯片型号Intel 82599，并满配兼容多模模块（SFP+），支持PXE，支持DPDK应用（兼容2.2版本），支持SRIOV技术，支持特定五元组（源IP地址，源端口，目的IP地址，目的端口和传输层协议）分流到SRIOV VF。 |
10GE: 双端口10G光口独立网卡，主控芯片型号Intel 82599，并满配兼容多模模块（SFP+），支持PXE，支持DPDK应用（兼容2.2版本），支持SRIOV技术，支持特定五元组（源IP地址，源端口，目的IP地址，目的端口和传输层协议）分流到SRIOV VF。 |
★网口数量 |
10GE*2 |
10GE*2 |
10GE*2 |
电源 |
1. 220VAC/240HVDC交直流兼容电源 * 2 2. 电源线根据机房环境来选择，如国标/美标/C14 |
1. 220VAC/240HVDC交直流兼容电源 * 2 2. 电源线根据机房环境来选择，如国标/美标/C14 |
1. 220VAC/240HVDC交直流兼容电源 * 2 2. 电源线根据机房环境来选择，如国标/美标/C14 |
★管理维护功能 |
提供基于Web的远程管理控制、配备硬件监控、远程管理功能；支持IPMI2.0标准。提供IKVM功能，实现远程KVM功能；独立管理口100%兼容千兆或百兆交换网络，通过管理口实现远程开关机、重启、网络安装操作系统等操作。 |
提供基于Web的远程管理控制、配备硬件监控、远程管理功能；支持IPMI2.0标准。提供IKVM功能，实现远程KVM功能；独立管理口100%兼容千兆或百兆交换网络，通过管理口实现远程开关机、重启、网络安装操作系统等操作。 |
提供基于Web的远程管理控制、配备硬件监控、远程管理功能；支持IPMI2.0标准。提供IKVM功能，实现远程KVM功能；独立管理口100%兼容千兆或百兆交换网络，通过管理口实现远程开关机、重启、网络安装操作系统等操作。 |
★云平台兼容性 |
与阿里云平台兼容，通过阿里云专有云平台认证，各厂商机型认证情况见阿里云官网链接：https://www.aliyun.com/product/apsara-stack 页面最下方“合作伙伴->硬件认证” |
与阿里云平台兼容，通过阿里云专有云平台认证，各厂商机型认证情况见阿里云官网链接：https://www.aliyun.com/product/apsara-stack 页面最下方“合作伙伴->硬件认证” |
与阿里云平台兼容，通过阿里云专有云平台认证，各厂商机型认证情况见阿里云官网链接：https://www.aliyun.com/product/apsara-stack页面最下方“合作伙伴->硬件认证” |
三.OceanBase某客户资源规划案例
一般来说实际进行资源规划，容量规划等工作需要采集考虑点的信息和客户实际应用情况，综合进行考虑。有些数据明显偏离正常范围建议和客户进行深入沟通后解读，了解数据是否确实有误。
1. 客户信息采集沟通汇总
某客户需要提前进行业务容量规划，并且提前针对OceeanBase服务进行资源规划
经过和客户沟通和业务实际情况了解，汇总了业务，项目实际信息获得了以下信息：
客户采用单元化架构实施
客户使用单元化架构决定了整体架构实施锁定分库分表ODP组件，客户会根据实际情况来进行逻辑/物理表拆分。
这样的策略导致和分区表有明显区别了
客户分库分表策略决定后，考虑采用1逻辑表=100分物理表形式
这里需要决定的是分多少OceanBase租户，由于单个租户无法跨OBserver分配物理资源，所以对于客户场景来说，规划多少租户决定了对应可使用最大OBserver数量，也决定了实际资源最大量。
客户性能数据汇总
客户反馈当前业务系统QPS大致为15W左右，已经考虑峰值情况，预计年均增长率为20%
结合数据量情况汇总得到
业务系统数据增长情况，以20%的增长率 |
|||||
联机QPS: 万次/s |
联机每日写入数据GB |
存量数据TB |
批量QPS: 万次/s |
季度结息日写入数据GB |
|
2019年 |
15 |
10 |
5.85 |
62 |
70 |
预估3年 |
25.92 |
17.28 |
10.11 |
62 |
120.96 |
预估5年 |
37.32 |
24.88 |
17.47 |
62 |
174.18 |
预估10年 |
92.88 |
61.92 |
36.22 |
62 |
433.42 |
*客户需要预估10年用量，则通过计算得到表如上所示。
2. 客户硬件信息计算能力
客户预计采用Q5O1 机型，单OBserver提供了 56C 384g内存，系统占用部分资源后实际业务使用48C 300G左右。
磁盘部分考虑到OceanBase对数据压缩率及磁盘配置，数据量不成为瓶颈，所以只计算CPU和内存，而通过计算CPU 性能按一定经验比例可以获得内存使用量配置。
根据实际经验来说，OceanBase单Core 提供了QPS 近1000-1500左右，客户重要生产环境按保守1000估算计算
通过列表可以计算得到n台OBserver实际提供的总容量和性能容量情况
OBserver数量（单zone OBServer数量） |
最大可扩展CPU |
可分配内存 |
最大可写入磁盘容量（8块800G的SSD盘）（单位：TB） |
每日安全写入数据量 |
QPS(以1000/c估算) 单位：万次/s |
（单位：颗） |
（单位GB） |
（单位：GB） |
|||
17 |
833 |
4080 |
81.6 |
1632 |
83.3 |
18 |
882 |
4320 |
86.4 |
1728 |
88.2 |
19 |
931 |
4560 |
91.2 |
1824 |
93.1 |
20 |
980 |
4800 |
96 |
1920 |
98 |
3. 客户容量架构规划
根据以上信息可以看到，20OBserver单Zone 提供的QPS容量可以满足客户10年总量需求，而其他数据容量等信息已经足够客户业务数据量。
所以综合来看，客户如果按照当前规划，最终10年以后需要达到单Zone20台OBserver。
由于ODP分库分表规划中租户无法跨OBserver，那意味着需要20租户。
由于考虑到后期数据同步等工作影响，应该在规划中提前规划将业务分布到20租户中。
所以客户最终的规划业务采用20租户，x分库y表，具体分库和分表根据实际单元化化单元量决定。
