电商行业对数据库有哪些需求

云集电商作为一家传统电商企业，业务涵盖了美妆个护、服饰、水果生鲜、健康保健等多个领域，在创立四年后在纳斯达克上市（股票代码：YJ）。与京东、淘宝、拼多多等电商平台不同，云集电商采取的是基于社群的社交驱动会员电商模式，主要服务于B端客户。

云集电商通过云集（包括App和小程序）以及云集健康（小程序）两大平台为会员提供服务。相较于其他互联网企业系统，电商企业的一大显著特点是频繁举办大促和秒杀活动，这些活动带来的瞬时高并发流量和高QPS对服务资源提出了极高的要求。此外，云集在选品推送、运营分析、财务数据分析及报表分析等方面，也依赖于大数据计算与分析技术。

因此，我们对数据库的需求首先是稳定性、高可用，其次是应对大促、秒杀场景的扩缩容能力，以及一些通用特性如高性能、高兼容、多中心部署、低成本、安全。此外，架构随着业务的发展逐渐变得复杂后，数据需要流转到大数据侧进行分析、计算后再传输回来，虽然数据算不上庞大，但过程也需要维护。我们希望能有一款支持HTAP场景的数据库来降低数据处理与分析的复杂性。

云集电商应用分布式数据库选型历程

在云集电商成立初期，毫不犹豫使用了世界上应用最广泛的数据库之一的MySQL，所有业务都搭载在MySQL之上。不久，疯狂增长的交易量使财务数据、对账数据迅速膨胀，而MySQL的性能、扩展能力与应对批量数量处理的能力有限，经过我们DBA团队和开发团队的一致决定，需要引入分布式数据库来支撑业务需求。

由于云集电商是在阿里云上，所以选取了阿里云生态中的HybridDB，基本能够满足当时的业务需求。后续因为战略调整，从阿里云迁移至腾讯云，但腾讯云上没有可用的分布式数据库，所以经过调研后选用TiDB数据库作为归档库，以及在边缘业务中应用。这时已完全弃用了HybridDB，业务主要是MySQL，同时对帐数据使用TiDB。

从2020年到2023年，一些众所周知的原因，云集电商的业务量逐渐下降，成本压力成为我们首要解决的问题。彼时，我们使用腾讯云的CDB，业务微服务的架构导致MySQL实例1000+ ，CVM高峰期的实例接近3000个。针对每一个微服务的数据库实例，会有基础的一主一从，另外还会有一个用户从库，一个系统对应三个数据库实例。

同时，业务数据库通过Flink、Canal等组件输出到大数据进行统计分析，生成T+0、T+1的报表。再将分析数据同步回业务数据库，供用户查询，形成数据的循环。

复杂的业务架构与多实例带来的运营成本，使云集电商难堪重负，亟需优化。

由于在使用TIDB的过程中有一些问题，比如扩容后性能提升达不到预期，而且一些参数调整需要重启集群，有时候个别节点会启动失败。因此，出于稳定性考虑，我们没有将TiDB用于核心业务，因此在成本优化之际，便舍弃了这个产品。

在使用TiDB的时候，我认识了一个朋友，这个朋友在后来去了OceanBase任职，机缘巧合下我们就了解了OceanBase，发现其特性更符合我们的战略需求。

• 稳定性强，可持续响应服务，保证整体业务的稳定。
• 兼容性高，简化新技术和架构的应用，降低开发难度，减少学习成本。
• 低成本，极致的数据压缩带来存储成本优化。
• 高可用，多地多中心部署，容灾有保障。
• 不过度优化，避免因过度优化而降低业务的波动能力。
• OceanBase 的吞吐量和生态系统的支持良好。
• 一体化的HTAP 能力能够满足业务高峰交易场景和分析场景的业务需求，简化原有架构，。
• 水平扩展方便，资源利用灵活，同时解决大促场景中MySQL扩容切换导致的业务中断问题。

上文讲到我们最看重数据库的稳定性，OceanBase的稳定性业界闻名，我们就初步试用起来。

云集数据库迁移与成效分析

目前，我们已经将30+个业务迁移到了OceanBase数据库，包括社群系统、供应链、农场项目及其他业务，并且在规划迁移更核心的业务场景，订单系统，预计2025 年迁移完成。下文以其中的农场项目为例讲述迁移过程及收益，并分享其中的经验供大家参考。 

农场项目共有6台主实例，数据量13TB左右，由于是在线业务，在迁移时要求不影响线上用户的使用，最好无感知，同时，我们也希望不需要开发人员改动代码就能实现平滑迁移。另外，考虑到我们的业务生态、中间件如Canal，Flink CDC，还要求新的数据库即OceanBase能够兼容或支持。

明确的需求可以使迁移评估更加高效，基于上述要求，我们做了五项评估，分别是：

• 中间件收集及版本检查，用于判断新数据库是否支持；
• 检查帐号及连接IP等，收集业务访问，以便根据业务情况制定合适的迁移策略；
• 查询新数据库中是否有定义函数，存储过程，触发器及字符集等，对于我们而言是禁用
  的，因为容易引发问题；
• 迁移前处理慢SQL，进行资源评估，预估MySQL数据量迁移后的占用情况；
• 评估总体兼容性和性能。

我们选择OceanBase的迁移工具OMS完成数据迁移和同步。OMS支持多种数据源，可以在线不停服进行迁移，性能也不错，还会进行多重数据校验，其原理如下图所示。

而具体的迁移步骤分为六步。第一步即上文提到的业务检查。第二步做迁移准备，包括慢SQL及数据归档、字符集检查、资源评估、迁移测试链路等，其中如果发现了不支持的字符集，需要在迁移前转换，以保证迁移过程的稳定性。第三步是配置迁移任务，比如创建帐号、配置数据源、配置迁移链路、反向增量同步，然后开始第四步的数据同步，并监视此过程。第五步是，确认迁移结果，选择一个流量较少的时间段将业务重启，切换数据源。

在迁移完成后可能会涉及收尾工作，也就是第六步。对于云集而言，为了减少迁移的复杂性，从MySQL到OceanBase按表迁移，然后再做合库合表，因此，迁移完成后我们涉及同步连接关闭、资源释放、业务改造等收尾工作。在此过程中，我们也发现OMS 每次同步的表数量有限，大约3000个表。也遇到了一点挫折，在使用OBLogProxy时内存泄露，官方人员介入后修复了该问题。

总结

目前，我们已经迁移30+业务，40+MySQL实例，我们最看重的成本优化效果超出预期，服务器成本降低约45%，数据压缩率提高43%。在此之前某些业务的数据量已经突破了单机容量的上线，迁移到OceanBase后，受益于其极致的压缩率，这个问题也顺利解决。

在不久的将来，业务全部迁移完成后，得益于OceanBase的诸多特性，我们预估效果或者说期望达到的效果大概是：

• 一体化的HTAP 的运用使得数据不再需要流转（ETL），直接当成数据仓库使用，极大地降低架构复杂度。
• 多中心的部署方案直接满足等保需求，并借助多中心部署方案满足多活能力

对于一个企业而言，数据库替换就像心脏移植，充满未知与风险，因此，我们需要做好充足的产品选型与调研工作。对于云集电商而言，从MySQL到HybridDB，到在边缘业务试用TiDB，再到如今将大量业务迁移到OceanBase，经历了些许坎坷。希望本文的分享能为同行朋友提供参考意义，也欢迎同行朋友们留言交流。

---

OceanBase 云数据库现已支持 365天 免费试用，现在申请，体验分布式数据库带来全新体验吧 ~