TiDB x 云盛海宏丨加速零售系统精细化运营

在 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,技术栈层面做好了充足的准备,最终只用了两周时间就完成了单平台库存管理模块的调整”,云盛海宏首席架构师洪亮如是说道。