OceanBase迁移服务:向分布式架构升级的直接路径

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,高可用系列 2核4GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介: 2019年1月4日,OceanBase迁移服务解决方案在ATEC城市峰会中正式发布。蚂蚁金服资深技术专家师文汇和技术专家韩谷悦共同分享了OceanBase迁移服务的重要特性和业务实践。

2019年1月4日,OceanBase迁移服务解决方案在ATEC城市峰会中正式发布。蚂蚁金服资深技术专家师文汇和技术专家韩谷悦共同分享了OceanBase迁移服务的重要特性和业务实践。

蚂蚁数据库架构的三代升级史

在过去的十多年时间里,蚂蚁在整个基础数据库架构上一共经历了三代升级。第一代数据架构是构建在IOE的基础之上——IBM的小型机、Oracle的商业数据库,还有EMC的共享存储。基于第一代IOE架构的运维成本是非常高的,同时稳定性的挑战也是非常大的。随着业务的快速发展,这套架构已经完全没有办法适应业务发展的增速。

_

随之诞生的是第二代架构,第二代架构的主体是OE——也就是Oracle和EMC,加上蚂蚁自身的分布式中间件,解决了业务的水平和垂直的弹性能力。这一代架构其实伴随着蚂蚁走了很多年。

随着4G、5G时代的到来和金融的普及化,人们的生活越来越离不开移动支付,业务井喷式的发展给底层的数据库提出了更高的要求。这些要求包括更高的稳定性,快速恢复能力和极致的弹性能力等。

于是最终演进到了我们如今的第三代架构。第三代架构是由OceanBase为代表的金融级云数据库和分布式中间件所构成。

数据库架构升级的挑战

伴随着整个蚂蚁的发展,整个数据库的架构也仅仅演进了三代。这其中一个很重要的原因就是对于任何企业而言,整个数据库的架构升级都是一件非常有挑战的事情。

蚂蚁金服资深技术专家师文汇说道,“用一个我们内部经常说的比喻,就是数据库的架构升级就好像是在给一个高速运行的飞机更换引擎。”

vcg_VCG41155150766_RF

更换引擎的目的是为了拥有更好的动力,做更多技术上的创新。但是横亘在眼前的问题是,如何才能做到稳妥创新,保证驾驶中的飞机平稳顺利的运行,这其实是有非常大的挑战。

_2019_01_07_10_34_28

在过去三代架构的演进中我们可以看到,本质上每一代架构的迭代基本上都是以两到三年为周期,这其中会有非常高的人力投入和成本开销。

第二个挑战就是从传统的商业数据库迁移到OceanBase数据库之上,我们如何保证迁移过程中以及迁移以后的稳定性。

另外一个非常大的挑战就是数据质量,在金融企业里,数据承载的不仅只是钱,更承载了数以亿计用户的信任。所以数据一条不能丢,一条不能错,这是我们做数据库的底线。

当然,包括兼容性问题和性能风险也给数据库的架构升级带来重重挑战。

OceanBase迁移服务:向分布式架构升级的直接路径

基于上述问题和挑战,同时经过蚂蚁十年数据库架构升级的先进经验,蚂蚁金服为客户打造了这款一站式数据迁移解决方案——OceanBase迁移服务(OceanBase Migration Service,简称OMS)。

OMS的发展演进

_2019_01_07_2_00_35

OMS的演进是以业务为驱动,并且与OceanBase的架构升级和不断发展密不可分。

早在2014-2015年期间,蚂蚁主站上的一些核心业务,包括大家熟知的交易业务,支付业务和会员业务等,需要从Oracle迁移到OceanBase上。当时的OMS还是以一个工具类、模块化的形态支撑着这些项目。

所以在2015年我们开始对OMS的方案进行全面的调研,力求沉淀出通用的系统化的解决方案。

在2016年,OMS已经有了平台化的架构,引入了大规模编排的思想,将整个迁移特别是切换过程中繁琐易错的环节全部集成到平台。这一时期,OceanBase也完成了从0.5版本到1.0版本的架构升级,这一年OMS还支撑了网商银行、印度PayTM以及主站的核心业务升级到OceanBase 1.0版本。

到了2018年的时候,无论在基础功能层面还是任务编排层面,OMS都已经被打磨得日趋完善。今年OMS已经支持了蚂蚁森林,蚂蚁商户平台以及众多大量核心及非核心的业务从MySQL迁移到OceanBase之上。与此同时,在外部业务包括很多已经上线OceanBase的商业银行,也已经验证了使用OMS一键迁移到OceanBase的能力。

OMS的方案优势

_

OceanBase迁移服务其实主要解决了五个重要的问题。

负载回放验证:其中第一个核心的问题就是负载回放验证,通过采集源端数据库的SQL流量,在目标库OceanBase上回放,可以验证其在OceanBase上的功能是否兼容、性能是否出现问题等。同时基于蚂蚁DBA十多年的经验沉淀,OMS会为客户提供性能等方面的调优建议。

秒级数据校验:第二点就是数据校验,OMS有三层数据校验,可以做到秒级的延迟。举一个例子,比如说我们想把传统商业数据库替换成OceanBase,如果在迁移过程中任何一条数据出现了错误,在一秒钟内就可以快速发现。校验的延迟可以完全保证在一秒以内,根据蚂蚁线上的经验,大概在100-200毫秒之间。

分钟级即时回滚:第三点也是最重要的一点,就是OMS有随时回滚的能力,而且回滚是无损的。这也是我们前面所强调的稳妥创新的基石。

多种数据库类型支持:目前OMS支持源端数据库类型有Oracle、MySQL、OceanBase等等,支持全量迁移和增量数据同步。

一键完成迁移:整个数据迁移链路和回滚机制的搭建基本上都是通过一键操作完成,使用简便。

OMS的技术架构

OMS的核心方案其实非常简单,我们把OceanBase变成Oracle/MySQL的一个备库。

_

传统的商业数据库一般都是有主库和备库的:主库承担写的流量,如果主库出现问题,我们会把数据切到备库,然后通过OMS提供的一整套虚拟主备库的解决方案完成切换。比如原来Oracle有一个主库一个备库,然后OceanBase其实变成了一个虚拟的备库。

整个数据库架构的升级也会变得异常简单,简单到只是做了一个主备切换。回滚也会变得非常简单,其实也是做了一次主备切换。

_2019_01_07_1_30_24

从OMS的整体架构来看,其实一个非常关键的点就是,我们在传统的商业数据库和OceanBase之间建立了一套虚拟的主备链路,整个OMS里用到的所有组件,其实都是在蚂蚁和阿里有很多年技术沉淀的,也都是基于真实场景所产生的。

OMS的迁移流程

_2019_01_07_1_42_10

OceanBase迁移服务的整体迁移流程其实只有七步。

评估:首先第一步是通过负载回放工具做兼容性分析;

PoC:接下来OceanBase云平台可以帮助客户部署一套PoC集群;

预迁移:然后OMS把线上的Oracle的数据预迁移到一个测试库里;

验证:在这个测试库里用负载回放工具去回放这些SQL,然后找到SQL里不兼容,性能或者数据质量不满足预期的部分,并提供优化建议;

正式迁移:前四步做完了以后,业务需要调整或者需要优化的SQL已经完成优化,然后就可以正式迁移了。首先把原有的全量数据迁过来,然后再把增量变化的那部分数据实时同步过来;

校验:等到所有的数据准备好以后,然后我们继续完成三级校验;

切换和回滚:等到所有的校验都完成以后,可以一键完成切换和回滚功能。

通过这七步就可以轻松完成从传统商业数据库到分布式数据库的完整迁移。

蚂蚁商户平台基于OMS的业务实践

蚂蚁商户平台承载着商户档案数据信息,订购关系、签约信息的数据和相应的服务能力。其中一部分业务使用的是MySQL数据库,还有一部分核心业务使用的是Oracle数据库。

随着商户的快速增长以及业务场景的不断丰富,商户平台数据增长迅速,数据规模相当庞大。尤其是MySQL的单表瓶颈日益明显,DDL变更、DML更新的性能与风险已经无法承担。

蚂蚁金服技术专家韩谷悦介绍道,“OceanBase能够支持数据的无限扩展,满足商户业务的容量与性能需求。那么如果我们换一种数据库底盘,其实所要面对的性能、稳定性和数据质量的风险同样不可避免。”

_

从蚂蚁商户平台的业务实践来看,使用OMS迁移与传统迁移进行对比,我们可以看到:

  • 业务评估和改造

过去通常一个业务少则花费1-2个月的时间去做改造和适配;那么基于OMS自动化的SQL兼容性评估和负载回放的能力,蚂蚁商务平台业务的改造大概只用了一个星期的时间。

  • 数据迁移和校验

客观来讲,迁移的总时长主要取决于业务数据模型,数据量和网络环境。在提高迁移效率方面,OMS目前增量迁移的延迟仅为毫秒级,跨城情况下最长只需要3秒。并且针对校验出的数据差异提供补齐的SQL和订正方案,使得迁移和校验的整体效率有了大幅度的提升。

  • 业务切换

其实在切换之前,往往需要制定严密的切流方案和Failover方案,整个切换过程中需要检查与校验的细节非常繁琐,任何一步疏忽都有可能造成数据不一致的问题。那么OMS通过引入大规模编排的思想,把所有繁琐复杂的环节通通落到平台当中。所以从原来业务切换需要用时1-2周时间, 使用OMS后蚂蚁商户平台业务无论是切读还是切写的过程中都只用了几分钟的时间。

  • 业务回滚

在过去,迁移之后的业务回滚要担负重大的决策风险,OMS使得业务回滚就像一次主备切换,可以瞬间完成并且不丢数据,所以让业务回滚不再成为难题。商户业务整体迁移的过程中也发生过业务抖动,使用OMS回滚的时候从登陆系统到完成回滚也只用了几分钟的时间。

所以全程下来蚂蚁商户平台这个业务的迁移时间大概在三个多星期的时间完成,那么无论从人力成本还是时间成本上,OMS都极大地提升了数据库的整体迁移效率。

最后,韩谷悦为大家展示了OMS一键迁移的demo演示。

_2019_01_09_11_58_24

当前, 越来越多的企业已经认识到分布式架构在实现业务灵活扩展以及敏捷开发等方面的巨大价值。OceanBase不断通过产品端的革新,为传统企业输送“互联网基因”,帮助更多客户向分布式架构转型。

同时OceanBase也在不断提高服务客户的深度和广度。深度意味着在同样的业务场景下,随着业务的发展和体量的壮大,帮助更多企业承担起业务所带来的极致压力。广度则针对的是随着新型技术形态和业务场景的出现,帮助更多企业快速响应,通过技术创新而适应变化所带来的新的市场契机。

OceanBase致力于将蚂蚁自身业务多年沉淀下来的最浓缩,最经典和最普世的方法论输出给广大的企业客户,同时做到深度和广度并存,真正帮助客户实现稳妥创新。

OMS 技术交流群

— 想了解更多OMS的产品特性和功能?

— 想与蚂蚁金服OceanBase的一线技术专家深入交流?

扫描下方二维码联系小编,快速加入OMS技术交流群!

_

相关文章
|
4月前
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
22天前
|
缓存 Cloud Native 中间件
《聊聊分布式》从单体到分布式:电商系统架构演进之路
本文系统阐述了电商平台从单体到分布式架构的演进历程,剖析了单体架构的局限性与分布式架构的优势,结合淘宝、京东等真实案例,深入探讨了服务拆分、数据库分片、中间件体系等关键技术实践,并总结了渐进式迁移策略与核心经验,为大型应用架构升级提供了全面参考。
|
6月前
|
存储 SQL 数据库
【赵渝强老师】OceanBase的部署架构
OceanBase数据库支持两种部署架构:无共享(Shared-Nothing,SN)模式和共享存储(Shared-Storage,SS)模式。SN模式下,各节点对等,具备高扩展性、可用性和性能,运行于普通PC服务器集群;SS模式采用存算分离架构,租户数据存储在共享对象存储上,本地缓存热点数据。两种模式均支持高可用与多副本一致性,适用于不同业务场景。
401 1
|
1月前
|
存储 NoSQL 前端开发
【赵渝强老师】MongoDB的分布式存储架构
MongoDB分片通过将数据分布到多台服务器,实现海量数据的高效存储与读写。其架构包含路由、配置服务器和分片服务器,支持水平扩展,结合复制集保障高可用性,适用于大规模生产环境。
201 1
|
5月前
|
监控 算法 关系型数据库
分布式事务难题终结:Seata+DRDS全局事务一致性架构设计
在分布式系统中,CAP定理限制了可用性、一致性与分区容错的三者兼得,尤其在网络分区时需做出取舍。为应对这一挑战,最终一致性方案成为常见选择。以电商订单系统为例,微服务化后,原本的本地事务演变为跨数据库的分布式事务,暴露出全局锁失效、事务边界模糊及协议差异等问题。本文深入探讨了基于 Seata 与 DRDS 的分布式事务解决方案,涵盖 AT 模式实践、分片策略优化、典型问题处理、性能调优及高级特性实现,结合实际业务场景提供可落地的技术路径与架构设计原则。通过压测验证,该方案在事务延迟、TPS 及失败率等方面均取得显著优化效果。
307 61
|
6月前
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
1953 57
|
10月前
|
存储 缓存 NoSQL
分布式系统架构8:分布式缓存
本文介绍了分布式缓存的理论知识及Redis集群的应用,探讨了AP与CP的区别,Redis作为AP系统具备高性能和高可用性但不保证强一致性。文章还讲解了透明多级缓存(TMC)的概念及其优缺点,并详细分析了memcached和Redis的分布式实现方案。此外,针对缓存穿透、击穿、雪崩和污染等常见问题提供了应对策略,强调了Cache Aside模式在解决数据一致性方面的作用。最后指出,面试中关于缓存的问题多围绕Redis展开,建议深入学习相关知识点。
658 8
|
6月前
|
消息中间件 缓存 算法
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
311 0
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
|
8月前
|
并行计算 PyTorch 算法框架/工具
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
本文探讨了如何通过技术手段混合使用AMD与NVIDIA GPU集群以支持PyTorch分布式训练。面对CUDA与ROCm框架互操作性不足的问题,文章提出利用UCC和UCX等统一通信框架实现高效数据传输,并在异构Kubernetes集群中部署任务。通过解决轻度与强度异构环境下的挑战,如计算能力不平衡、内存容量差异及通信性能优化,文章展示了如何无需重构代码即可充分利用异构硬件资源。尽管存在RDMA验证不足、通信性能次优等局限性,但该方案为最大化GPU资源利用率、降低供应商锁定提供了可行路径。源代码已公开,供读者参考实践。
611 3
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
|
8月前
|
人工智能 运维 监控
领先AI企业经验谈:探究AI分布式推理网络架构实践
当前,AI行业正处于快速发展的关键时期。继DeepSeek大放异彩之后,又一款备受瞩目的AI智能体产品Manus横空出世。Manus具备独立思考、规划和执行复杂任务的能力,其多智能体架构能够自主调用工具。在GAIA基准测试中,Manus的性能超越了OpenAI同层次的大模型,展现出卓越的技术实力。

热门文章

最新文章

推荐镜像

更多