作者｜王翔，vivo 数据库工程师
vivo 互联网数据库现状和挑战：MySQL 扩容与延迟问题成为瓶颈
vivo 互联网主要负责为 vivo 手机的应用程序提供用户数据存储服务，包括消息推送数据的存储。从 2018 年至 2024 年，其数据库业务经历了显著的增长：
这些数据清晰地展示了 vivo 互联网数据库业务在规模上的快速增长。但是，伴随着业务增长，我们同样面临着一系列挑战。
当前 MySQL 数据库的整体架构如下图所示，最上方 client 为业务访问的客户端，下方 DNS 服务主要为 MySQL 数据库提供域名。再往下，Proxy 代理层主要负责日志记录、流量管控，实现读写分离的功能。继续深入，则是传统的 MySQL 核心部分一主两从架构。最底层的 Agent 组件，负责探活工作和高可用切换。一旦检测到主库出现故障，Agent 会迅速进行高可用性切换，将新的主库信息更新到 Zookeeper, 最终反馈到 Proxy 层，确保业务能够持续稳定地访问数据库。
基于上述架构，当前 MySQL 数据库面临两大痛点：
痛点 1 ：MySQL 的主从架构则存在局限性，无法实现真正的分布式。随着数据量的不断增长，单个 MySQL 集群受限于物理机的磁盘容量，磁盘容量达到上限时，不得不采取分库分表的策略。但随着数据量的持续增大，业务的复杂度和管理成本的成本也随之增加，这对我们的在线业务构成了显著痛点，成为当前业务发展的一个难题
痛点 2 ：MySQL 的逻辑复制机制也带来了挑战。在流量突增或执行批量任务时，大量的 DML 操作会导致主从复制延迟。若主库发生故障需要切换，必须等待从库追上主库的数据，确保数据一致性后才能完成切换。这不仅影响了主从切换的效率，还可能对从库的实时查询性能造成负面影响。
MySQL 作为世界上最流行的开源数据库，以其简单易用和出色的性能而广受欢迎。然而，它在扩容和延迟方面存在的局限性促使我们寻找新的解决方案。
针对以上 MySQL 数据库架构存在的痛点，我们决定引入分布式数据库以解决问题。在对比了多种数据库后，我们选择了国产自主可靠的 OceanBase 分布式数据库。
vivo 互联网分布式选型：为什么选择 OceanBase?
分布式数据库有很多, 但随着我们对 OceanBase 的深入研究, 最终 OceanBase 以其多项显著优势脱颖而出 :
在引入 OceanBase 数据库的过程中，我们着重进行了生态和平台的建设。我们内部已建立一套完善的数据库管理平台系统，该系统目前支持 OceanBase 的源数据管理以及数据变更操作。用户可以通过此平台进行表结构变更、数据增删改查等操作，并实现了 OceanBase 数据的归档功能。同时，我们正积极建设 OceanBase 的审计日志功能，以确保业务用户在从 MySQL 迁移到 OceanBase 后，能够继续享受与原有平台相同的安全策略和审计支持。
此外，我们还构建了常规的告警监控配置和备份恢复机制，以保障 OceanBase 数据库的稳定运行和数据安全。在下游，我们与大数据生态紧密集成；在上游，我们实现了透明加解密功能，为数据安全提供了额外保障。
2023 年 9 月至 10 月，vivo 互联网决定引入 OceanBase 数据库，并随即在 10 月至 11 月期间对 OceanBase 数据库进行了安全漏洞扫描。同年的 12 月，我们完成了环境部署，并建立了 OceanBase 相关的操作规范。
自引入 OceanBase 数据库之初，我们便开始着手构建告警监控系统，涵盖功能性和性能告警的监测，并持续完善相关文档。此外，我们在去年底时开始对 OCP 及 OMS 进行了高频测试，备份与恢复工作也开始持续进行。于此同时，我们测试了下游的 oblogproxy 工具，对比其日志格式与原生的 Binlog 是否存在差异，并进行了高可用性等关键特性的测试。
2024 年 3 月，我们成功上线了首套 OceanBase 集群，并实现了与 MySQL 的双写功能。经过几个月的努力，今年 7 月，我们顺利完成了该集群的上线工作。其中，从 6 月份开始，我们陆续上线了多套 MySQL 集群，目前仍在持续进行中。
OceanBase 收益分析：降本增效及稳定性增强
收益 1：在线业务延迟大幅下降
在某个线上业务场景中，原本使用 MySQL 进行跑批业务。该业务并非持续运行，而是在短时间内需要处理大量数据操作，每秒需处理约 4~5 万行数据。然而，MySQL 数据库在此高负载下性能严重受限，从库延迟高达 10 万秒，甚至持续攀升至百万秒，对数据库的高可用性和整体性能造成了极大影响。
针对此情况，我们将该业务的数据库从 MySQL 切换至 OceanBase。在仅分配一个租户的情况下，OceanBase 成功应对了每秒 4~5 万行的数据操作，且响应时间保持在约 100 毫秒左右，这一性能表现完全满足了业务需求。
下图为 MySQL 的监控图：
切换到 OceanBase 后，每秒 40 万行数据操作的事务响应时间：
OceanBase 之所以成功解决了 MySQL 在高负载下出现的延时痛点。得益于其分布式架构，允许三个节点并行写入，这一特性显著提升了写入性能并降低了响应时间。
收益 2：稳定性大幅增强, 延迟不再抖动
我们还成功将线上环境的某 DB 集群迁移至 OceanBase 数据库。迁移后，响应时间从原先不稳定的 50 毫秒显著降低至稳定的 35 毫秒，整体响应时间减少了约 30%。上图中的黑色线条代表迁移前 DB 的响应时间，而蓝色线条则展示了迁移到 OceanBase 后的响应时间，表现出更加平稳且低延时的特点。
OceanBase 的稳定性是我们非常重要的一个参考指标。在确保稳定性的基础上，再开发其他功能会更为理想。如果数据库缺乏稳定性，那么它就不会成为我们考量的选项之一。因此，当数据库稳定后，它对业务和用户访问将产生极为顺畅的影响，显著提升用户的体验。
收益 3：超大表 DDL 执行丝滑
在 MySQL 环境中，我们有一张不断增长的大表，由于业务上的限制无法拆分，最终达到了物理机磁盘容量的上限，无法继续存储数据。为了应对这一问题，我们选择了对这张大表进行压缩处理，并选用了 Toku DB 作为压缩工具。这是因为该表的查询量和访问量相对较低，适合在 Toku DB 上进行压缩。
将大表迁移到 Toku DB 后，数据量得以压缩至原来的四分之一，暂时缓解了物理机的磁盘容量压力。然而，随着表规模的不断扩大，数据量最终达到数百亿级，Toku DB 已无法支持对该表进行 DDL 变更，这类操作对于如此庞大的表来说变得极为危险。
因此，我们决定将这张表再次迁移到 OceanBase 数据库上。迁移后，OceanBase 同样实现了四倍的压缩率，有效解决了我们面临的存储和性能问题。
我们对 400 亿条记录的表在 OceanBase 上执行了 DDL 操作，用时仅为 2 小时 18 分钟，这一数据非常可观。这充分满足了业务上在不拆分大表的前提下，对大表处理的需求，是 DDL 操作效能提升的一个典型案例。
收益 4：降本增效, 存储成本减少 60%
接下来，我们实现了大规模集群的降本成效。将一套 35TB 的数据库迁移到 OceanBase 后，存储量降至 26TB，节省了 9TB 空间。此外，我们还迁移了多套 MySQL 集群，总计 20TB 的数据迁移到后，存储量减至 6.6TB，节省了 13.4TB 空间。这些迁移都显著降低了存储成本，实现了降本增效的目标。
OceanBase 迁移实战经验分享
接下来是关于 OceanBase 迁移案例的真实分享，分别总结了从某 DB 数据库和 MySQL 数据库迁移到 OceanBase 的实践经验。
某分布式 DB 迁移到 OceanBase 迁移准备
本次迁移是从某分布式数据库迁移到 OceanBase，迁移前进行了一系列前期准备。
评估完成后，需关注一些迁移事项：
•源与目标端字符集保持一致；
•勿向 TiCDC 同步使用的 Topic 中写数据，否则会导致 JDBC-Connector 异常，报空指针的错误；
•确认 OMS 对 DECIMAL、FLOAT 或 DOUBLE 等列类型的迁移精度是否符合预期；
•变更目标端的唯一索引，需要重启增量同步组件，否则可能存在数据不一致的问题；
•OMS 进行增量数据同步时，必须部署 TxCDC+ Kafka，不然无法进行增量同步。
迁移优化
在使用 OMS 工具进行迁移时，有几点注意事项需特别关注。
另需注意，OMS 仅支持 TxCDC Open Protocol 协议，不支持其他协议。这是在使用 OMS 进行迁移时必须考虑的一个重要因素，如果使用不支持的协议，会导致 JDBC-Connector 异常，报空指针的错误
我们曾遇到一个问题，迁移的表虽有主键，但主键分布不连续，这导致迁移速度极慢。因为 OMS 在迁移时会根据主键分区，若主键不连续，则分区过小，严重影响迁移效率。为此，我们后期调整了分区策略，增大了主键分区范围，从而显著提升了迁移速度。
最初，迁移速度约为每秒 5000 行，经过优化后，最终达到了每秒 50 万行，提升是非常可观的。
接下来，关于迁移的同步过程，
MySQL 迁移到 OceanBase 迁移准备
对于 MySQL 到 OceanBase 的迁移，其流程与某 DB 的迁移大致相似，但相对更为简单:
此外，还需关注以下几点：
•确保源端和目标端数据库的 Collation 一致，不然可能导致数据同步不一致；
•VARCHAR 作为主键的表数据校验会不一致；
•确认 DECIMAL、FLOAT、DOUBLE 等列类型的迁移精度是否符合预期，可能发生截断现象，导致源端和目标端的数据不一致；
•确保源端和目标端表结构一致，不然数据同步失败。
迁移优化
关于 MySQL 到 OceanBase 使用 OMS 进行的迁移，存在多种方案。
考虑到直接从主库拉取数据可能带来风险或性能影响，一种优化的迁移模式是：从备库拉取全量数据，同时从主库拉取增量数据，实现主备库协同迁移。
这种迁移流程大致与上文所述相似，包括配置账号、一致性校验等步骤。最终，需将数据源切换到 OceanBase，并停止 OMS 正向同步，开启反向同步以备不时之需。
vivo 互联网关于 OceanBase 使用规划
展望未来，我们计划继续迁移更多对业务有痛点的 MySQL 集群至 OceanBase 数据库，并逐步将线上某分布式 DB 集群全部迁移至 OceanBase。同时，我们将大力投入生态建设，针对公司内部 MySQL 的上下游工具，进行 OceanBase 工具的适配工作，确保业务迁移的顺畅性，让使用者几乎感受不到任何差异。
此外，我们将持续完善 OceanBase 数据库的工具体系，尤其是 DaaS 数据库平台，开发和完善慢日志、审计日志等功能，以及公司内部统一监控告警系统。我们也考虑将当前使用的 OCP 告警平台整合进公司统一的告警系统中，以提升运维的效率和便捷性。
