vivo 自 2022 年开始调研、测试 OceanBase 至今，现已上线 17 个业务系统，涵盖日志类、分析类、交易类业务，实现了总资源节省 80%，开发、运维工作大幅简化。vivo 体系与流程 IT 部门数据库高级工程师廖光明在本文中，详细介绍了 OceanBase 应用现状、遇到的问题，以及 OceanBase 与 MySQL 在开发、运维架构的各项特性对比。

vivo 是一家以智能终端和智慧服务为核心的科技公司，研发线涵盖 5G 通信、人工智能、工业设计、影像技术等。得益于 vivo 的智能制造网络（含品牌授权），截至目前，vivo 年生产能力近 2 亿台，向全球超过 60 个国家和地区的 5 亿用户提供优质产品和服务。

我所在的部门主要负责 MES、ERP、产销存等系统，比如线下门店购买系统、网上应用商城、App 端应用市场等。vivo 整体上使用的数据库种类繁多，约有 1000+ 主机，涉及 15 种数据库（见图 1），还有数据同步工具需要维护。此外，还有多区域多云的特性，包括东莞机房自建、海外使用阿里云、AWS RDS 数据库。

图1 vivo 使用的数据库种类

我们使用数据库的方式也比较复杂，例如，在一个业务中同时使用 MySQL 主从和MySQL MGR，如果涉及读写分离，还要分别叠加 Proxy 使用，数据库的多种类和架构的复杂性给运维团队带来了较大压力。

此外，我们还面临资源利用率较低、机器数量多、部分系统资源扩展瓶颈等问题。

• RDS  成本高，资源利用率低：最贵的 CPU 资源利用率较低，平均 CPU 利用率不足 5%，CPU 峰值的平均值也不到 20%；磁盘和 I/O 资源利用率也偏低。在 AWS 中，存储类型和 IOPS 有绑定关系，每个系统都按未来最大规格去分配资源，系统资源的峰值时间节点也不一样。

• 数据库数量不断增多，资源和管理成本增加：业务微服务拆分越来越细，造成数据库实例不断增多，RDS 成本越来越高。

• MySQL 数据库扩展性不足：MySQL 数据库的可扩展性有限，依赖于分库分表进行水平扩容，带来开发运维复杂度。

基于业务考虑，核心业务系统为分库分表架构，某些场景又避免不了跨库 JOIN 查询，运维复杂；基于成本考虑，不仅运维成本高，而且数据库成本也高。因此，我们开始探索是否有更优的数据库方案。       

在选型时，我们调研了两款分布式数据库，最终选择引入OceanBase。从选型角度讲，我们看重几个方面：

• 产品成熟度。OceanBase 在 2010 年面世，在阿里巴巴和蚂蚁经历了很多应用场景的考验，尤其是支付宝核心业务和“天猫双 11”，其产品成熟度已经得到验证。

• 产品性能。我们对比了 OceanBase 和 MySQL 的并发性能表现（见图 2）。在 50 并发下，OceanBase 单主模式（指定主节点，仅主节点提供服务）优于多主模式（所有节点提供服务），不过，MySQL 的响应时间更短；在 50 并发以上，OceanBase 的响应更快；在复杂 SQL 场景下，OceanBase 全面优于 MySQL。

• MySQL兼容度。我们同样看重产品和 MySQL的兼容度，经过测试发现 OceanBase 高度兼容 MySQL，支持应用系统平滑迁移，过程中未出现任何兼容性问题。尤其 OceanBase 4.2 版本基本兼容 MySQL 8.0 的语法，避免了用户改造成本。

• 运维工具。DBA 非常关注运维配套工具是否完善，OceanBase 有完善的运维工具，如安装部署工具 OBD、集群管理平台 OCP、迁移服务 OMS 等。同时，OceanBase 支持 promethus、binlog 等 400 余种生态工具，可以兼容我们现有 Flink CDC+logproxy 的数据同步方式，

图2 OceanBase和MySQL的Sysbench 压测情况（ 三节点 32C 128G ）

此外，相比 MySQL，OceanBase 拥有极高的压缩率，可以节省存储成本；原生分布式，可以更快地完成数据横向扩展和纵向平滑扩展，并且原生高可用。

对于部分功能如数据压缩率、性能、成本等，我们也进行了测试。

▷ 数据压缩与性能

我们基于在云上和线下都有分布的产销存业务观察 OceanBase 的压缩率和响应时间，通过捕捉 MySQL 全量日志，同时全路径回放 MySQL 和 OceanBase 数据库，比对其 SQL 执行效率。

在云上，我们开启 RDS SLS 审计日志，捕获 RDS 时间段内的业务负载，并投递至 OSS，通过 OMA 读取 OSS 审计日志，解析成 SQL 文件，并记录审计日志中的 RDS 内核执行时间，然后使用解析文件，按用户定义回放倍速，向 OceanBase 上发送回放流量，记录 RT 时间，并结合 SLS 中的 RDS 整理最终结果报告。

线下回放同样开启 RDS SLS 审计日志，捕获 RDS 时间段内的业务负载，并投递至 OSS，但仅使用 SLS 解析出的 SQL 内容，不使用 SLS 中的 RDS 时间记录。从生产环境备份恢复出临时 RDS 实例，供流量回放，然后线下部署 OMA，将 SQL 负载同时回放至 RDS 和 MySQL，并分别统计执行时间，生成最终报告。

从图三的测试结果可见，相较于源数据库（MySQL），OceanBase 的效率较有优势，数据存储方面，OceanBase 的压缩比能达到 5.7 倍至 15.3 倍。最重要的是业务系统中的 MySQL 语句迁移到 OceanBase 完全兼容，没有修改。

图3 源数据库（MySQL）与OceanBase的数据压缩率对比

同时通过应用回放，统计执行较为频繁的 SQL 响应时间对比（前者 MySQL，后者 OceanBase，小于 1ms 记为 0ms），从图 4 可见，一半的业务 SQL 性能持平，大约在 1ms 左右；另一半的业务 SQL 有数十上百倍的提升。

图4 MySQL 与 OceanBase 的响应时间对比

由于产销存的线下业务数据量较大，这也是我们引入 OceanBase 的直接诉求。

vivo 各省业务系统的数据量并不一致，比如广东省的业务量比较大，一个门店的业务系统，最大的数据库为 2TB，大省份会独立个库，小省份会共库，但是所有省份又有整合数据的需求。

此前，整个业务系统采用分库分表架构，在查询场景，通过将各库数据聚合起来，难以保证查询的实时性和准确性。经过对 OceanBase 的性能测试，我们可以将汇总库和全国十余个分库合并为一个独立的 OceanBase 库，满足原来的跨库查询需求，较好地满足业务需求。

▷ 降本经验

OceanBase 基于 LSM-Tree 架构的存储引擎和数据压缩比为企业降低存储与硬件成本提供了更多可能。从硬件方面考虑，OceanBase 的降本优势在于超卖，各系统错峰使用超分资源，不同租户之间的弹性可以分时复用，提升资源利用率。假设对应以下三个系统，高峰期使用的资源都需要 4C8G。如果使用 MySQL，需要为三个业务系统都分配 3 个 4C8G 规格的资源；如果使用 OceanBase，只需要分配三个 1C8G 的租户，余 3 个CPU 资源可以共享。另外，如果开启 OceanBase 的读写分离特性，CPU 资源还能进一步充分利用。

图5 OceanBase 降本

目前，我们已经上线了 17 个业务系统，包括日志类、分析类、交易类等。原有业务系统架构为分库分表，以每个省份数据量切分，大省份会独立个库，小省份会共库；另将需要汇总查询的数据通过 DTS 汇总在一起；总计主机台数为 20 台，数据约 4.5T。在上线 OceanBase 后，整合后的资源为 12C，20G 租户规格，并开启读写分离，数据约 600GB。将各分库汇总为一个 OceanBase 库后，总资源节省 80%，也不再需要汇总库，查询时的准确性和实时性也得到了保障。

图6 上线OceanBase节省80%总资源

不过，在使用过程中，我们也遇到了一些问题。

其一，OceanBase 4.2 之前的版本中语句在有大字段的情况下，我们写场景执行计划选择不正确，应该走索引走了全表，研发反馈是成本评估模型未考虑大字段场景而导致的，该问题目前在 4.2 版本已解决。

表：t_log_record` (`inter_param` longtext outer_param` longtext ,create_time` timestamp NOT NULL)  索引列为 create_time
         select * from t_log_record WHERE create_time >= '2023-08-11 09:00:00’  and create_time <= '2023-08-11 23:59:59';

其二，备份时段采用适当错开，NAS 资源挂载采用官方推荐的参数，NAS 资源不够会有出现 hang 住情况。

其三，OCP 管理资源应用容器的问题，当集群管理较多时，应该对 OCP 容器进行扩容，避免出现 OCP 卡顿现象。

我们也发现了部分参数设置的问题，在此列举一下供大家参考。第一个问题是默认的自增序列，如果 OceanBase 设置成和 Oracle Sequence 类似的 Order 模式，并发度也会下降。第二个问题是参数自增列，如果大家比较关注自增值的情况，存在业务含义，可以尽量把该值设小一点，避免某些场景下存在跳号情况，沿用默认参数会跳的比较大。

另外，查询参数默认只有10s，如果不调大，遇到某些场景容易超时，典型场景如创建索引。

我们在使用 OceanBase 过程中开启了读写分离，能更加充分的利用机器资源。之所以不采用多主写模式，是因为 OceanBase 多主的模式在并发度较低的场景下，响应时间和 TPS 不及 MySQL ，在公有云也默认推荐单主的模式。

目前，我们接触 OceanBase 已有半年，从整体的测试和体验来看，符合预期。

基于目前对 OceanBase 和 MySQL 的了解与应用经验，我总结了OceanBase对比MySQL 的优势和不足，供大家参考。

• 兼容性：从 MySQL 5.7 版本迁移至 OceanBase 无需修改代码，不过目前OceanBase 4.0 版本不支持逆序索引。

• 在线 DDL ：尽管 MySQL 5.7 是弱支持，但不得不说这是 MySQL 的一个痛点，需要借助扩展工具，而 OceanBase 可以支持几乎所有常用的功能，除了在线分区表模式。

• 高可用和读写分离：MySQL 需要借助第三方工具来实现高可用、读写分离和审计，OceanBase 原生支持。

• 执行计划固定：众所周知在 Oracle 里面机器是正常用的，但 MySQL 里面没有，支持 Query write 改写，但不容易管控，而支持 OceanBase 支持 Outline 固定。

• 全局索引：MySQL 虽然有分区表，但不支持全局索引。但是有些场景其实避免不了使用全局索引，这方面 OceanBase 也是完全支持的。

• 序列：我们在一些日志场景下，有时希望日志能够保存是哪个月，MySQL 没有序列特性，还需要写脚本，带来高水位的问题。OceanBase 对序列的支持避免了此类问题的发生。

• TTL 特性：MySQL 不支持，OceanBase 4.2 版本开始支持。

• 大事务支持：MySQL 容易引起主从延时，如果用 Mgr，一旦事务大就容易有流控剔除节点。我们在数据迁移场景下，发现即使是 TB 级别的数据，OceanBase 也毫无压力。

• hash join：MySQL 8.0 支持，但比较弱；OceanBase 支持。

• 并行：MySQL 不支持，这也是慢的原因之一；OceanBase 支持并行，而且在查询优化不动的情况下，如果 CPU 足够，还可以用蛮力。

• 死锁：MySQL 不支持死锁检测视图，如果遇到死锁，只能去后台翻日志；OceanBase 有死锁检测视图查询。

• DBLink：MySQL 虽然号称有第三方组件，但基本没人这么用；OceanBase 4.2 开始支持。

• SQL限流：其实 OceanBase 是可以通过去加 hint 并发来限制 SQL 的并发度。而用 MySQL 或 Oracle 都没有特别好的方式对 SQL 的流量做限制。OceanBase 在不停应用的情况下，还有自动限制慢 SQL 的能力，超过默认 10s 的话，只会给慢 SQL 默认 30% 的资源使用，防止一个慢 SQL 拖垮整个系统。

• 数据压缩比：MySQL 的数据压缩依赖于操作系统文件系统，相较之下，OceanBase 的数据压缩比是 MySQL 的 6～7 倍。

• 内存回收：如果我们用 MySQL 的话，经常在使用过程中会发现内存使用的百分比较高，但是这块内存如果想要去回收的话，并不是很好办，因为看内存占用比并不知道 MySQL 实际需要占用多少内存。但 OceanBase 会定期回收合并，释放内存，更容易监控数据库所需实际内存。

• 碎片：使用 MySQL 的时候频繁 DML 容易有碎片，由于 OceanBase 使用 LSM  架构，会定期合并，不容易有碎片。

• 备份恢复（闪回查询）：MySQL 不支持，依赖 binlog ，OceanBase 支持表级闪回查询，租户级闪回操作，可以同一份数据进行多次测试。

• 规格变更：使用 MySQL 的时候云 RDS 在资源规格扩容时，应用会有闪断；OceanBase 租户规格变更没有闪断。

• 版本升级、变更：MySQL 无官方工具，需要自行开发，这对于升级工作量较大的部门非常不友好，OceanBase 提供了原生的升级工具，比较顺畅。

另外，生态工具对 DBA 而言是减负和提效的利器，MySQL 依赖自行开发，OceanBase 有 ODC、OCP、OMS 等自行开发的工具，可以支持开发自助 SQL 审核、数据执行、数据归档、数据删除、DDL 等常规繁锁危险的操作，可以协助 DBA 完成监控构建、高可用演练、定位问题、备份恢复、规格扩容、语句审核与执行，以及数据的导入、导出、迁移、同步、清理等。目前，我们通过 OceanBase 工具的 WEB 界面基本可以完成相关运维工作，其有细粒度权限管控，可以开放相关权限与相关人员自助，进一步简化了 DBA 的重复工作。OceanBase 还与 400+ 上下游生态工具进行了兼容和集成，对用户来说也很方便。

同时，我也总结了在使用 OceanBase 的工具时，需要注意的事项，以及我们希望优化的细节。

▷ 首先在功能性方面：

• OCP 上升级 OceanBase 版本时不允许租户有多个 primary_zone 存在，升级时如果租户多，切换主节点会比较繁琐。目前 4.2 版本已经支持。

• 如果用户手动改了集群的 root 密码或者租户的 root 密码时（不通过 OCP 平台），密码没法重置，这个如果有人故意使坏，比较危险。（OceanBase 计划 4.2.3 版本支持）

• OCP 查看执行计划时，只有已知索引列统计信息，没有其他列统计信息，希望能补充下相关 where 条件列后的列统计信息。比如 create_time 列区分度不佳，但我想知道 time_cost 列是否适合建索引。（官方告知 obdiag 工具支持该功能）

• CPU 内存能隔离时能支持最小、最大范围，保证最小资源，很多场景都是用户初始化时资源要多，其他时候资源比较闲。（OCP 4.3 计划支持）

• OBProxy 读写节点支持权重配置，防止负载不均衡。

• OceanBase 支持类似 Oracle Intervel 分区特性。当前可以通过 ODC 工具进行支持，但更希望数据库内核原生支持，OceanBase 计划在明年的内核 4.4 版本支持该功能。

• OMS 管理平台支持第三方登录，角色映射。

▷ 其次在易用性方面：

        

• OCP 平台上，如果是脚本创建的租户，OCP 控制台登陆时需要手动输入密码；然后如果切换 OCP 用户又要再输入一次密码。（OCP 4.2.2 密码箱易用性改进）

• OCP 租户界面能有用户说明，这样便于用户侧知道自己名下系统。（OCP 4.2.2 支持标签管理）

• OMS 添加数据源，在输入 OceanBase 连接串时，能根据 OCP 选择相关信息，减少输入工作量。

此次数据库的选型与替换历经半年，最终取得了不错的效果，主要体现为：OceanBase 与 MySQL 高度兼容，迁移时无需修改代码；MySQL 分库分表架构替换为OceanBase后，总资源占用节省了 80%，也极大地降低了运维成本；OceanBase 的运维工具和社区支持帮助 DBA 简化了运维复杂度，减轻了运维负担。

vivo 对应用 OceanBase 的计划分为三步。

第一步，试点运行。以 OceanBase 社区版替代 MySQL 为起点，优先选择存在分库分表痛点或资源占用成本高的业务，作为迁移到 OceanBase 的试点。将功能模块以影响度从低到高的顺序改造或迁移上线，过程中开发、DBA 或相关团队同步建设 OceanBase 的技术能力。

第二步，业务扩散并规模化改造。传统数据库架构向 OceanBase 数据库架构改造，同时，结合 OceanBase 的特性，选择适用且有改造价值的业务改造，将 OceanBase 作为 MySQL 能力不足场景的补充，依然保留 MySQL 适用场景。

第三步，规模化改造并全面保障业务。将 OceanBase 技术能力在 IT 建设成熟，并落地于更多 vivo 的业务场景，同时进行成本优化、降本增效，以及建设灾备环境。