oceanbase 在vivo互联网的应用实践-c7电子娱乐
编者按：在日新月异的手机通讯行业中，vivo始终保持着先锋者的姿态，不断推动着技术的革新与进步。然而，随着业务的不断扩展和数据量的急剧增长，vivo互联网在数据库方面遇到了前所未有的挑战。原有的mysql数据库逐渐无法满足业务需求，尤其是在处理海量数据和应对高并发场景时，显得力不从心。因此，vivo决定进行数据库替换，寻找一种更加高效、稳定且可扩展的数据库c7电子娱乐的解决方案。vivo数据库工程师王翔分享了他们的数据库替换历程和实践经验。他提到，vivo在选择新的数据库时，充分考虑了业务需求、技术发展趋势以及成本效益等多个因素。经过深入的调研和对比，他们最终决定分布式选型 oceanbase。
作者：王翔，vivo数据库工程师
vivo 互联网数据库现状和挑战：mysql扩容与延迟问题成为瓶颈
vivo互联网主要负责为vivo手机的应用程序提供用户数据存储服务，包括消息推送数据的存储。从2018年至2024年，其数据库业务经历了显著的增长：
- 物理机数量从大约2000台增加至2024年的约5000台。
- 实例规模从1万个扩展至2024年的近10万个，实现了十倍的增长。
- 实例密度，即每台物理机可部署的实例数量，稳定在18至19个之间。
数据库运维规模增长趋势
这些数据清晰地展示了vivo互联网数据库业务在规模上的快速增长。但是，伴随着业务增长，我们同样面临着一系列挑战。
当前mysql数据库的整体架构如下图所示，最上方client为业务访问的客户端，下方dns服务主要为mysql数据库提供域名。再往下，proxy代理层主要负责日志记录、流量管控，实现读写分离的功能。继续深入，则是传统的mysql核心部分一主两从架构。最底层的agent组件，负责探活工作和高可用切换。一旦检测到主库出现故障，agent会迅速进行高可用性切换，将新的主库信息更新到zookeeper, 最终反馈到proxy层，确保业务能够持续稳定地访问数据库。
当前mysql数据库架构
基于上述架构，当前mysql数据库面临两大痛点：
痛点1：mysql的主从架构则存在局限性，无法实现真正的分布式。随着数据量的不断增长，单个mysql集群受限于物理机的磁盘容量，磁盘容量达到上限时，不得不采取分库分表的策略。但随着数据量的持续增大，业务的复杂度和管理成本的成本也随之增加，这对我们的在线业务构成了显著痛点，成为当前业务发展的一个难题
痛点2：mysql的逻辑复制机制也带来了挑战。在流量突增或执行批量任务时，大量的dml操作会导致主从复制延迟。若主库发生故障需要切换，必须等待从库追上主库的数据，确保数据一致性后才能完成切换。这不仅影响了主从切换的效率，还可能对从库的实时查询性能造成负面影响。
mysql作为世界上最流行的开源数据库，以其简单易用和出色的性能而广受欢迎。然而，它在扩容和延迟方面存在的局限性促使我们寻找新的c7电子娱乐的解决方案。
针对以上mysql数据库架构存在的痛点，我们决定引入分布式数据库以解决问题。在对比了多种数据库后，我们选择了国产自主可靠的oceanbase分布式数据库。
vivo互联网分布式选型：为什么选择oceanbase?
分布式数据库有很多, 但随着我们对oceanbase 的深入研究, 最终oceanbase 以其多项显著优势脱颖而出 :
- 自主可控, oceanbase通过国家自主可控认可, 是蚂蚁集团自主研发的数据库，符合我们对数据安全性和自主可控的要求；
- 灵活扩展能力，作为原生分布式数据库，oceanbase支持垂直和水平方向的灵活扩展，能够有效解决mysql扩容受限的问题，同时其分区特性免去了mysql分库分表改造，显著降低业务复杂度；
- oceanbase多租户功能，支持灵活分配租户资源，同时通过多租户资源隔离机制，减少资源争用，确保租户之间互不干扰，保障系统稳定运行；
- oceanbase的高压缩能力和多租户特性，能够节省60%以上的存储空间，同时大幅提升资源利用效率，从而有效降低数据存储成本；
- 在高可用方面，oceanbase的三节点部署模式，支持在不增加资源消耗的情况下实现跨机房容灾，有效保障业务连续性。
- oceanbase对mysql的高度兼容也是一大亮点，这使得业务从mysql迁移到oceanbase时无需经过大量改造，即可实现无缝对接。同时迁移评估、反向同步等功能保障数据实现平滑且安全迁移。
- 此外，oceanbase的htap能力也是我们关注的重点，一套系统同时支持oltp和olap需求，为业务提供了更加灵活高效的数据处理方案。
在引入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数据库的进展情况
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，迁移前进行了一系列前期准备。首先，通过性能评估来确认压测结果是否符合预期；其次，检查原有系统在oceanbase上的兼容性，特别是表结构、sql功能、账号等是否兼容。另外, 还需要考虑分区适应性。当业务使用分区表时，表结构需要做兼容性修改，查询sql也要适配分区表，此时需要结合业务评估业务改造成本。
评估完成后，需关注一些迁移事项：
• 源与目标端字符集保持一致；
• 勿向 ticdc 同步使用的 topic 中写数据，否则会导致 jdbc-connector 异常，报空指针的错误；
• 确认 oms 对 decimal、float 或 double 等列类型的迁移精度是否符合预期；
• 变更目标端的唯一索引，需要重启增量同步组件，否则可能存在数据不一致的问题；
• oms 进行增量数据同步时，必须部署 txcdc kafka，不然无法进行增量同步。
迁移优化
在使用oms工具进行迁移时，有几点注意事项需特别关注。
- 在进行源端迁移时应禁止执行库或表结构变更ddl操作，以确保数据一致性。
- oms不支持目标端存在 trigger oms。
- 目前oms支持的某db数据库版本为4.x和5.4，且不支持迁移该db数据库的无主键表，以及包含空格的数据至 oceanbase 数据库 mysql 租户。
另需注意，oms仅支持txcdc open protocol协议，不支持其他协议。这是在使用oms进行迁移时必须考虑的一个重要因素，如果使用不支持的协议，会导致 jdbc-connector 异常，报空指针的错误
我们曾遇到一个问题，迁移的表虽有主键，但主键分布不连续，这导致迁移速度极慢。因为oms在迁移时会根据主键分区，若主键不连续，则分区过小，严重影响迁移效率。为此，我们后期调整了分区策略，增大了主键分区范围，从而显著提升了迁移速度。
最初，迁移速度约为每秒5000行，经过优化后，最终达到了每秒50万行，提升是非常可观的。
某db 迁移到 oceanbase 的oms数据同步
接下来，关于迁移的同步过程，
- 首先需要创建一个数据源并配置某 txcdc kafka。完成配置后，就进入了常规的迁移流程;
- 接着是前期的配置校验，确保账号数据的一致性；
- 接着，暂停对ddl操作进行表结构修改；
- 然后，切换应用的数据源名称，并处理剩余的数据库连接；
- 此后，停止正向同步，并开启反向同步作为回滚机制，以备迁移不成功时使用。
某db 迁移到 oceanbase 的迁移流程
mysql迁移到 oceanbase
迁移准备
对于mysql到oceanbase的迁移，其流程与某db的迁移大致相似，但相对更为简单。首先也是进行可行性评估；随后使用oms工具执行迁移。在迁移过程中，mysql需要开启binlog，并创建相应的用户账号。
此外，还需关注以下几点：
• 确保源端和目标端数据库的 collation一致，不然可能导致数据同步不一致；
• varchar 作为主键的表数据校验会不一致；
• 确认decimal、float、double 等列类型的迁移精度是否符合预期，可能发生截断现象，导致源端和目标端的数据不一致；
• 确保源端和目标端表结构一致，不然数据同步失败。
迁移优化
关于mysql到oceanbase使用oms进行的迁移，存在多种方案。
- 若连接主库进行迁移，可采取结构迁移、全量迁移、增量同步、全量校验，以及反向增量迁移的组合方式。
- 而若连接备库，则主要进行全量迁移和全量校验。
考虑到直接从主库拉取数据可能带来风险或性能影响，一种优化的迁移模式是：从备库拉取全量数据，同时从主库拉取增量数据，实现主备库协同迁移。
这种迁移流程大致与上文所述相似，包括配置账号、一致性校验等步骤。最终，需将数据源切换到oceanbase，并停止oms正向同步，开启反向同步以备不时之需。
vivo互联网关于oceanbase使用规划
展望未来，我们计划继续迁移更多对业务有痛点的mysql集群至oceanbase数据库，并逐步将线上某分布式db集群全部迁移至oceanbase。同时，我们将大力投入生态建设，针对公司内部mysql的上下游工具，进行oceanbase工具的适配工作，确保业务迁移的顺畅性，让使用者几乎感受不到任何差异。
此外，我们将持续完善oceanbase数据库的工具体系，尤其是daas数据库平台，开发和完善慢日志、审计日志等功能，以及公司内部统一监控告警系统。我们也考虑将当前使用的ocp告警平台整合进公司统一的告警系统中，以提升运维的效率和便捷性。
