摘要：
滔搏原采用 MyCat+MySQL+Oracle 混合架构，存在成本高、扩容难、数据一致性保障等问题。在数据库切换过程中引入 OB Cloud 后，依托其完善的兼容性、HTAP 融合能力、弹性扩展能力，优化表结构适配原分片策略，低改造完成迁移。升级后存储从 15TB 压缩至 0.9TB，SQL性能提升，扩容高效低风险，运维复杂度大幅降低。
日前，2025 OceanBase 年度发布会在北京举行。在云数据库+ AI 专场，滔搏数据库主管徐子清进行专题分享，介绍滔搏在数据库切换过程中引入 OB Cloud 后的应用实践。
她表示，此次切换并没有带来过高的业务改造或运维成本，不仅实现"无痛"切换和系统"瘦身",也领略到 OceanBase 生态系统中工具的优秀和强大。
以下为演讲实录。
大家好，我是来自滔搏运动的徐子清，很高兴能与大家分享滔搏在数据库架构切换过程中积累的一些经验。
滔搏是中国领先的运动零售运营商，拥有广泛且深度下沉的零售网络，覆盖全国 300 多个城市近 5000 家直营门店，与 20 余个知名运动品牌深度合作，包括耐克、阿迪达斯、亚瑟士等。公司与超过 8000 万用户实现了无缝连接，为消费者提供优质商品、专业服务和美好体验。
随着公司规模的不断扩大，我们在数据库领域也面临着日益严峻的挑战和压力，公司数据库架构也经历多次调整。
数据库历经多轮迭代 OB Cloud 成终选
最早期时，我们采用的是集中式单库，各个地区如华南、华北、西南，分别自行负责本地的数据库系统，每个区域独立维护和运营。每天业务结束后，各地区将当日业务数据上传至总部系统。这样也就导致总部无法及时查阅当日相关数据，造成了数据实时性不足的问题。
2016 年，公司在数据库架构上进行了一次较大的变革，引入了主流数据库 MySQL，并结合 MyCat 中间件，打造分布式架构。随着业务发展，复杂场景越来越多，如总部的某些报表和财务系统新增需求，使得 MyCat 分布式架构也开始面临压力。继而引入了 Oracle 数据库系统，用于支撑报表和一些特殊场景。但近几年业务激增，新的问题也随之而来。
首先是数据库系统整体成本高昂。
之前，传统集中式数据库系统架构是一主四从，而 MyCat+MySQL 数据库架构里，由于数据库节点众多，同时还存在多种同步工具、运维平台等服务，整体服务器体量较大、硬件成本高。
其次，数据库性能方面也存在一定瓶颈。
在混合架构中，MySQL 主要负责在线事务处理（TP）业务，大部分即时性要求较高的分析型（ AP） 业务放在传统集中式数据库系统中运行。但在业务量持续增长的情况下，传统集中式数据库的扩容压力和难度不断增加，对业务发展形成一定限制。
另外，数据一致性的保障也存在一定挑战。
由于架构复杂，存在多种数据库系统之间的数据同步，不同系统之间要保障数据的一致性和实时性，极具挑战。遇到业务异常时，无法快速定位是 SQL 逻辑问题，还是基础表数据有误，亦或是数据同步异常导致数据缺失。排查难度大周期长，面临维护成本高的问题。
在 2019 年到 2020 年期间，业务规模持续扩张，市场需求超出预期，在系统本身面临多维度压力的情况下，我们最后考虑切换数据库系统。
基于时下分布式数据库解决方案综合优势尤为突出，因此将企业的业务系统陆续切换到了某分布式数据库平台。因财务系统最为重要且复杂，且对改造的可控性要求较高，当时并未进行数据库切换。随着业务发展，数据库切换成为势在必行的举措。经过多种方案调研测评，我们最终选择了 OceanBase。
目前，我们的财务系统均已部署到 OB Cloud 集群上。存在数据依赖的业务系统之间，用 OMS 工具进行数据实时同步。
多能力支撑 破数据库运维困局
整个数据库架构的演变，体现了滔搏随着业务发展不断探索和优化数据支撑能力的历程。但很多人会有这样一个疑问：优秀数据库系统那么多，为何最终会选择 OB Cloud？
结合公司业务进行总结，我觉得主要基于以下几方面的原因：
**首当其冲是其完善的兼容性。**OB Cloud 分布式特性与应用透明扩展非常契合我们的系统诉求。同时 OB Cloud 支持多租户的模式。这对于我们拥有多种数据库系统的企业来说意义重大。公司业务发展迅速，新的功能和需求不断增加，研发团队很难投入太多时间进行旧系统大规模改造。因此，兼容性成为我们选型时的重要考量之一。
高性能也是我们选择 OB Cloud 的核心原因之一。财务系统复杂、存在大量分析报表需求，还有不少小万行的 SQL 语句。切换至OB Cloud 后，没有进行特定的 SQL 优化的情况下，部分业务性能已有明显提升。在 OB Cloud 技术专家的支持下，进行了诸如并行查询配置等建议后更进一步优化了我们的业务支持能力，带来了实实在在的体验升级。
弹性扩展能力也是 OB Cloud 的一大亮点。以电商业务场景为例，每逢"双十一"等促销活动期间，为防止业务流量激增、影响业务正常运行，往往需要提前一周甚至更久准备服务器，进行数据库系统扩容。传统架构进行扩容，普遍困难且复杂。而在 OB Cloud 上，我们只需提前一两天即可完成扩容部署，且对应用完全无感知，活动结束后还可及时收回资源，实现效率和成本的双重优化。
此外，OB Cloud 的 HTAP 能力极大简化了我们的系统架构。切换之前我们需要规划不同数据库系统处理不同模块的需求，切换至 OB Cloud 后，通过多租户模式，一套集群同时支持两种传统集中式数据库系统，将 TP 和 AP 的业务场景统一管理，还减少了业务系统之间需要进行数据同步的场景，维护成本大幅降低。
最后，是其卓越的易用性。由于 OB Cloud 高度兼容，所以相关使用者无需在开发、测试过程中花费精力学习新系统，研发同事可以"无痛"完成切换，运维和 DBA 团队也能做到零学习成本、无缝接纳。
作为使用者我必须特别提及的是OB Cloud 团队的技术服务支持到位。整个过程中，技术专家几乎 24 小时在线，在某些特定时期，也会进行现场支持。
OMS 助力切换 实现"无痛"切换、系统"瘦身"
数据库的切换过程平稳高效。我们首先在 OB Cloud 上完成了数据库服务的部署，然后分别从我们各业务数据库系统进行数据同步。
在这个过程中，切身领略到 OceanBase 生态系统工具的优秀强大。个人最被征服的工具还是 OMS，它在我们切换期间不同阶段承担了多种维度的链路支持。OMS 不仅极高效且稳定的同步数据，也可以灵活地按需选择链路环节。
如，我们可以只对表结构进行迁移，也可以选择迁移表结构和全量数据，或者只进行增量同步。对于部分链路，也可以仅做数据校验而不进行数据同步。
在实际使用数据校验功能时，OMS 可详细展示数据库校验结果，一键生成数据修复 SQL，快速实现数据一致性。
总而言之，OMS 工具非常值得推荐，切换前后数据空间压缩比也令人满意。
在之前业务架构下，财务系统业务库的数据量约为 15 TB。引入某分布式数据库后有进行一定程度的去重，例如全局表只选取一个节点进行数据同步，使得数据规模大大缩减，数据量降到约 3.8 TB。而在切换到 OB Cloud 后，数据量又被一定比例压缩了，目前占用存储空间约 0.9TB。
通过数据量对比，可以明显看到切换过程中数据治理和结构优化带来的存储成本节省效果。
OB Cloud 工作台的"诊断"功能可以帮助我们实时监控和分析数据库的 SQL 运行情况。该页面直观呈现系统中出现的大 SQL、慢SQL，可疑 SQL 等各类可能影响业务性能的 SQL 语句，我们能够清晰看到相关 SQL 实际执行耗时和资源占用情况，有效提升了我们对数据库运行状况的掌控能力。
最值得一提的是，这次切换并没有带来过高的业务改造或运维成本，反而带来了高效、低风险的体验，这一点值得点赞。
小贴士
回顾本次切换过程，遇到了不少具有代表性的问题。但在 OceanBase 的协助下，各种复杂问题都得到了有效解决，整体的使用体验很好。
以下是我们的解决方案，供参考，希望能带来帮助：
1.表结构需预处理。原系统的分库表在切换至 OB Cloud 时，需要对原有的分片策略和字段进行相应的分区调整。第一次同步时， OMS 工具检测到存在无主键或唯一约束的表、行迁移未开启等情况，这将直接影响切换后数据库业务是否能良好运行，需对相关业务表调整表结构后手动创建到 OB 租户；
2.从其他分布式集群同步至 OB Cloud 的过程中，OMS 消费 kafka 日志消息只支持特定 kafka 数据格式，会存在多字段唯一索引导致的数据消息串行，处理过程中不免会造成同步效率低下。遇到此类问题时，可考虑调整 OMS 任务中 kafka 数据类型的配置；
3.部分对象如物化视图，OMS 无法直接同步定义，需在相关表对象迁移成功后在 OB Cloud 端手工创建；
4.对于频繁删除、插入数据的传统集中式数据库业务场景，OMS 由于需先解析上游数据库日志文件，再进行 OB Cloud 上的回放，同步效率无法与原生主从同步机制相比。若部分非实时数据业务能接受一定滞后，可以考虑用 OMS 链路同步。