vivo鄢楠：基于OceanBase 的降本增效实践

在3 月 20 日的2024 OceanBase 数据库城市行中，vivo的体系与流程 IT 部 DBA 组总监鄢楠就“vivo 基于 OceanBase 的降本增效实践”进行了主题演讲。本文为该演讲的精彩回顾。

vivo 在1995年于中国东莞成立，作为一家全球领先的移动互联网智能终端公司，其年生产能力已接近2亿台，服务于全球超过5亿用户。vivo最初从电话机业务起家，如今业务范围已广泛拓展至智能手机、AI等多个领域。随着业务的蓬勃发展，vivo的IT技术架构也经历了巨大的变革。从最初的单体架构，到现今基于5G的容器化微服务模式，vivo在二十多年的时间里不断探索并成功应用了行业主流的IT技术。

1712027654

一、使用MySQL面临诸多挑战

vivo 的数据库迭代伴随着整个数据库行业的变迁。vivo 的现有业务系统有的采用了传统的商业数据库，有的采用了新型的开源数据库，最多时有几千个数据库，目前数据库技术栈包括 Oracle、MySQL、Redis、OceanBase 等近 10 种数据库。随着数据库越用越多，vivo 开始围绕数据库的运维和使用场景，探索工作效率的提升。

1712027681

当前，vivo 使用的主要数据库是 MySQL，通过 MySQL 的集群加一套 proxysql 分离的模式支撑业务运行。MySQL 的生态非常庞大，周边组件非常多，但是并没有统一的集成解决方案，每个问题都需要单独调研或者引入第三方组件。

而多个组件搭配的方案也存在明显的缺陷。这些组件来自不同的社区和厂商，给运维 DBA 带来了高昂的学习成本，同时也给业务带来隐藏的风险。vivo 现存的关系型数据库在日常运维中，常见的问题主要有以下几个方面：

第一，性能和可扩展性

在使用 MySQL 数据库时，如果进行复杂查询或大数据库的查询，会导致 MySQL 性能下降。在高并发场景下，写入操作会导致性能瓶颈。此外，不恰当的索引设计或管理也会影响查询效率。MySQL 的水平扩展能力有限，对于需要分布式数据库解决方案的场景不够理想。

第二，备份和恢复

MySQL 对增量备份的支持相对有限，大型数据库备份耗时较长，在线备份会影响数据库性能，在数据丢失或损坏情况下，恢复过程复杂且耗时。

第三，可用性和灾难恢复

现存关系型数据库在设置和维护高可用性架构（如主从复制、集群）时，复杂且成本较高。在主数据库发生故障时，自动故障切换到备份数据库时，存在延迟或不一致性问题。为了确保数据安全性和业务连续性，制定和测试灾难恢复计划也需要额外的资源和时间。为了提供灾难恢复能力，在多个数据中心间同步数据会面临网络延迟和数据一致性挑战。

近些年，降本增效成为企业数字化转型过程中的重要议题。企业不再满足传统的数据架构，期望通过高可用、高性能的数据库，提升运营效率，适应市场需求。大型企业在核心系统升级或全面升级时，主要关注以下几点：

○ 数据模型优化：随着业务发展，数据模型可能需要调整以适应新的需求，这可能导致数据库重构和迁移的挑战。

○ 数据库分片：为了提高性能和可扩展性，数据库分片（sharding）的实施可能增加架构的复杂性。

○ 多租户支持：在多租户应用中管理数据隔离和资源分配可能需要额外的设计和管理工作。

○ 数据迁移：将现有数据迁移到新的数据模型或数据库架构可能涉及复杂的转换和同步过程。

此过程中，相比降本，vivo 更看中增效。在使用 MySQL 时：

在效率层面，偏分析类的复杂 SQL 在 MySQL 执行耗时较长。当 MySQL 单表数据量大时，采用分库/分表方案，会给开发设计、SQL 编写、维护带来复杂度。通过第三方工具配置高可用切换方式，也会增加运维复杂度。

在成本层面，MySQL 一主多从的架构下，实例数量多，存储成本高，从库资源不能高效利用。假如要做读写分离，需要借助第三方组件，增加额外的硬件资源成本。

基于 MySQL 的使用痛点，vivo 开始数据库选型之路。在对行业的头部产品进行了性能测试、兼容性测试、功能点测试等对比后，最终 vivo 选择了 OceanBase。

二、OceanBase 上线15个生产业务

vivo 选型落地 OceanBase 的过程中，经历了内部分享——OceanBase 专家培训——测试环境——IDC 生产上线——公有云生产上线——规模化陆续上线几个阶段。

vivo 在产品选型之后，紧接着在内部做了一次围绕 OceanBase 的特性、收益等方面的技术分享，提升了运维开发人员对 OceanBase 的接受度。在此期间，OceanBase 的专家也对 vivo 的运维开发人员做了相关的产品技术宣导。vivo 的业务范围广，因此选择了一个契合 OceanBase 功能特性的业务优先试点。运行良好之后，从 IDC 到云上，持续拓展集群规模。

vivo 的业务遍布全球，2024 年年初，vivo 在阿里云海外版上线了一个 OB Cloud 集群。目前 vivo 已有 4 个测试集群、1 个阿里云集群、5 个生产集群、15 个生产业务模块上线 OceanBase，包括日志系统，并陆续审计平台、技术中台、用户中心等多个业务系统。

接下来，vivo 的规划是先保证试点业务的平稳运行，将其运行效果转化为其他业务对 OceanBase 的信心，持续地迭代升级。当业务在 MySQL 上有运行痛点，并且业务有意愿做调整，且调整成本不高的情况下，我们会做 OceanBase 的替换。现阶段，MySQL 和 OceanBase 在 vivo 会同时存在。

三、使用 OceanBase 相当于增强版“MySQL”

OceanBase 是一款自主研发的分布式数据库，具备数据强一致、高扩展、高可用、高性价比、稳定可靠等特征，因其高度兼容 Oracle/MySQL，也大大降低了数据库的迁移成本和运维开发的难度。其周边生态系统也比较完善，社区很活跃，对相关问题能够及时响应，团队的支持力度也很大。总体使用下来，相当于“增强版 MySQL”。

第一，兼容性。vivo 在引入新产品时，需要保证不会因此降低原有的效率。OceanBase 的兼容性极大保证了业务效率。

○ 语法与 MySQL 兼容，对开发友好，代码改动小

○ 云上与云下同一个技术栈，OB Cloud 支持多云部署

○ 兼容 MySQL Binlog 模式，对下游消费 Binlog 友好；MySQL 生态的 Binlog 统计、flashback 工具（例如 my2sql/mysqlbinlog）等可兼容

○ 可将监控指标采集到 Prometheus，兼容现有的监控、告警体系

第二，稳定性。稳定性是 vivo 引入新产品时第二考虑因素，只有系统稳定运行，才能为效率提供保证。vivo 选择了一些业务上线 OceanBase 进行试点，稳定运行大半年后， vivo 对 OceanBase 在快速扩缩容、副本调整、读写分离方面的优势深有体会。

○ 平稳支持业务流量

○ 快速弹性扩容

○ 多场景原生支持 Online DDL，降低变更对业务的影响

第三，服务。在试点 OceanBase 的过程中，OceanBase 团队 7*24 小时响应，提供了专家技术支持、多次专项培训、内部方案设计等技术服务和专业建议，遇到特殊问题时，研发人员也能快速介入，快速解决问题。

第四，增效。OceanBase 灵活的表分区方式，消除了分库分表的复杂性。开发人员不需要再对分库分表进行特殊的代码设计。且 OceanBase 可支撑部分 AP 类查询，在遇到这类问题时，不需要再接入下一个大数据平台完成。同时，跨集群的主备租户模式，可以高效创建灾备或只读节点，从而保证数据库的一致性，提高资源利用率。

第五，降本。OceanBase 的多租户管理模式和资源隔离，规格和副本可以灵活调整，解决了 vivo 之前的主从副本资源无法有效利用问题。并且 OceanBase 的数据压缩比非常高，可进一步降低存储成本。高可用架构+ OBproxy，无需搭配第三方工具进行切换和读写分离。

第六，工具生态。OceanBase 的工具生态非常丰富，从数据库的全生命周期，几乎覆盖了 90% 的运维场景。因为有些历史业务要兼容，所以 vivo 需要考虑和以往数据库的兼容性，假如上线新的业务系统，选择 OceanBase 可以做到开箱即用，几乎无需在平台建设方面投入人力。vivo 在使用 OceanBase 的过程中，感受最深的工具有两个，分别是 OCP 和 OMS：

○ OCP 管理平台提供了便利的部署、升级、监控、备份恢复等运维手段；

○ OMS 迁移平台提供了便利的数据迁移方法，支持全量、增量、反向同步等多种模式。

1712028023