{
"componentChunkName": "component---src-templates-blog-blog-detail-tsx",
"path": "/blog/mysql-migrate-to-oracle-to-tidb",
"result": {"pageContext":{"blog":{"id":"Blogs_489","title":"从 MySQL 到 Oracle 再到全面 TiDB ，云盛海宏的数据库架构实践","tags":["MySQL 架构演进"],"category":{"name":"案例实践"},"summary":"这样一家零售领域的老牌企业是如何一步步转向原生分布式数据库的？整体的架构变迁思路是怎样的？实践过后又是如何从成本视角评价 Oracle 和国产分布式数据库的......本文就上述问题逐一进行了探讨。","body":"## 导读\n\n云盛海宏的零售系统是支持全渠道、全品类运动鞋服的零售服务平台，为全球 8000+ 多家线下门店提供零售服务支持。发展至今，云海零售系统的数据库经历了从 MySQL 到 Oracle 再到全面 TiDB 的架构演进。\n\n**本文由 InfoQ 主编赵钰莹撰写，与云盛海宏首席架构师洪亮共同探讨了云海零售系统整体架构从 MySQL 到原生分布式变迁的思路和收获，以及数据库设计在零售业业务发展中的重要性**。\n\n目前，国内某知名运动品牌在全球经营着 12 家鞋服运动品牌，在全国有近万家线下门店，耐克、阿迪达斯、彪马、匡威等品牌门店绝大部分都是其代理经营，注册会员达 6000 多万，这些业务由旗下科技公司云盛海宏全面支撑。过去十年间，云海零售系统是支撑全渠道、全品类运动鞋服的零售服务平台，支撑了 8000+ 线下门店的零售。\n\n这样一家零售领域的老牌企业是如何一步步从 MySQL 转向原生分布式数据库的？整体的架构变迁思路是怎样的？实践过后又是如何从成本视角评价 Oracle 和国产分布式数据库的......近期，InfoQ 有幸采访到了云盛海宏首席架构师洪亮，就上述问题逐一进行了探讨。\n\n## 背景介绍 \n\n在介绍云盛海宏的数据库架构设计之前，我们先了解下其整体的业务背景。云盛海宏的核心业务是零售系统，包括库存、终端零售以及用于集团内部的财务辅助系统三大模块。\n\n自 2013 年起，云盛海宏就开始搭建整个数据库架构，中间因为业务的不断发展经历了多轮迭代。2016 年之前，云盛海宏基本还处于传统零售时代，内部各大区自建设信息化系统，维护自己的数据库架构，每天向总部上传业务数据，数据库采用集中式单库，这种方式的优点是架构简单，缺点则随着业务发展越来越明显，比如没有办法及时查看地区汇总数据，也无法跨大区查看全国的实时库存等。\n\n为了解决这些问题，云盛海宏在 2016 年上线了全新的架构——云海零售系统，开启了数字化零售时代的架构演进之路。\n\n## 从 MySQL 到 Oracle 再到全面 TiDB 的架构演进\n\n发展至今，云海零售系统主要经历了三个阶段的演进。\n\n**阶段一：应用微服务化，实现数据共享，初步精细化运营，支撑数字化业务发展**\n\n在这一阶段，云盛海宏使用的是微服务+ MySQL 分库分表的方式。立项之初，团队调研时考虑到数据垂直切分的模式短时间内较稳定，MySQL 集群的开发难易程度对团队来说又比较好掌握，所以选定了 MySQL 。\n\n随着业务的飞速发展，很多问题超出了团队的原始预期，MySQL 集群对于复杂报表分析支持不足，团队尝试引入 Oracle 分担这部分需求，再通过 Otter 进行数据的实时同步，保障两边的数据完整。对于 TOB 业务来说，内部报表非常关键，且对数据精度要求极高，冷热数据变化频繁，Oracle 的引入很好解决了实时报表方面的问题。\n\n此后，云海零售系统支撑了业务高速发展的五年，实现了很多小目标，比如实现了全国各地区、各大区的海量数据的存储，实现了数据实时共享，也达到了业务可视化的目标。但是随着业务的扩展和需求难度的增加，慢慢地出现了一些新的挑战。首先，整个架构基于 MyCAT 做分库分表，在日常维护中，如果有新的业务，比如要增加表或者调整表，维护层面会增加人力成本，需要人工调整配置，然后再调用配置，需要花费很多精力。\n\n其次，当时的 Otter 同步渠道已经有 110 +，使用起来也没有那么理想。比如源端加表，目标端没有加表，或者是仅仅是字段的调整也可能导致一些同步的中断，这需要大量人力维护。最主要的是 Oracle 也遇到了一些瓶颈，例如海量数据无法扩展、聚合库分析时效差等问题。\n\n**阶段二：解决数据爆发式增长导致聚合库分析时效性差**\n\n2020 年之前，Oracle 的单点性能已经无法横向扩展，团队开始积极寻求替代方案。此时，团队开始接触到 TiDB ，并于当时 InfoQ 举办的 ArchSummit 大会上听到了时任 PingCAP 联合创始人兼 CTO 黄东旭的详细讲解，后又经过详细的对比测试，主要集中在大数据量的查询以及复杂 SQL 的查询性能两方面，发现 TiDB 可以解决 Oracle 存在的问题并且非常便捷。在内部小规模试用取得显著效果之后，云盛海宏最终决定快速推进 TiDB 集群的部署工作。\n\n\n\n决定将 TiDB 部署到生产时的压测方案（利用了 Percona 公司的开源工具 Percona-playback 实施的压测） \n\n“2020 年，疫情爆发，这对我们的业务带来了很大冲击，我们开始发力做线上业务，技术侧最直接的压力来自于库存管理模块的变化。原本，从接到需要对接淘宝、京东、唯品会、抖音等平台的需求到最终落地需要三个月甚至半年的时间，但因为我们前期已经切换到了 TiDB ，技术栈层面做好了充足的准备，最终只用了两周时间就完成了单平台库存管理模块的调整”，洪亮如是说道。\n\n\n2020 年引入 TiDB 之后的架构图\n\n就内部工程师而言，TiDB 的部署推进得也非常顺利。首先，云盛海宏的主要业务都是在 MySQL 的基础上构建的，TiDB 完全兼容 MySQL 协议，从 MySQL 迁移到 TiDB 是比较顺利的。其次，TiDB 的日常运维、扩容、缩容非常方便，原来 DBA 按月或者季度为周期需要在凌晨一次性完成十几个实例的数据迁移，维护工作量巨大，而且数据迁移风险极高，一旦出现问题后果非常严重，引入 TiDB 之后基本不需要做迁移动作，更别提 MySQL 日常巡检、归档和备份这些动作耗费的时间。最后，MySQL 分库分表带来的局限性无法让团队快速应对变化，公司组织架构的每一次调整都会对业务带来一定冲击，团队需要快速消化这种冲击，TiDB 的引入让整个技术栈更具弹性。\n\n**阶段三：向全面部署分布式数据库迈进，初步探索架构云化**\n\n目前，云盛海宏内部已经完成了 MySQL 到 TiDB 的迁移，从最初的 4.0 版本到目前线上的 5.4.2 版本，每一次升级 TiDB 都会带来比较实用的特性和功能。接下来，云盛海宏会尝试从 Oracle 到 TiDB 的迁移，逐渐收拢数据库集群，更进一步降低运维负担。在云盛海宏内部，Oracle 不会承担太多核心业务和写操作，迁移基本面向 AP 类的数据和业务，所以这部分相对来说比较容易，团队重心会放在前端数据迁移，包括数据准确性校验。\n\n采访中，洪亮表示目前内部的 TiDB 集群的机器规模已经达到 100 台，已经部署了两个 TiDB 集群，分别承担前端和后台的业务负载，计划在 2024 年前完成第三个 TiDB 集群的部署，承担前文所述的 AP 类业务，也就是目前 Oracle 承担的财务报表分析负载。届时，云盛海宏的所有业务将全部运行至 TiDB 集群，Oracle 集群将逐渐停用。\n\n除此之外，整体架构将会逐渐云化。当前，云盛海宏部分应用做了私有云化，未来会尝试将一些环境公有云化，比如开发、测试、培训、生产等。\n\n## 数据库设计核心问题探讨\n\n在零售行业，云盛海宏算得上是对技术投入较大的公司之一，而且结合其业务范围和体量，技术架构的搭建是存在一定难度的，数据库选型和架构演进需要考虑因素很多。在这个过程中，团队也摸索出了一些经验。\n\n**零售业有没有可能完全舍弃 Oracle ？**\n\n在零售领域，有一定历史的企业内部早期肯定部署着 Oracle 数据库，尤其是对精度要求极高的财务数据，那时可替代的国产数据库并不多。如今，国产数据库越来越成熟，可供选择的空间也越来越大，很多企业都开始尝试迁移至其他数据库。\n\n从云盛海宏的经验来看，零售领域未来完全有机会舍弃 Oracle ，即便是要求极高的财务报表数据的处理也可以由国产数据库来负责。\n\n选型上，企业需要提前根据业务特点做好压测，迁移之前也需要做好相关预案，云盛海宏从 MySQL 到 TiDB ，从 Oracle 到 TiDB 都做好了充分的备案。\n\n**从成本视角来看，分布式数据库值吗？**\n\n现在谈到成本，基本涵盖软件授权费用、软件服务费用、硬件采购费用以及日常维护费用等众多维度，企业内部情况不同也存在差异。\n\n从云盛海宏的经验来看，TiDB 相比 Oracle 在软件授权费用上肯定是具备明显优势的；在软件服务费用方面，TiDB 本身的生态和社区建设（包括文档）相对比较完善，但不排除一些国产数据库因为成熟度不足而尚无法投入人力建设成熟的服务生态，这一点需要根据选型情况具体判断；在硬件采购费用方面，云盛海宏使用前后差异不大；在日常维护方面，TiDB 的门槛低、易维护节约了大量人力成本。\n\n如果与管理 MySQL 集群相比，数据备份、硬件故障处理、主从节点管理等相对都比较麻烦，但 TiDB 基本可以做到轻量级维护，后期云化之后可能会更进一步降低运维成本。\n\n**要不要全面云化？**\n\n如前文言，云盛海宏其实未来会逐步云化，其团队内部对此也有很多考虑。\n\n采访中，洪亮表示从整个集群而不是单个数据库的角度出发，云化在机房管理、网络安全、高可用、容灾等层面会比本地部署更有优势。如今，TiDB 和阿里云也有合作，云化是比较容易进行的，尤其是针对原有技术栈基于 MySQL 的企业。\n\n**智能化运维值不值得初期就考虑？**\n\n最近两年，很多数据库都在积极整合 AI 能力，以期让部署、运行、运维等全过程更具智能化。对云盛海宏而言，企业内部对落地 AI 的诉求相对而言没那么迫切。\n\n“智能化运维或者说引入 AI 能力取决于底层的基础建设是否到位，如果存算分离或者是运维能力没有提升，AI 就像是空中楼阁。只有底层基础打好了，智能化运维才能发挥出更大作用。比如，MySQL 的一些指标监控肯定没有 TiDB 完善，没有这些指标，AI 监控就无从谈起了。”","date":"2023-04-26","author":"赵钰莹","fillInMethod":"writeDirectly","customUrl":"mysql-migrate-to-oracle-to-tidb","file":null,"relatedBlogs":[{"relatedBlog":{"body":"## 导读\n\n本文为云盛海宏数据库架构师徐婷的分享实录。云海零售系统是支撑着全渠道、全品类运动鞋服的零售服务平台。本文介绍了云盛海宏云海零售系统所使用的数据库架构从集中式到分布式的演进历程，并根据使用的经验和体验，阐述了为什么选择 TiDB 数据库来支撑其业务，详细讲述了 TiDB 如何在实际使用中助力精细化运营。\n\n大家好，我是徐婷，云盛海宏的数据库架构师，也是 TiDB 的深度用户，很高兴和大家分享 TiDB 在云盛海宏“云海零售系统”中的应用。云盛海宏是一家零售行业的科技公司，以科技的力量为门店和线上客户打造 360 度的优秀体验，目前服务全国近万家的线下门店和千万级别的线上会员。\n\n## 云海零售系统升级历程\n\n云海零售系统是支撑着全渠道、全品类运动鞋服的零售服务平台。在过去的十年间我们的业务系统和架构经历过多次的升级和改造，整体来看就是一个从集中式演进到分布式的过程。在 2016 年之前，各个大区自建设信息化系统，每天向总部上传业务数据，属于烟囱式的数据架构。随着移动互联网和数字经济的发展，该架构也暴露出一些问题，比如说没有办法很及时地去查看地区的汇总数据，也无法跨大区去查看全国的实时库存等。\n\n\n\n为了解决这些问题，我们在 2016 年的时候就上线了全新的架构——云海零售系统。新架构是采用的微服务 + MySQL 的分库分表架构，并通过 Otter 将数据的实时汇聚到 Oracle，用于支撑复杂的报表查询。随着数字化零售时代的开启，汇聚库 Oracle 也遇到了一些瓶颈，例如存储无法扩展、分析时效差等问题，所以我们就引入了 TiDB 和 Oracle 一起支撑业务需求。对于未来的规划，我们希望能借助 TiDB 混合负载特性，支撑我们整个零售系统。\n\n## 使用新的架构支撑数字化业务\n\n2016 年为了支撑数字化业务，我们进行了业务流程的变革，并升级了我们的 IT 架构，上线了云海零售系统，这是当时的系统架构图。基于 MyCAT 进行分库分表和读写分离，拆分的规则复杂一点，基于每个业务系统还有大区都做了一定的拆分，这个架构的好处是将当时比较分散的数据汇聚到了一起。但这套架构也增加了实时分析的难度，做到了数据的共享，但因为数据做了拆分，如果要做一些复杂的需求，比如一些报表，比较复杂的 SQL，还有一些其他业务的时候就会增加相应的难度，一方面由于 MyCAT 对复杂 SQL 的支持有限、另外 MySQL 大表复杂查询效率也有限，所以我们通过 Otter 将数据实时汇聚到 Oracle 中，在 Oracle 上进行复杂的 SQL 查询。\n\n\n\n## 新架构带来的新挑战\n\n这套架构支撑了我们业务高速发展的五年，实现了很多小目标，比如实现了全国各地区、各大区的海量数据的存储，实现了数据的实时共享，也达到了业务可视化的目标。但是随着业务的扩展和需求难度的增加，慢慢地面临了一些新的挑战。由于 MyCAT 分库分表规则基于静态的策略，在日常的使用中需要大量的人工维护，如新的业务或者组织机构合并，需要新建表或者调整数据时，需要调整策略以及手动导数据。 \n\n其次业务对于 Otter 也有很高的依赖度，同步通道 100 多个，维护成本也比较大。源端进行 DDL 操作、大表 DML 操作时，有可能导致同步中断或者同步延迟，人力成本较大。最紧迫的还是在聚合库这边遇到的问题，由于数据量一直增涨，Oracle 很快就面临了单机数据库的存储容量上限问题，并且随着数据增长部分 SQL 效率越来越差。\n\n\n\n## 为何选择 TiDB 分布式数据库\n\n到 2020 年的时候，我们当时已经不得不减少 Oracle 这边数据存储周期，来保障大部分查询的时效性，但同时也导致了有一部分业务需求无法实现。于是我们开始探索其他解决方案，用于解决 Oracle 聚合库这边的问题。 \n\n我们当时调研了 PG XL、Impala、TiDB 这几个方案，综合来看：TiDB 作为一个分布式关系型数据库天然具备水平扩展能力，协议上与 MySQL 兼容，并且复杂 SQL 执行效率也比较高，在解决我们问题的时候成本是最低的。另外 TiDB 文档比较齐全、社区比较活跃，我们的学习成本也比较低。经过了详细测试和业务评估，我们正式引入了 TiDB。 \n\n\n\n## 引入 TiDB 加速精细化运营\n\n下图是云海零售系统引入 TiDB 之后的新架构，使用 TiDB 去共同支撑聚合库这边的一些需求，并且将绝大部分功能迁移到 TiDB 上。TiDB 的实际使用效果超出我们的预期：TiDB 分布式架构可以灵活扩展，数据存储周期越来越长；绝大部分 SQL 从 Oracle 迁移过来时，效率都获得提升，当然也有小部分 SQL 效率退化（通过我们手动调整解决）；之前由于数据存储周期和查询时效性导致的一系列难以实现的需求，目前也可以实现了。\n\n\n\n## 当前 TiDB 使用情况\n\n这个是目前 TiDB 的使用规模，基本上承载了整个系统的数据，总数据量将近 15 TB，最大的业务表单表达到了 600GB。在业务的高峰期，比如上午业务比较繁忙的时候，QPS 达到 20000 以上，地区的业务报表每天最大并发差不多在 300 以上。\n\n\n\n## 经验分享\n\n### 从 MySQL 到 TiDB 的压测方案\n\n我们目前正计划迁移一个业务子系统，迁移的过程中也整理了一些经验分享，供大家参考。对于一个存量系统的迁移，可以认为它是简单的也可以认为是复杂的。简单的原因是因为 TiDB 兼容 MySQL 协议，业务基本上不需要太多改造就可以在 TiDB 上跑起来；而复杂的原因恰好因为不需要太多改造，导致测试的时候可能会遗漏一些边边角角的功能测试，导致上线的时候出现隐患。 \n\n所以目前该系统的迁移，除了有开发、测试同学的人力测试外，还有数据库级别的流量测试。即将源端各个分片的慢查询日志收集起来，根据分片规则作对日志中的库表名进行相应的调整转换，然后利用 perconca-playback 工具去目标端回放，实现流量回放的目的，发现执行异常、执行效率存在差异的 SQL，并进行分析和优化。如果上游是单库的话，只要制定源端慢查询日志和目标端的数据库地址、库名等信息，就可以直接进行流量回放。 \n\n\n\n### 使用中遇到的问题\n\n在使用 TiDB 的两年里面也遇到一些问题：最多的还是优化器生成的执行计划有时不准，像索引选择不准、Join 顺序选择不准、存储引擎选择不准等问题，目前我们基本都是通过在 SQL 中指定 hint 或者在计算节点上设置默认引擎来解决。统计信息也存在一些收集不及时的情况，导致优化器影响较大，目前我们也自己部署了定时收集统计信息的脚本，保障统计信息的健康度。其他的基本上就是一些排序规则和工具上使用上的小问题，影响不大。\n\n\n\n### 改善建议\n\n从 2020 年的 4.0 版本开始使用 TiDB，到目前线上的 5.4.2 版本，每一次升级 TiDB 给我们带来了很多比较实用的特性和功能，像 MPP、中文字符排序、CTE、canal-json 等等，并且持续提升稳定性和性能，是一个非常有活力的产品。当前 TiDB 仍存在一些需要改善的地方：在执行计划正确的时候，TiDB 效率都比较高。但当前仍旧存在索引设计合理、统计信息准确时，执行计划还是不对的情况。而且遇到时，往往都是事后才发现并去手动处理，对业务已经产生一定影响。 \n\n此外，业务上有大量数据批处理操作，当前像 Insert Into ... Select（复杂查询）这样的 SQL 当前无法走 TiFlash，只能走 TiKV，而走 TiKV 一方面效率不佳，另外一方面走 TiKV 时消耗资源可能影响其他正常业务接口。业务上使用到的主数据，基本上都是读多写很少，一天才写 100 多条，写入基本都是从上游下发下来的，对实时性要求不那么高，反而对查询响应及吞吐性能要求很高，而当前 TiDB 缓存表无法缓存整张表数据，导致这个功能在我们这无法发挥出价值。\n\n\n\n## 未来展望\n\n我也想和大家分享一些未来的规划，我们目前正计划升级 TiDB 6.1 LTS 版本，去解锁更多新特性：使用 Placement Rule in SQL，来实现冷热数据的分离以及资源的隔离；新版本 TiFlash 支持更高的并发能力以及更高的处理效率；TiKV 全新日志引擎及内存锁可以提升写入效率并降低资源消耗等等。 \n\n我们计划将 TiDB 应用到更有挑战的场景中，比如使用 TiDB 去升级分库分表的架构，支撑整个零售系统，使用 TiDB 去支撑有更多复杂需求的 Oracle 系统。 \n\n\n\n未来，我们计划将整个零售系统演进到单库的形态，基于 TiDB 混合负载能力，支撑整个零售系统，通过两套集群 + 两套存储引擎的方式，实现业务和资源的隔离，以下是我们未来初步规划的架构。\n\n\n\n预估的收益体现在几个方面： \n- 首先，新架构将大幅降低数据同步通道，预计可从 100 多个降低到 20 个左右；\n- 其次，之前 MyCAT 上存在大量的数据冗余，部分库表冗余度从 10 份降低到 2 份；\n- 由于数据冗余降低，再加上 TiDB 自带的压缩能力，我们预计硬件资源可降低约 50% 左右；\n- 此外，在开发和运维层面，也能大幅提升我们的效率，加速业务需求的快速落地。\n\n整体来说，TiDB 是一款非常不错的产品，对我们来说是相见恨晚的，最后感谢 PingCAP 给我们带来一款这么好用的数据库产品。","author":"徐婷","category":4,"customUrl":"user-case-wonhigh","fillInMethod":"writeDirectly","id":476,"summary":"本文介绍了云盛海宏云海零售系统所使用的数据库架构从集中式到分布式的演进历程，并根据使用的经验和体验，阐述了为什么选择 TiDB 数据库来支撑其业务，详细讲述了 TiDB 如何在实际使用中助力精细化运营。","tags":["TiDB"],"title":"TiDB x 云盛海宏丨加速精细化运营，云海零售系统的架构演进"}}]}}},
"staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}