{
    "componentChunkName": "component---src-templates-blog-blog-detail-tsx",
    "path": "/blog/tidb-in-digital-retail-in-dmall",
    "result": {"pageContext":{"blog":{"id":"Blogs_403","title":"TiDB 在多点数字化零售场景下的应用","tags":["TiDB","新经济 DTC 转型"],"category":{"name":"案例实践"},"summary":"本文根据多点 Dmall 数据库团队负责人冯光普在 TUG 企业行成都站的分享整理而成，介绍了在数字化零售场景下，TiDB 在多点的使用情况、核心业务场景支撑、价值分析、及经验总结。","body":"> 本文根据多点 Dmall 数据库团队负责人冯光普在 TUG 企业行成都站的分享整理而成，介绍了在数字化零售场景下，TiDB 在多点的使用情况、核心业务场景支撑、价值分析、及经验总结。\n\n## 一、Dmall OS 数字化零售方案\n\nDmall OS 是多点全渠道数字化零售方案，通过对零售场景中人、货、场全方位数字化解构+重构，赋能零售商和品牌商，帮助客户实现会员数字化、搭建线上线下一体化营销体系、实现门店作业在线化协同、以及智能供应链，助力商家降本、增效、提升客户体验。\n\n![img](https://tva1.sinaimg.cn/large/e6c9d24ely1h3x1byjtqpj21hb0u0tds.jpg)\n\n\n截止到 2021 年 6 月，Dmall OS 已助力物美，麦德龙，711，新百，中百，重百，锅圈食汇，DairyFarm，万宁等 120+ 国内外零售商，覆盖连锁商超、便利店、专营零售等业态；并基于全渠道零售数据为国内外知名品牌实现高速增长。\n\n![img](https://tva1.sinaimg.cn/large/e6c9d24ely1h3x1c3luf7j21hb0u0tcs.jpg)\n\n\n## 二、TiDB 整体使用情况\n\n多点自 2019 年接触 TiDB，目前有超过 30 个 TiDB 集群，服务器节点超过 300 个，总数据量 320TB 以上，其中，最大的 TiDB 集群有 40 台服务器规模，数据量级 60TB，集群 QPS 峰值达到了 100K。\n\n- 2020 年开始调研并在非关键业务中试用，当时版本是 v3.1；\n\n- 2021 年正式跑通上线，在业财融合场景中落地，版本 v4.0.9，除 TiCDC 偶尔出问题，整体比较稳定；\n\n- 2022 年整体升级到 v5.1.4 后，TiCDC 稳定性问题也得到彻底解决，研发和 DBA 睡觉非常踏实；\n\nTiDB 大版本升级，使用 TiUP 仅一条命令即可完成，滚动的方式，过程中业务也很平滑，深得 DBA 喜爱\n\n![img](https://tva1.sinaimg.cn/large/e6c9d24ely1h3x1c0v7zej21hb0u0tbc.jpg)\n\n![img](https://tva1.sinaimg.cn/large/e6c9d24ely1h3x1c1ba5hj21hb0u0q53.jpg)\n\n当前各行业数字化转型，将领域对象、流程、场景数字化，实现实时在线、高效协同、智能决策，垂直领域的 SaaS 解决方案不断涌现，它们在助力企业降本增效的同时，在数据方面也面临以下技术挑战：\n\n1. **数据持续快速增长**，对于 MySQL 等开源单机数据库，达到容量上限需引入分库分表方案，比如 Sharding-JDBC，这类方案虽然逻辑上透明，但使用后 SQL 能力受限，实际很难执行跨节点 SQL；\n\n1. **实时商业洞察**，数据规模大且产生速度快，对 AP 也提出了挑战，T+1 的方式已经难以满足商业洞察和决策的需求了，比如：商家营销活动的执行效果分析，如果依赖 ETL 抽数+离线计算的技术方案，就无法在活动进行中及时优化营销策略，提升有限资源的回报率；\n\n1. **更低的成本**，不仅是资源层面的存储成本，计算成本，也包括架构及维护成本，弹性可扩展的云原生架构是未来的发展趋势；\n\n![img](https://tva1.sinaimg.cn/large/e6c9d24ely1h3x1byxywqj21hb0u0taq.jpg)\n\n\n## 三、核心业务场景支撑\n\nTiDB 在多点 Dmall 的典型应用场景，简单归纳，主要有以下三类：\n\n1.**海量流水类存储**，使用 TiDB 直接替换了 MySQL，多并发批量写的方式，充分发挥 TiDB 高吞吐的优势，典型场景：App 推送记录，短信发送记录，单次营销活动产生的记录可达千万规模，从 MySQL 切换到 TiDB 后，DBA 就告别了容量焦虑，不用频繁归档历史数据，且 RocksDB 引擎相对 InnoDB 引擎有 3~10 的压缩优势，成本比使用 MySQL 更低；\n\n![img](https://tva1.sinaimg.cn/large/e6c9d24ely1h3x1c2otu7j21hb0u0wh4.jpg)\n\n\n2.**冷热分离全量存储**，对于响应时间敏感，同时数据持续快速增长的在线业务，采用读写分离架构，将近期热数据存储在 MySQL，提供高并发低延迟的在线读写，同时实时同步到 TiDB，保存全量数据，提供历史快照查询及统计分析，支持业务数据变更溯源。典型场景：商品调价、库存变更，数据量超过了单机 MySQL 容量，且持续增长，基于自研的 DRC-TiDB 组件（它可过滤源端 MySQL 归档 DELETE 事件，同步 MySQL 数据到 TiDB），避免了数据增长超过 MySQL 单机容量后水平拆分的技术复杂度；\n\n![img](https://tva1.sinaimg.cn/large/e6c9d24ely1h3x1c1r4n9j21hb0u0gon.jpg)\n\n\n3.**多源聚合存储及分析**，中台思想及微服务技术架构，实现了在业务域清晰划分下的技术能力复用，及研发高效分工协同，但也导致了数据散落到各个业务子系统中，全链路的业务聚合分析变得困难，在数据规模超过单机存储容量，且要求准实时性分析时，问题更甚。TiDB 透明的水平扩展能力，及 TiFlash 引擎 AP 能力，为这类场景提供了可行方案，典型场景：营销活动分析，聚合同步了多个在线 MySQL 业务库及 MQ 的数据，在 TiDB 中实时计算活动效果，助力运营评估和优化营销策略。\n\n![img](https://tva1.sinaimg.cn/large/e6c9d24ely1h3x1c0d5xfj21hb0u041m.jpg)\n\n\n## 四、TiDB 价值分析\n\n站在研发的视角，使用 TiDB 的好处：\n\n1. **更简单的架构**，TP 分库分表 + ETL 同步聚合 + AP 分析引擎，这种技术架构，除了技术复杂度、资源成本高、运维困难外，结构/数据一致性难以保证，ETL 同步延迟也是常态。TiDB 提供了另外一种可能：基于内建的 Raft learner 数据复制技术简化了架构，实现 TP 业务和 AP 业务基于同一份数据，避免了一致性和延迟问题。\n\n1. **实时数据分析能力**，基于 TiFlash 列存引擎，及 MPP 计算架构，实时业务数据集上的直接分析得以实现，得益于 TiKV 的水平扩展能力，上游数据的流入和存储几乎无限制，更多的数据，可放大实时数据分析的价值。\n\n1. **专注业务创新**，在充满不确定性的商业竞争中，为快速验证 MVP，业务早期存储选型采用简单易用的 MySQL，但在数据规模达到单机容量上限引入分库分表等技术后，业务研发就需要关注底层存储架构的约束和限制，开发效率降低；甚至权衡性能、稳定性、或成本被迫放弃部分需求特性，业务创新也受到影响，丢失早期竞争优势。TiDB 提供了另外一种可能：在业务进入快速增长阶段，底层存储的扩展对上层业务真正透明，让研发可以专注于业务创新和快速迭代。\n\n![img](https://tva1.sinaimg.cn/large/e6c9d24ely1h3x1c29j0bj21hb0u0dhx.jpg)\n\n\n站在运维 DBA 视角，使用 TiDB 的好处：\n\n1. **云原生红利**，TiDB 符合云原生架构理念，不论计算层，还是存储层，加机器即扩容，可按需、弹性、近乎无限扩展，相较于 MySQL 分库分表方案的技术复杂、实施门槛高、SQL 能力受限，大规模快速增长数据场景下，运维 TiDB 幸福指数高于运维 MySQL；\n\n1. **MySQL生态友好**，TiDB 兼容 MySQL 协议，已建成的平台工具，可直接复用，比如：查询工具，慢 SQL 分析，监控指令等，DBA 可快速上手为研发提供数据库接入服务；\n\n1. **数据可靠性高**，MySQL 需要依赖外部 HA 组件实现故障切换，除部署配置复杂外，还难以彻底避免脑裂问题，TiDB 内部实现了基于 Raft 的数据同步和故障切换，failover 高效可靠，数据强一致保证，DBA 几乎没有心智负担；\n\n![img](https://tva1.sinaimg.cn/large/e6c9d24ely1h3x1c43op7j21hb0u0ac4.jpg)\n\n\n在成本方面，TiDB 一直有很多争议：1）组件多，有 PD、TiKV、TiDB 等；2）多副本+高可用，集群部署起步成本较高，会劝退很多用户。根据我们实际使用经验，成本方面的真实情况是：\n\n- 在数据规模较小，如在单机 MySQL 容量以内，主从两节点 MySQL 集群，成本是远低于 TiDB 集群的；\n\n- 当数据规模超过单机 MySQL 容量，需要引入 sharding 方案后，情况会发生变化，使用 TiDB 可能比使用 MySQL 更便宜，主要因为：\n\n- TiKV 的 RocksDB 引擎相对 InnoDB 引擎，有 3~10 倍压缩优势，存储相同规模数据，TiDB 的存储节点数远远低于 MySQL 集群；\n\n- 随着数据规模增长，只有 TiKV 节点数是随之增长，PD 节点的成本基本不增长，而 TiDB 节点数是与 QPS 相关；\n\n- 还需考虑引入 sharding 方案后，技术复杂度提升，SQL 能力受限，会带来运维成本的升高，以及开发效率的降低；\n\n![img](https://tva1.sinaimg.cn/large/e6c9d24ely1h3x1c367i4j21hb0u0tba.jpg)\n\n\n## 五、实践经验及场景对比\n\n从使用 MySQL 切换到使用 TiDB，需要重点关注和理解分布式架构的优缺点，尤其是算存分离以及分布式事务带来的网络开销，局域网的网络交互延迟，与读写 SSD 的 IO 延迟在一个级别，它远远高于单机数据库进程内的数据交互，简单总结一下，结论：\n\n- TiDB 相比 MySQL 响应更慢；\n\n- TiDB 相比 MySQL 可输出吞吐更高；\n\n因此，建议采用多并发、批量读写的方式，以发挥 TiDB 的优势。\n\n![img](https://tva1.sinaimg.cn/large/e6c9d24ely1h3x1bzgnq6j21hb0u00vc.jpg)\n\n\n下图是 MySQL 与 TiDB 的详细优劣势对比和选型参考，在数据规模小，要求低延迟的 TP 业务场景中，MySQL 更加合适，而在数据规模远超单机容量、持续快速增长、对响应延迟不那么敏感的 HTAP 业务场景中，使用 TiDB 更加合适。\n\n![img](https://tva1.sinaimg.cn/large/e6c9d24ely1h3x1bzv2z0j21hb0u00vy.jpg)\n\n\n## 六、总结\n\n- TiDB 基于云原生理念，采用算存分离架构，可以按需、弹性、近乎无限的水平扩展；\n\n- 基于 TiDB 的 HTAP 能力，可实现同时支撑 TP 业务和 AP 业务的一体化架构，综合成本低；\n\n- TiDB 与 MySQL 相辅相成，生态友好，是优秀的面向数据快速增长的理想选择。\n\n> 延展阅读：  \n[“新经济 DTC 转型背后的数据库”专题 ](https://pingcap.com/zh/events/database-behind-new-economy-digital-transformation)   \n点击查看更多[新经济 DTC 转型案例实践](https://pingcap.com/zh/blog?tag=%E6%96%B0%E7%BB%8F%E6%B5%8E%20DTC%20%E8%BD%AC%E5%9E%8B)","date":"2022-07-07","author":"冯光普","fillInMethod":"writeDirectly","customUrl":"tidb-in-digital-retail-in-dmall","file":null,"relatedBlogs":[{"relatedBlog":{"body":"> 嘀……“请问您有多点会员吗？”  \n> 对于经常去物美、麦德龙等大型连锁超市的人来说，扫码的嘀嘀声和随后的这句话应该是非常熟悉的。但作为专业的商超数字化系统供应商，多点所做的绝不只是收银这般简单。在全新业财一体战略的支撑下，多点的 Dmall OS 不仅是超市顾客每天都能用到的系统，也是 CFO 和 CEO 每天都会关注的系统。\n\n## 业财一体为企业带来的美妙图景\n\n多点是面向新零售的数字解决方案提供商，旗下的 Dmall OS 产品是统合了人、货、场的全场景云化解决方案，也是多点的拳头产品。以此为基础，多点的下一步则是为零售企业提供具备业财一体能力的经营大脑。\n\n以往，企业需要通过大量基于场景和流程的业务应用来实现业务数字化，但与此同时，**企业管理层更关心的财务数据却由运行逻辑、统计口径、统计方法完全不同的财务系统产生**。这种业务与财务的相互脱节也使得企业很难快速掌握当期经营数据，无法通过及时的财务反馈来调整业务策略和经营方针。而所谓业财一体便是要打破两套系统之间的重重隔阂，让业务层面的变化直接反应在实时进行的财务统计当中，使企业在激烈的市场竞争中获得灵活的身段、矫健的身手。  \n\n![640.png](https://img1.www.pingcap.com/prod/640_8d071d88be.png)\n\n从实现之后的效果来看，业财一体对于企业来说足够美妙，但在实际的系统构建过程中，业财一体的实现却充满挑战。\n\n以 Dmall OS 面向的零售商超行业为例，其业务端对应的是海量的交易笔数和庞大且分散的门店数量。要为商品管理、收银、会员等基础业务提供支持，Dmall OS 需要配备一套强大的 OLTP 数据库。而其财务端所需的各类分析功能却是典型 OLAP 应用，因此，在理顺业务逻辑、完成系统对接之前，大量数据还需完成从 OLTP 到 OLAP 的数据导入。而业财一体概念中关键的实时性要求则意味着，**Dmall OS 一边要保证 OLTP 数据库的性能、可靠性，另一边还要完成数据的实时导入、实时同步、实时分析**，实现难度可想而知。\n\n看懂了这层难点，我们也就很容易理解为何很多企业的业财一体无法实时，只能异步了。\n\n不过 Dmall OS 已经跨过了这些技术门槛并获得了物美、麦德龙等一系列行业顶尖用户的认可和青睐。而在底层帮助 Dmall OS 实现业财一体这一关键转型的赋能工具正是 TiDB。\n\n## PingCAP 的 TiDB，多点的业财一体\n\n其实，多点所遇到的数据库挑战并不罕见。\n\n一方面，以收银、库存等为代表的基础业务对应了典型的 OLTP 数据库应用，而超市业态庞大的销售额则让**这部分业务对性能、稳定性等有着颇高的要求**。在满足这部分业务需求时，和大多数互联网企业一样，多点在开始之初选择了开源的 MySQL，性能不错、生态丰富、人才充沛且二次开发方便是其最大优势。但作为一种诞生自 90 年代的技术，MySQL 仍旧无法在“数据量增长所导致的性能下降”和“通过复杂且高风险的分库分表操作来保证性能”之间取得良好的平衡。\n\n另一方面，为实现业财一体功能，**多点 Dmall OS 还需要一套能够为报表合并及海量数据分析提供支撑的高性能 OLAP 数据库**。并且，为了保持软件堆栈的整体开源和业务人员的操作连贯性，新数据库同样需要是开源的，并且最好能够与 MySQL 有着类似的操作逻辑和语法。\n\n当然，如果多点只是用另外一套 OLAP 数据库来满足财务分析需求并承担双数据库所带来的运维成本升高的话，那么故事到此就结束了。但 TiDB 给多点提供的却是一条完全不同的路径。\n\n作为一款具备 HTAP 能力的数据库，**TiDB 可以同时满足 OLTP 和 OLAP 两种不同应用的需求**。在面对多点业财一体中的 OLAP 需求时，TiDB 能够提供高性能的分析能力，满足业财一体在财务端的报表合并及分析需求。借助强大的 TiFlash 列式存储引擎，TiDB 在面对 6.8 亿行大表全表聚合查询时仅需 5 秒左右便能得到结果，40 亿行超大表全表聚合仅 38 秒左右，由此多点的 OLAP 业务也达到了实时级别。\n\n![641.png](https://img1.www.pingcap.com/prod/641_a8cca9b3be.png)\n<center>业财一体化架构图</center>\n\n而 TiDB 的 HTAP 能力则意味着多点可以首先在 OLAP 领域部署 TiDB，解决现有痛点。待积累了足够丰富的操作、业务经验之后，多点便可以更低的成本和风险统一切换至 TiDB，实现数据库层面的架构统一，简化运维，为更进一步的数据平台建设打好基础。\n\n作为全新一代云原生数据库，**TiDB 不仅有着极高的执行效率，也支持用户通过集群和横向扩展来轻松应对数据量和业务需求的增长**，避免传统数据库分库分表所产生的巨大工作量和风险。而作为一款开源产品，TiDB 不仅符合多点的总体技术路线，其活跃的社区和强大的原厂支持也能让多点在不被绑定的基础上无忧面对未来变化。同时，在操作和语法等层面，TiDB 也尽量与 MySQL 保持一致，能够让用户的操作经验和使用习惯前后统一。\n\n在实际部署当中，承担 OLTP 业务的 MySQL 和承担 OLAP 的 TiDB 之间通过 PingCAP 开发的 TiDB DM 工具和相关 API 实现高速数据同步，并且保证了金融级的数据一致性。\n\n在 TiDB 本身强大的功能、性能以及原厂工程师的全方位支持下，**多点不仅通过集群的横向扩展让业财一体服务有了伴随客户共同成长、壮大的空间，更完全解决了业财一体所对应的 HTAP 需求**。而在日常运维中，TiDB 的扩展能力也将多点的运维人员从分库分表的繁琐操作中解放出来，大幅降低了多点的数据库运维成本和工作量。\n\n面对新技术、新产品时，企业的选择通常都是保守的，因为这事关业务稳定性，在数据库层面更是如此。而多点这种新业务用新数据库、老业务用成熟产品的“喜新不厌旧”的部署方式则证明，TiDB 的 HTAP 能力、多样功能和强大适应力能够为企业提供一条渐进式创新的稳健路径，让企业在“数据库切换”这一数字化转型的关键环节中有更充足的转换和适应空间。\n\n## 好的系统，应该“喜新不厌旧”\n\n从最简单的收银系统开始，到人、货、场在数字空间内的重构，再到更高级的业财一体和经营大脑，一路走来的多点发展路径非常清晰：**在把当下做好的同时，每次多一点、再多一点**。以稳健为前提，通过循序渐进的功能和架构演进，直至经营大脑各项功能的完整构建。多点的发展逻辑既是看得见、摸的着的，更是能够令各大商超企业信服的。因此，我们才能看到一众行业巨头愿意将多点 Dmall OS 作为自己的经营大脑，将业务、财务、决策放心交付。\n\n多点的渐进式创新也证明，PingCAP 的 TiDB 不仅具备先进的性能和架构，更拥有完善的工具、接口和服务支持，能够在与传统数据库的联合作战中从容自如。而对于广大用户来说，这样的应用方式则提供了一个低成本、低风险且快速切入新技术的绝佳机遇。\n\n**可咸可甜、喜新不厌旧，这是商业经营持久长青的秘密，更是以 TiDB 为代表的新一代数据技术所应有的样子**。\n\n> 延展阅读：  \n[“新经济 DTC 转型背后的数据库”专题 ](https://pingcap.com/zh/events/database-behind-new-economy-digital-transformation/?utm_source=blog&utm_medium=banner&utm_campaign=new-economy-dtc)   \n点击查看更多[新经济 DTC 转型案例实践](https://pingcap.com/zh/blog?tag=%E6%96%B0%E7%BB%8F%E6%B5%8E%20DTC%20%E8%BD%AC%E5%9E%8B)\n","author":"PingCAP","category":4,"customUrl":"do-you-have-a-dmall-membership","fillInMethod":"writeDirectly","id":362,"summary":"多点是面向新零售的数字解决方案提供商，旗下拳头产品 Dmall OS 是物美、麦德龙等超市顾客每天都会用到的系统，也是 CFO 和 CEO 每天都会关注的系统，在底层帮助 Dmall OS 实现“业财一体化”关键转型的赋能工具正是 TiDB。","tags":["新经济 DTC 转型"],"title":"您有多点会员吗——数据库渐进式创新助力多点稳步推进经营大脑实践"}}]}}},
    "staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}