在 DTC（Direct to Customer） 趋势下，零售企业纷纷建设面向最终消费者的大前台，例如自营电商、微信小程序等，使得产品和服务加速迭代。业务需求对 IT 基础设施的要求就是“快”和“准”，云盛海宏不断夯实数据底座来应对外部环境的变化。

【资料图】

云盛海宏是一家零售业科技公司，以科技的力量为门店和线上客户打造 360 度的优秀体验，目前服务中国近万家的线下门店和千万级别的线上会员。

业务挑战

云海零售系统是支撑着全渠道、全品类运动鞋服零售服务平台的关键系统。最初，云盛海宏采用微服务和 MySQL 分库分表的方式支撑云海零售系统。随着业务的快速发展，MySQL 集群在复杂报表分析方面的支持不足。为了解决实时报表的问题，云盛海宏引入了 Oracle 作为报表需求的分担，并通过 Otter 进行数据的实时同步。然而，随着数据爆发式增长和需求难度的增加，基于 MyCAT 的分库分表架构面临新的挑战，需要增加或者调整表结构，从维护层面增加了大量人力成本。此外，Oracle 也遇到了单点性能无法扩展、聚合库分析时效差等问题，云盛海宏开始积极寻求替代方案。

经过详细的对比测试，包括大数据量的查询以及复杂 SQL 的查询性能等方面的细致比较，TiDB 在解决 Oracle 存在的问题方面表现得非常出色且高效。在小规模试用取得效果之后，云盛海宏最终决定正式引入 TiDB。

解决方案

云海零售系统使用 TiDB 支撑面向最终用户的营促销业务，横向扩展能力支持海量数据高并发，通过实时的行为数据分析洞察用户需求，实现对用户生命周期的全程追踪，在 360° 画像的基础上进行产品和服务创新。利用 TiDB HTAP 能力，实时获取跨业务的聚合数据，支撑企业运营管理对实时、复杂数据查询的需求，几千行的业务报表 SQL 也能高效执行。目前，云盛海宏已部署两个 TiDB 集群分别承担前端和后台的业务负载，集群总规模已达百台，数据量将近 15 TB，业务高峰期 QPS 达到两万多，最大业务单表达到了 600 GB。

图：云海零售系统架构示意图

业务价值

高度兼容 MySQL 的分布式数据库

TiDB 原生分布式架构提供灵活的在线扩容和缩容能力，快速响应业务需求的变化。TiDB 高度兼容 MySQL 协议，应用程序可实现从 MySQL 到 TiDB 的无缝迁移，无需考虑分库分表以及分布式事务的实现，降低了业务开发人员的开发与学习等隐性成本。

简化数据栈，节省硬件资源

TiDB HTAP 混合负载能力为企业多个业务提供一栈式数据服务，既能支撑前端业务的在线事务处理，又能支撑多源数据的实时分析。新架构降低了 80% 的 otter 数据同步通道， 与 MyCAT 分库分表架构相比，部分库表冗余度从 10 份降低到 2 份，再加上 TiDB 自带的压缩能力，硬件资源可节省约 50% 左右。

运维工作大幅提效

与管理 MySQL 集群相比，TiDB 可以做到轻量级维护。原先 DBA 以月或者季度为周期需要一次性完成十几个实例的数据迁移，维护工作量巨大且数据迁移风险极高。引入 TiDB 之后，DBA 不用再为 MySQL 日常巡检、归档和备份这些动作耗费时间，大幅提升了运维工作的效率。

“疫情对我们的业务带来了很大冲击，我们开始发力做线上业务，技术侧最直接的压力来自于库存管理模块的变化。原本，从接到需要对接淘宝、京东、唯品会、抖音等平台的需求到最终落地需要三个月甚至半年的时间，但因为我们前期已经切换到了 TiDB，技术栈层面做好了充足的准备，最终只用了两周时间就完成了单平台库存管理模块的调整”，云盛海宏首席架构师洪亮如是说道。