vivo国产数据库技术储备，突破大规模数据的存储与性能瓶颈

作者：杜霆，vivo互联网存储运维负责人

vivo 是一家以智能终端和智慧服务为核心的科技公司，服务全球 5亿+ 用户，公司内分设多条业务线，其中vivo互联网业务在近两年内完成底层数据库方案的升级以更好地支撑业务发展。业务使用OceanBase后，解决了原本的MySQL在大规模数据场景下的存储与性能使用瓶颈，高并发数据更新效率提升60%，复杂查询性能提升80%，存储成本降低50%。

曾支撑数千套 MySQL 集群稳定运行的技术架构遭遇瓶颈

在过去十多年，vivo一直使用MySQL作为底层数据库。如图1所示，vivo的 MySQL 集群使用双层异步复制架构：上层通过自研代理服务 Proxy 实现加解密、审计、连接池等能力，并通过运维平台对 Proxy 进行完全自动的运维管理，实现了探活、自动切换、自动部署等能力；最下层的 Agent 用于故障切换，通过 Raft 实现了多节点高可用部署；中间的Zookeeper 用于同步 MySQL元数据信息，保证 MySQL 集群间的数据一致性。

图1 MySQL 集群的双层异步复制架构

这套架构及管理方案具备自定义高可用切换能力、探活能力，已支撑数千套 MySQL 集群的稳定运行。然而，在业务发展的过程中，该方案逐渐面临数据存储、读写性能的瓶颈。

数据存储： MySQL 使用单机多实例部署架构，数据存储在物理机中，当业务发展到一定规模后，存储容量受到单机磁盘的限制，需要进行分表。而分库分表的扩展性较差，导致业务、研发、运维等方面的投入成本越来越高。目前总存储规模已经达到 PB 级别，面临较高的存储成本。

读写性能： vivo 庞大的业务规模中涉及大量复杂查询，但 MySQL 的复杂查询性能较低，无法满足业务需求。而且在大批量高并发写场景的效率低，上下游同步和离线查询的从库延迟较大，相关业务都会受到影响。

基于上述原因，vivo 开始调研能够解决当前问题的数据库产品。经过调研对比，最终选择了具备水平扩展、资源隔离、低成本、强容灾、高度兼容MySQL、HTAP等特性的OceanBase，并引进业务环境。

具体而言，自 2023 年第四季度起，存储运维团队开始启动系统化调研，对部署架构、功能特性、性能指标、应用场景、成功案例、安全规范等方面进行调研评估。调研完成后，经部门级评审，正式决定引入 OceanBase 进行平台建设（见图2）。

图2 OceanBase的引入流程

2024 年，项目正式进入落地实施：

• 完成规范制定，开展性能压测、高可用验证、备份恢复与监控报警等验证，确保满足业务上线条件；
• 同步建设配套生态，部署 OCP、OMS、OBLoproxy 等核心组件，并集成下游 Binlog 消费链路，形成完整的上下游生态体系。

2024 年 7 月，首个边缘业务完成试点接入。同时，存储运维团队将 OceanBase 的基础能力（元数据管理、数据查询、数据变更、集群管理）逐步集成到现有运维平台。截至 2024 年底，已有十余个业务、数十套集群正式投产，规模持续扩大。

四个技术场景应用OceanBase，收益可观

目前，在vivo互联网业务线，已有四个数据库场景使用OceanBase，并且运维体系已经开始逐步替换为OceanBase。

OceanBase解决了哪些问题？

1. 数据归档。

因为MySQL 存量数据庞大，部分业务的历史数据已无需在线访问，所以现阶段冷数据归档采用 TokuDB 压缩方案，压缩比约 3–4 倍，并挂载大容量磁盘存储。随着数据持续增长，面对磁盘容量不足的问题，存储运维团队已多次拆分归档集群，但拆分操作的运维成本高、扩展性差。引入 OceanBase ，利用其数据压缩能力与分布式扩展能力，可按业务粒度部署独立集群，实现横向扩容与在线压缩。一方面解决了业务侧需要基于 MySQL 进行分库分表的改造问题，另一方面降低了业务复杂度和运维成本，并显著降低了历史数据存储空间。

2. 水平分库分表。

在业务初期，业务团队并没有设计分库分表，当集群规模扩大后单实例容量受限，传统 MySQL 需要人工实施分库分表，投入大、周期长。引入 OceanBase 后，由于其原生支持分区表以及自动分区能力，可以自动水平拆分，减少了应用改造及人力成本等的投入，而且多租户资源隔离特性，可以减少原本单机多实例架构的资源争用情况。

3. 高并发。

对于部分并发极高的业务，MySQL 容易出现写延迟、吞吐下降等问题，而OceanBase 多节点并行处理，可有效分散写压力，保证低延迟与高吞吐。

4. HTAP 混合负载。

vivo互联网业务线存在大量既有交易又有实时分析需求的混合型业务。引入 OceanBase 后，可同时满足 TP 与 AP 查询，显著简化整体架构。

自建运维平台，统一运维体系

使用 OceanBase 初期，vivo 互联网业务的运维主要依赖开源平台，比如OceanBase 的运维管理平台 OCP。OCP 具备资源管理、性能监控、集群管理、租户管理、备份恢复等完整的数据全生命周期管理能力，可以满足基本的运维需求。但 vivo 互联网业务内部有自建的 DaaS、PaaS 平台，于是存储运维团队启动了将 OCP 的能力集成到自建平台的计划，目前已在业务研发和 DBA 运维两方面实现了一些必要能力。

• 面向业务研发：实现了应用详情查询、数据查询、数据变更等能力。
• 面向 DBA 运维：实现了实例管理、域名管理、账号管理等管理能力。

如图3所示，蓝色背景白色字体对应的功能是已经建设完成的功能；蓝色背景黑色字体是正在建设的功能；白色背景对应的功能为后续规划。通过平台整合，最终形成统一的内部自建运营平台，实现对开源平台的全面替代。

图3 运营平台建设进度

OceanBase带来了哪些收益？

高并发场景，性能提升60%以上

某业务因 MySQL 批量写入过大，每秒40万行的数据操作，导致 MySQL 主从延迟一直居高不下，存在数据丢失风险，同时离线业务无法查询业务数据。该业务切换到 OceanBase 后，延迟问题得到解决，实现了上下游生态产品的数据实时同步。同时，得益于分布式的特性，业务的写入性能得到提升，整体的更新性能也提升了60%以上（见图4）。

图4 某业务切换到OceanBase后的性能提升

大规模数据变更效能翻倍，复杂查询性能提升80%

业务归档库原本使用 TokuDB 存储引擎，数据容量可压缩4倍，虽然缓解了物理机磁盘容量问题，但400亿+的数据量，无法支持 DDL 变更。迁移到 OceanBase 数据库后，不仅数据的存储压缩率和 TokuDB 基本一致，还支持对400亿+数据量的大表做 DDL，仅用时2小时18分钟就能完成， 性能相较于 TokuDB 提升多倍。OceanBase不仅解决了超大规模 MySQL 数据不能变更问题，还实现了与原业务表同步变更，彻底解决了原来大规模归档数据的在线变更难题。

此外，大规模数据量查询业务切换至OceanBase后，整体时延降低了30%以上，实现TP、AP共存复杂业务查询，性能提升80%。

硬件、运维等成本显著降低

得益于 OceanBase 的高压缩特性，数百TB的数据压缩了60%，存储成本节省50%，硬件成本得到显著降低。此外，相较于运维人员对分库分表的投入，OceanBase 原生支持的分区表、自动分区能力及在线扩缩容能力极大地释放了运维人员的双手，使运维成本和业务研发的开发成本大幅降低。

储备国产技术栈，完善运维生态

后续vivo互联网业务计划从如下四个方面陆续落地 OceanBase 并逐步完善运维生态及体系建设。

1. 将分布式关系型数据库长期纳入技术栈。

公司现有数据库产品已覆盖多种类型的数据库，如 MySQL、TiDB、Redis、Eelasticsearch、kv存储 等，但缺少一款经过大规模验证的分布式关系型数据库。经评估，OceanBase 可作为应对海量数据和高并发场景的分布式数据库产品补充，纳入长期产品规划。

2. 国产数据库技术储备。

在国际供应链不确定性增加的背景下，MySQL、Redis 等开源产品存在潜在受限风险。OceanBase 属国产自研数据库，可将其作为关键备用技术栈，持续投入并完善其能力，以保障业务连续性。

3. 运维生态建设。

结合OceanBase的生态工具产品，完善上下游运维生态工具，打造完整的上下游生态，涵盖同步、备份、监控、审计、数据订阅等全部环节，确保业务可无缝接入。

4. 运维体系建设。

持续进行运维体系建设，逐步把 OceanBase 的元数据管理、集群管理、监控告警、自动运维等能力集成至现有统一运维平台，实现与既有体系的风格一致、体验一致。