云盛海宏：十年后，我们有了一次重新选择数据库的机会 原创

2023年的情人节，可能是疫情以来，商场人流量最大的一次，某国内知名运动品牌也随即打出了促销活动，吸引消费者。

2019年底，可能是零售行业至今以来遇到的最大难关，零售企业该激进，还是保守？

彼时，更多的零售企业还在寻找着新的突破口，寻求继续活下去的可能。而适应变化最重要的一点就是变革，大家都在转向线上销售。

DTC（Direct to Customer，即“直接面向消费者”） 受到了新经济企业的追捧。企业也开始建设面向最终消费者的大前台，例如自营电商、微信小程序、超级 APP 等，这让企业的产品和服务不断加速迭代，私域运营与 KOL 投放等营销手段推陈出新…… 这一系列变化都对企业数据服务平台提出了更严苛的要求。

云盛海宏作为该运动品牌旗下的一家科技公司，承担了核心业务系统。作为云盛海宏的首席架构师，洪亮说：“线上和线下的区别非常明显，尤其是库存管理。”，库存需要快速对接外部像淘宝、京东、抖音等平台，在过去可能需要三个月或半年，现在对接一个库存小程序我们只需要花两周。

云盛海宏首席架构师洪亮

既要支撑海量的消费者，实现快速的前端应用迭代，又要提升营销侧的转化率，以全链条的数据驱动企业经营的实时决策。

所以云盛海宏一直在不断务实技术栈，来面对外部环境的快速变化。对于现在业务的需求，反映到底层架构上就是快和准，云盛海宏正在做的是用领先的技术为业务创新腾挪出两到三年的红利。

给数据库做减法

从2013年开始，云海零售系统就开始筹建。2016年之前，各个大区都是自建信息系统，各大区自己进行数据库的维护，每天向总部上传业务数据。这时的数据库采用的是集中式单库，随着使用暴露的问题也是越来越明显，像无法及时查看地区汇总数据、无法跨大区查看全国实时库存数据等问题。

十年间云海零售系统的数据架构也经历了多次升级改造，主要分为三个阶段。

第一阶段，2016年从传统架构升级为微服务+MySQL分库分表架构，由于MySQL对一些复杂分析报表支持不足，2015年云盛海宏又引入了Oracle进行分担，再通过Otter去进行数据的实时同步，保障两边的数据都是完整的。

洪亮说，早期的线下零售数据量并不大，我们预估MySQL的一个表，承载的极限容量在500-800万，但是MySQL上线三年后，分库分表表单可能超过两千万，每个月都要对一些相对冷的数据进行迁移。大概2015年，MySQL单表已经到了极限，承载不住了。

虽然迁移到Oracle解了燃眉之急，但是也带来了另一个问题，每月都需要对MySQL的数据进行迁移，每月进行一次这样的维护，工作量和风险都是非常高的，因为一个节点就有两千万数据，两个集群就有十几个节点。

第二阶段，到了数字化零售时代，随着数据量增长，Oracle单点性能已经没办法横向扩充，聚合库成为最大的瓶颈，所以又引入了TiDB，来解决数据爆发式增长导致聚合库分析时效性差、海量数据无法扩展的问题。

2020年，云盛海宏积极地寻求新的解决方案，进行了很多数据库产品的调研和测试。选择TiDB一方面是因为完全兼容 MySQL协议，一方面是日常的运维、扩缩容相对方便。

“最主要的原因是，Oracle数据库因为数据存储的时效性提升或者数据量大，导致一些SQL、复杂报表的实现效率越来越低。”洪亮在测试时发现TiDB可以良好地支撑Oralce无法实现的一些需求，这是云盛海宏考虑的重要因素，而且TiDB使用的便捷性也出乎意料。

第三阶段，未来将继续借助TiDB的优良特性解决分库架构导致的扩容、数据同步、合并拆分等问题，支撑整个零售系统发展。

洪亮认为，TiDB的官方文档比较健全完善，查找相关信息很快能找到想要的答案。此外 TiDB 社区的活跃度非常高，对云盛海宏来说学习成本相对低很多。

全部到TiDB还有几步

云海零售系统的架构一直在不断完善，从线下到线上，到对接更多外部系统，现在的云海零售系统已经支撑着8000+全渠道、全品类运动鞋服的零售服务平台。

除了性能，稳定性、易维护性都是云盛海宏关注的，尤其是易维护性，因为专职数据库运维团队只有两个人，所以云盛海宏要用更少的人做更多的事。

“MySQL、Oracle、TiDB，云盛海宏用了很多的数据库，所以迫切需要把数据库做收敛，来降低运维压力。”

现在几乎所有的业务系统都已经迁移到TiDB的集群上，数据将近15TB，region也有将近38万个。在业务的高峰期，比如上午业务比较繁忙时，QPS一般能达到两万多，很多地区自己的一些业务报表，平时最大的并发差不多在300以上，系统里业务表的单表大小最大已经达到了600GB。

目前云盛海宏有前端和后端业务两套TiDB集群，之后还准备部署第三套专门负责数据报表分析的集群。

其实刚开始接触TiDB时，洪亮就觉得分布式HTAP数据库值得去尝试，经过几年小规模的试用之后，发现TiDB适合他们的业务，所以今年也在快速推进，逐步把Oracle向TiDB做迁移。

“现在Oracle在财务还是承担了很大一部分负载，我们也期望做一次Oracle到TiDB的迁移。”洪亮说道，在MySQL和TiDB间的迁移我们做了很多次，比较有经验，但是Oracle到TiDB的迁移我们还在做尝试。

2022年，云盛海宏切换了核心促销系统，预计今年9月左右迁移库存系统，2024年初迁移财务辅助系统，计划最终将Oracle全部迁移。

对于Oracle的迁移，洪亮还是有很多的担心，因为现在零售行业财务系统迁移没有一个可参考的案例，而且去年还上线了财务共享中心。Oracle迁移基本是面向OLAP类的一些数据、业务迁移，所以相对容易，复杂的是在前端数据的迁移，包括数据准确性校验等方面。

面对云盛海宏这样的复杂业务场景，TiDB也在积极建设数据的迁移工具链，包括前端代码的调整等等。

洪亮也说，在2C的领域很少有我们这种场景，而且一个跑了十几年的数据库，突然要做切换是很少见的。云盛海宏希望在业务和企业内部架构上进行优化，配合TiDB的外围工具链，共同努力最终实现Oracle的迁移。

除了Oracle的迁移，之后和PingCAP的合作可能主要会在云上。

对于云盛海宏讲，MySQL是一个历史包袱，因为在2013年没有像TiDB这种数据库可以选择，当然因为授权等各方面因素也没有考虑Oracle，所以最终选择了MySQL。

但云盛海宏并不想止步于此，一直用自己的嗅觉追逐着数据库领域的前沿技术，希望对分布式数据库技术的不断探索与尝试，在零售行业中利用技术优势保持领先性。

所以十年后的今天出现了像TiDB这样的数据库，可以打破这些问题，这对于云盛海宏和对于整个行业而言都是一件幸运的事。