{
"componentChunkName": "component---src-templates-blog-blog-detail-tsx",
"path": "/blog/user-practice-of-migrating-from-oracle-to-tidb",
"result": {"pageContext":{"blog":{"id":"Blogs_491","title":"从 Oracle 迁移到 TiDB 的方案设计与用户实践","tags":["Oracle 迁移"],"category":{"name":"案例实践"},"summary":"本文以中国人寿财险公司为例，详述其从 Oracle 到 TiDB 分布式数据库的四个阶段的迁移，展示了金融行业对数据库的高要求和国产数据库的价值应用。","body":"> 作者：盛玉，中国人寿财险金融科技中心系统运行部；王耀强，PingCAP 资深解决方案架构师\n\n## 导读\n\n当前，全球数字化浪潮推动数字经济与实体经济融合，更多的企业意识到数据平台对业务增长和创新的重要性。通过国产化迁移和替换数据库，中国数据库市场蓬勃发展，为企业自主创新奠定了基础。本文以中国人寿财险公司为例，详述其从 Oracle 到 TiDB 分布式数据库的四个阶段的迁移，展示了金融行业对数据库的高要求和国产数据库的价值应用。\n\n## 背景和前言\n\n当前，数字化浪潮席卷全球，随着大数据、云计算、移动互联网等数字技术的广泛应用，数字经济与实体经济深度融合的趋势越加明显。在数字化转型加速期，全球企业与组织深刻意识到数据平台是业务发展的重要驱动力，如何有效利用数据，充分释放数据价值，成为业务增长和创新的关键基础。\n\n近年来，科技创新、科技自立自强已作为重要发展战略，中国数据库市场正迎来发展的黄金窗口期。在 IT 基础设施之中，数据库作为三大基础软件之一，承载了各类业务系统的不同种类数据，如客户信息类、交易流水类、用户行为类等，通过对底层数据库的国产化替换和迁移，为企业 IT 系统的自主创新奠定坚实的基础。\n\n## 业务系统替换升级的发展路径\n\n企业在不同时期、由不同业务部门主导来推动信息系统的建设，割裂的烟囱式架构使得系统之间的数据无法打通并利用。数字化转型和国产数据库的迁移工作，并不是简单的对传统商业数据库产品（如 Oracle 等）替换，更是要站在企业发展的战略高度，重新对业务、应用、技术架构等方面进行综合考量，满足企业可持续规模化发展的需求。金融机构在国产数据库替换道路上，呈现出两类发展路径：\n\n### 对成熟商业数据库的平行替换\n\n金融机构有部分业务系统由于开发时间较早、熟悉代码的人员较少、又特别依赖于成熟商业数据库的特性等原因，往往会优先选择不改或者少改应用、使用兼容商业数据库特性的国产数据库进行替换。虽然短期内能够实现快速替换，但长期看这种方案使得技术债进一步堆积，用户对原有数据库的粘性没有减少，业务开发人员的习惯并没有改变，因此“平行替换”适用于相对较传统的应用。\n\n### 从集中式到分布式的架构跃迁\n\n分布式、云原生为代表的新技术的出现，为数据库技术突破实现弯道超车做好了理论铺垫。伴随着数据使用场景的多元化，对于海量数据增长迅速、高并发读写、高峰业务弹性需求大的业务系统，集中式商业数据库已经无法支撑，从敏捷开发迭代、技术自主掌控、业务连续性等角度进行评估，金融机构更倾向选择国产分布式数据库实现架构的跃迁，这样才能在基础架构层面开辟自主创新的道路。\n\n## 从 Oracle 迁移到 TiDB 实践\n\n金融行业对于数据库的要求极其严苛，“稳定、高可用、高并发、高扩展”是选择合适国产数据库的多维度考量标准。TiDB 作为原生分布式数据库，已广泛应用金融、互联网、电信、能源等各行各业中的不同业务场景，在积极协助企业稳步推进国产化相关工作，并总结了数据库国产化迁移的实践经验。\n\n为响应国家层面“加快建设科技强国，实现高水平科技自立自强”的号召，中国人寿财险公司积极推进数字化转型，启动 IT 架构的整体规划工作，探索业界先锋技术及进行分布式架构转型。在数据库的国产化迁移过程中，按照先边缘再核心的策略稳步推进，目前已完成多个核心业务系统从 Oracle 到 TiDB 的迁移改造工作，同时也为后续多部署形态的架构打下了坚实的基础。本文以中国人寿财险公司核心系统的改造实践为蓝本，阐述通过四个阶段的分步骤实施，实现从 Oralce 迁移到 TiDB 分布式数据库。\n\n\n中国人寿财险核心系统分布式数据库改造历程\n\n### 迁移准备阶段\n\n首先是对分布式数据库的选型，从数据库产品特点是否与业务场景匹配，满足业务平滑迁移及持续发展；是否完全自主研发，保证产品的持续演进能力；是否有完善的生态建设，包括上下游工具、文档体系、培训体系；是否有广泛的行业用户案例；是否支持云原生，满足未来的架构演进等角度进行综合评估后进行决策。\n\n其次是迁移改造规划，主要涉及迁移改造量分析、迁移方案制定和回退方案制定几个方面。异构数据库之间的迁移适配，通常涉及应用系统的改造。以保险为例，保险业务逻辑处理复杂，各业务系统之间的调用关系、完成整个交易的复杂度较高。中国人寿财险制定的策略是不再依赖封闭的商业数据库特性，而是由应用来主导业务流程实现，实现系统分布式微服务架构的转型。应用改造分析主要包括各系统间调用模式、微服务的设计等。异构数据库的改造分析，涉及数据库对象改造（表结构、其他对象等）、SQL 语法改造、运维工具改造和流程变更等；通过提供的 O2T schema 比对工具，可以比对 schema 迁移后，检测出是否有表、视图、或索引遗失的情况。\n\n迁移方案的制定需要结合系统的存量数据及每日增量数据情况，制定切换前全量截面数据加截面后增量追数的迁移方式，形成了迁移手册及迁移中使用的脚本工具，为后续项目的开展提供经验支持。借助 Kettle、SQLULDR2 与 Lightning、国产数据库同步工具、OGG 等多种模式，丰富数据迁移方案、实现差异化的需求，同时可以通过 o2t-sync-diff 工具比对 Oracle 和 TiDB 的快照数据正确性。\n\n数据库是保险企业信息系统当中的关键基础设施，稳定运行是重中之重，因此也需要制定完善的回退方案。从 Oracle 到 TiDB 迁移，可以使用 OGG 进行数据实时同步，反向同步通过 TiDB Drainer 工具把 Oracle 作为目标库，实现高效的反向回退。\n\n\n从 Oracle 迁移到 TiDB 的并行和回退机制\n\n### 开发测试阶段 \n\n开发阶段需要对于原有业务系统使用的数据库对象类型、数据库函数功能等进行细致分析，通过 Oracle 到 TiDB 的数据类型映射、函数映射等指导手册、并结合 TiDB 数据库开发规范，完成代码开发及单元测试工作。测试阶段需要涵盖功能、性能、高可用、流量双发和回退测试。在系统开发完毕之后，需要进行各业务功能测试，并按照 3-5 年未来业务量的数据存储基线做性能测试，完成业务单交易负载测试、混合交易负载、水平扩展性测试等各项压力测试，验证高并发条件下数据库所能承载的业务流量。\n\n在高可用测试方面，需要完成分布式数据库生产部署架构搭建、进行数据库基础组件故障演练，进行数据库同城和异地切换演练，以及进行数据库物理备份和逻辑备份恢复等测试。流量双发测试可以对生产业务流量进行异步复制，搭建生产流量双发并行环境，实现 100% 全量业务生产级别仿真执行，对执行结果利用 o2t-sync-diff 比对工具进行生产和并行环境数据的比对验证，同时在并行环境搭建 TiDB Drainer 数据库增量回退链路，实现数据库日志级别的一致性数据同步，进行应用和数据库回退演练。\n\n### 投产切换与运行保障\n\n投产切换的所有步骤严格按照投产前演练的顺序和操作方式进行，防止出现流程上以及操作上的风险。以中国人寿财险报价中心投产切换为例，为了防止投产风险，制定了分批切换策略：第一批按照 10% 的业务流量将部分典型渠道进行切换验证，数据迁移按照全量和增量迁移，无需回退；第二批按照 30% 的业务流量将标准和个性化的业务进行切换，重复第一批迁移流程，部分业务表进行回退链路搭建；最后一批切换 60% 的核心业务流量，新增部分核心业务表的回退链路。在投产后进行 48 小时内进行数据库各性能指标实时监控保障支持，保障投产顺利实施完成。\n\n\n中国人寿财险分批次切投产切换\n\n### 成效总结与未来展望\n\nTiDB 上线后完全满足各项业务性能指标，运行稳定，承载核心系统报价中心的全渠道业务量。TiDB 分布式数据库在中国人寿财险核心业务的成功应用，首先节省了成本，通过 X86 通用服务器代替 IBM 小型机，硬件投入成本降低了 75%；其次，用先进的分布式数据库替换集中式数据库，改造完成之后，OLTP 和 OLAP 性能较原来的 Oracle 数据库均有了明显上升，其中全量状态统计报表的处理时效提升 80 多倍，并具备了更强的数据汇聚和查询能力；最后，通过开放架构实现了安全可控，初步打造了中国人寿财险的自主创新体系，并不断演进，为后续异地双活改造奠定了坚实的技术基础。\n\n目前，国内金融机构的重要业务系统仍在使用国外成熟的商业数据库，而国产数据库从成熟度和稳定性上还需要进行持续的打磨。数据库技术的发展离不开新兴技术和业务场景的融合，因此不必局限于传统数据库的技术锁定。在产业变革加速的今天，中国数据库厂商应加大核心技术攻关力度，提升产品创新性和影响力，加强知识产权保护，探索变道超车的发展道路，逐步形成技术引领、生态完善、应用成功的创新发展局面。","date":"2023-05-24","author":"盛玉、王耀强","fillInMethod":"writeDirectly","customUrl":"user-practice-of-migrating-from-oracle-to-tidb","file":null,"relatedBlogs":[{"relatedBlog":{"body":"> 作者：熊浪，平安科技资深数据库架构师，在关系型和非关系型分布式数据库技术领域具有丰富的经验，担任平安集团去 O 分布式项目经理，负责分布式数据库选型和架构设计工作。 \n平安科技是平安集团旗下科技解决方案专家，践行“科技赋能金融、科技驱动生态”的企业使命，赋能集团金融服务、医疗健康、汽车服务、智慧城市生态圈建设，致力于成为国际领先的科技公司。\n\n\n## UbiSQL 简介\n\nUbiSQL 这个词对大家来说可能比较陌生，UbiSQL 是平安集团内部打造的分布式数据库产品，**代码基于 TiDB，完全兼容 TiBD 4.0 版本**。在 TiDB 的特性之上，UbiSQL 在稳定性、安全性和应用性上面都做了提升，打造出一个金融级且内核源码自主可控的分布式数据库，提供一栈式 HTAP 解决方案。\n\nUbiSQL 的规划是提供金融级别的安全能力，比如加密算法、给 TDE 的透明算法做增强，以及集群内部管理的加强。因为后续会增加到上千套集群，我们对于集群的管理做了加强，监控都做了合并。此外，UbiSQL 提供冷热数据的分离，支持把集群的冷数据都分离到 SATA 盘上，从而降低存储成本。\n\n## 从 Oracle 迁移到 UbiSQL 的过程\n\n接下来分享一个比较详细的 Oracle 迁移实践，这是我们在平安集团里面做了多年去 O 工作的总结，希望给到大家借鉴。集团的核心支付系统迁移的数据量大概在 8 T 左右，因为都是 rac 节点，为了避免节点之间的相互影响，就把它迁移到两个 UbiSQL 的实例上面。\n\n\n图：迁移前后集群的对比\n\nUbiSQL 的架构是通过 F5 负载均衡，打到三个数据中心的 TiDB 集群上面，F5 在三地机房都有部署，通过 DNS 方式访问相应 UbiSQL 的实例，在机房 IDC1、IDC2、IDC3 的集群之间通过 UbiSQL 自身的 Raft 协议实现强一致的数据同步，再通过 Drainer 工具进行异步复制，复制到远程的灾备集群。\n\n\n 图：迁移后的 UbiSQL 架构\n\n首先是迁移前对于现状的分析，主要包括三个方面：\n\n1. 数据库的负载以及迁移 SQL 的金融性、对象，存储过程的分析，确定是不是都可以迁移，这部分分析是 DBA 通过代码的扫描、报告得出的。\n\n1. 应用方面的分析，应用层需要看新的数据库是不是能适配，能不能兼容应用，了解应用层的结构还有相应的 JDBC 的版本。\n\n1. 关联系统的分析，Oracle 数据库有很多通过 OGG 或者 ETL、Kettle 或者调用第三方进行同步，接口调用情况也需要做相应的梳理。\n\n接下来基于分析的结果，做数据库的选型：\n\n1. 选择 RDBMS 还是选其他的开源数据库或是分布式数据库，我们需要根据应用层的要求来看，是做到双活，还是做到快速的扩容，亦或是分布式，然后根据要求来做相应数据库的选型。数据库的架构设计方案，是不是需要做多活，还是 NG 就足够了，也需要根据相应的业务需求做设计。\n\n1. 应用系统的拆分与解耦方案，确定应用是整个迁移，还是只迁移一部分，然后再启动应用的前期改造。\n\n1. 关联数据的同步方案设计，这部分就是 OGG 或者其他 ETL 数据的同步，分布式数据库以及开源的 PG，目前不支持 OGG 为源的，所以需要借助于第三方，比如 Kafka 之类的工具做相应的数据同步。\n\n然后是相应的迁移方案和回退方案设计，需要做相应的人力规划，还要看一下投入多少人力和成本。\n\n在这些准备都做完后，我们就开始搭建数据库、开发环境、测试环境、生产环境。准备好以后我们开始做数据的迁移，将前面梳理出来的一些表结构、对象之类的迁移到新的 UbiSQL 上，需要涉及到表结构的比对和数据的比对，这部分后面会详细介绍。\n\n应用功能的改造和测试是最重要、最核心的部分，开发人员需要对相应的功能、SQL 以及存储过程这方面进行改造，这是整个脱 O 的核心部分，如果存储过程较大，有几十万行之类的，需要评估人力的投入。我们今年脱 O 的项目存储过程大概有 2 万行左右，投入的人力约 10 个人，做了两个月左右，把整体约 100个 package，全部转换为 java 代码，这块的人力投入是挺大的。这部分做完之后就是应用层功能的全回归测试，校验开发转化的功能是否完全一致，和原来 Oracle 的逻辑是否完全一致。 接下来依次是做应用的性能压测、数据库的压测，然后是相应的迁移手册。\n\n接下来进入生产实施的阶段，按照实际的情况和方案步骤进行迁移，可能是“一次迁移，一次切换”，也可能是“多批次迁移、逐步切换”，因为有一些核心系统的迁移需要做保障措施，比如切过去不能有任何问题，可能切一些灰度数据过去。后续进入到生产数据库的并行运行阶段，我们对迁移后的数据库做相应监控和报告，紧接着下线老的 Oracle 数据库和回滚链路，进行项目的总结。\n\n## 流量复制与回放方案\n\n重点剖析一下流量复制和流量回放方面我们的实现方案。首先，为什么有流量复制和流量回放？流量回放是因为 Oracle 转化为 java 代码后，不知道这个逻辑对不对，完全通过测试人员做回归测试，可能测试不全，也有可能遗漏掉很重要的部分，我们想通过流量回放的方案保证生产业务流量完全在测试环境做相应的应用。\n\n流量复制是因为可以做压测，把生产的流量直接引入到迁移之后的环境，然后把流量做到翻倍，翻到两三倍做压测，做完之后还可以在后续核心系统去 O 上面做重复利用，从而节约了相应的成本和人力。\n\n\n图：流量复制\n\n流量复制借助的是 F5，或者 Ngnix 的流量，将所有客户端的流量通过 F5 访问到 Oracle 的环境，也可以在 F5 这一层将流量做镜像，将实时到 F5 的流量转发到应用层，应用层通过访问 UbiSQL，再通过挡板程序做到相应业务的访问。整个环节的核心在 F5，所有的流量都要经过 F5，如果没有走 F5 的流量则没有办法抓取到相应 SQL 的调用或者执行。挡板程序则是将所有环境按照生产环境进行调用，如果访问其他数据库的话，不需要做相应的访问，在这个地方会有一个挡板程序。这个挡板程序就是直接访问其他数据库，直接获取结果，不在其他数据库执行，不然会出现数据混乱。\n\n\n图：流量回放方案\n\n流量回放相对比较复杂，主要是开发同学实现的。主要的实现逻辑，就是通过外围系统的调用，通过 Traceid 访问相应的功能点，功能点上面会有一个 Agent，会去把相应调用的情况和参数，调用到哪个接口记录下来，存储到日志平台上。再通过日志平台里面的存储，将这部分存储下来，存储后调用后续支付系统的 UbiSQL，就可以做到数据的回放。\n\n因为是存储下来，想什么时候调用就可以什么时候去调，这个地方也有相应的挡板程序。做完之后我们可以做到 Oracle 和 UbiSQL 数据库的对比，因为之前的 SQL 都是一样的，而且是全量的，那么就可以把 Oracle 的数据通过恢复的方式恢复到某一个时间点，然后再把 UbiSQL 的数据通过流量回放的方式把那天的数据进行回放，这两边的数据基本就是一致的，再通过数据比对工具比对两边数据是否一致，这样来验证功能是不是完全一致。\n\n流量复制或回放方案通过搭建生产旁路验证环境，在旁路环境进行回退链路的生产级别验证。相比传统数据库回放，这个方案进行应用 + 数据库整体架构层面的验证，降低重大核心业务系统新技术上线投产风险。并行验证通过后，完成数据迁移比对后，可直接切换上线，减少了投产时间。\n\n## 数据对比与切换方案\n\n数据切换和数据比对的方案，先看数据比对的部分。迁移 Oracle 会有一个数据比对的过程，平安集团内部的有一个 Ludbgate 工具可以实现表结构的转化、全量数据的同步、增量数据的同步，还有全量数据的比对，增量数据的比对，它是整个迁移过程中数据对比的全链路工具。\n\n数据比对大致的逻辑是，当开始做数据同步的时候，会在日志里面记录相应的日志点，开始全量同步，全量同步完成之后就可以启动增量同步，因为记录了相应的启动时间点，后续就可以通过这个时间点做增量同步，在做增量的同时，会在中间的 MySQL 里面创建一个影子表，这个影子表的作用主要是记录进程启动后同步表的所有 dml 操作的主键值。\n\n数据同步完成之后就可以做相应的全量同步，这时所有增量及全量数据一直在不断变化，需要进行全量的比较，可以基于这个时间点比对两边的数据，不管是否静态都可以进行比较。全量比较主要通过把数据做一定的分区，首先对表记录做分区划分，用于多进程处理，每个进程根据对应分区的 rowid 去 Oracle 获取对应的记录并算出 md5 值，同时在 UbiSQL 这端获取到这个主键值，并通过查询整个行的数据，计算出 md5 值进行比对，如果比对结果不一致就会存到影子表里面。\n\n全量比对完成之后会启动增量对比，增量对比是每个小时启动一次，会将影子表里面的主键值拿到 Oracle 里面读取相应的记录，计算出 md5 值，再在 UbiSQL 里获取相应记录并计算出 md5 值，然后进行对比，如果一致，将此主键值从影子表中删除，如果不一致，下次在启动的时候会再次做相应对比，这样减少了比对的时间，做到最短的停机时间。\n\n\n图：数据对比和切换方案\n\n数据的切换方案通过 Oracle Ludbgate 访问到 UbiSQL 这一端，Oracle 这边有到其他 Oracle OGG 的链路，迁移是通过部分流量的切换，因为是资费系统，它需要保证迁移是完全的，没有任何问题，涉及到钱的问题，大家都觉得比较麻烦，所以我们按照切部分用户的方式去做。\n\n我们按照切少量流量，在应用端做相应的功能开关，去做到少量数据切到 UbiSQL 这边，然后做应用的验证，如果没有问题，流量会一点一点地切到 UbiSQL 这一端。另外它有相应到第三方的同步，会启用到 kafka，同步到其他的 Oracle 数据库。这个方案有一个短板，即不能保证回退的机制，因为写到 UbiSQL之后，UbiSQL 的新增数据没有办法写回到 Oracle。也就是说回退的时候这部分数据不再被需要。我们给 TiDB 社区提了相应的需求，是不是可以做到在 TiDB 里面进行用户写入的区分，这样我们就可以做到 Oracle 到 TiDB 双向的同步，就不会存在无法回退的问题。\n\n\n图：迁移后性能对比\n\n最后看下迁移后的性能对比，可以看到，因为都是资费系统，平均响应时间特别短，迁移到 UbiSQL 后进行了大致的统计，在执行 Count 语句的时候性能有提升，在其他的查询或插入性能方面有损耗，但是损耗不大，基本在 10% 以内，应用端是可以接受的。用这套方法我们迁移了统一支付、CF2 客户关系系统以及工作流系统，这些都是属于平安集团内部比较核心的业务系统。","author":"熊浪","category":4,"customUrl":"pingan-technology-from-oracle-to-ubisql","fillInMethod":"writeDirectly","id":342,"summary":"本篇文章将介绍平安科技从 Oracle 迁移到 UbiSQL （平安集团内部打造的分布式数据库产品，代码基于 TiDB，完全兼容 TiBD 4.0 版本） 的实践。","tags":["数据迁移"],"title":"平安科技从 Oracle 迁移到 UbiSQL 的实践"}},{"relatedBlog":{"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 监控就无从谈起了。”","author":"赵钰莹","category":4,"customUrl":"mysql-migrate-to-oracle-to-tidb","fillInMethod":"writeDirectly","id":489,"summary":"这样一家零售领域的老牌企业是如何一步步转向原生分布式数据库的？整体的架构变迁思路是怎样的？实践过后又是如何从成本视角评价 Oracle 和国产分布式数据库的......本文就上述问题逐一进行了探讨。","tags":["MySQL 架构演进"],"title":"从 MySQL 到 Oracle 再到全面 TiDB ，云盛海宏的数据库架构实践"}}]}}},
"staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}