登录 / 注册
IT168技术开发频道
IT168首页 > 技术开发 > 技术开发评论 > 正文

案例研究:为什么要从MySQL迁移到Aurora?

2018-11-16 12:10    it168网站 原创  作者: 老鱼 编辑: 覃里

  【IT168 评论】 今年8月9日,在京召开的亚马逊AWS中国技术峰会上,亚马逊AWS全球副总裁、大中华区执行董事容永康宣布,AWS 历史上用户数量增速最快的云服务Amazon Aurora登陆中国,并在由西云数据运营的AWS中国(宁夏)区域率先提供服务。

  

  与此同时,AWS在北京区域和宁夏区域一并推出了数据库迁移服务,在帮助客户从传统数据库快速迁移到Aurora平台的同时,快速抢占市场。

  众所周知,数据库服务是粘性最强的云服务之一,一旦客户被吸附,转投其他云的可能性就微乎其微。

  如今3个月过去了,因为没有官方数据,所以,这3个月到底有多少中国企业选择并迁移到Aurora之上不得而知。不过近期,AWS官方博客发布了3篇与Aurora相关的文章,其中有2篇是国外用户迁移到Aurora之上的案例, 1篇是帮助用户如何从Oracle数据库迁移到Aurora PostgreSQL的教程。

  

  通过对这2个案例研究,我们或许可以发现Aurora到底凭什么成为AWS增长最快的云服务的一丝端倪。

  先来看看这2家国外企业:

  

  InfoScout 创建于2011年,总部位于旧金山,通过一共一系列的APP,帮助用户拍照上传购物小票,换取各种奖励。而 InfoScout则将这些购物信息汇总分析形成报告,提供给零售商、代理商、大众消费品企业。

  

  Autodesk国内的朋友应该不陌生,设计圈内大名鼎鼎的AutoCAD,就是这家公司的产品。知名的二维和三维设计、工程与娱乐软件公司,创立于 1982 年。

  选择Aurora的原因:瓶颈

  InfoScout目前获取的信息占美国购物交易的 1/500,每天传输 300000 张收据图像。随着业务增长,InfoScout开始遇到数据库性能问题。高流量期间有两个重大问题爆发出来。

  首先,是查询执行时间的总体性能不佳。在高峰负载下,高并发请求,导致读取速度下降,页面超时,作业失败。

  其次是存储问题。Amazon RDS for MySQL 当时的最大存储容量为 6 TB(现在最高支持 16 TB),而当时,InfoScout的数据库已经达到了 5 TB。

  Autodesk的瓶颈得先从Autodesk Access Control Management (ACM)说起。

  

  尽管ACM 的架构允许 Autodesk 扩展和平衡应用程序的负载,但瓶颈很快就转移到数据库。比如,应用程序连接单个 RDS MySQL 数据库实例,限制了可用的扩展选项。一个方法是增加数据库实例的大小。这种方法仍然受到可以预置的数据库实例的最大型号制约。ACM 很快就超出了最大可用实例的容量限制。

  下一个选项是增加 RDS Read Replica 实例的数量以卸载主实例的读取流量,从而横向扩展数据库容量。Autodesk 希望复制延迟能低于一秒,从而为所有 ACM 用户提供稳定的体验。与只读副本有关的复制延迟取决于主实例和只读副本实例的工作负载压力。

  除非重新设计 ACM 的架构,将数据跨多个 MySQL 数据库进行分拆,Autodesk 不得不对应用程序进行控制,限制指向数据库的负载以减少复制延迟。但这种方法是不可持续的。

  迁移到 Aurora 后

  迁移到 Aurora 后,InfoScout发现,收据引擎状态计算机中的一个关键步骤的时间减少了 10 倍。此任务负责复制图像并验证最近提交的收据。

  下图显示了收据管道中的一个关键异步作业的运行时间。可以看到执行时间下降了 10 倍,从 4 秒缩短至 400 毫秒。

  

  除 AWS 监控工具外,InfoScout还使用 New Relic 等生产级的服务来进行深度性能监控。通过提取了这些报告,可以看到响应时间缩短了 3 倍!

  在InfoScout使用MySQL 时,完成手机客户端向后端发出的标准网络调用需要 600 毫秒,部署 Aurora 后,这一延迟已经缩短至 200 毫秒以下。

  下图为迁移之前和之后的延迟,能看到性能明显提升。

  

  迁移到 Aurora 后的 ACM 应用程序架构:

  

  在此架构中,Aurora 集群包含一个写实例和最高四个 Aurora 副本。Aurora Auto Scaling 将会启用以根据 CPU 利用率自动调整 Aurora 副本的数量。

  下图显示了迁移之前和之后的 CPU 利用率。Autodesk 的 CPU 利用率下降了 10 倍,从使用 MySQL 时高达 100% 的峰值水平降至使用Aurora后不到 10%的水平。

  

  MySQL

  

  Aurora

  下图显示了迁移之前和之后的应用程序响应时间。 Autodesk 的响应时间缩短了 2 倍。

  

  MySQL

  

  Aurora

  迁移到 Aurora 后,Autodesk 发现数据库的性能超出预期,应用程序的扩展性提高了 20 倍,应用程序的响应时间缩短了 2 倍,并且 Aurora 支持的数据库连接数量增加了 7 倍。

  写在最后

  通过这两个案例,我们可以总结出Aurora的四个亮点,也是对在用MySQL企业的四大诱惑,而这或许就是为什么Aurora能成为AWS用户增长最快的云服务之一的原因。

  1、 完全兼容MySQL,意味着即插即用,即用户在无需修改程序的前提下,可以直接迁移。

  2、 性能增强,性能是MySQL的五倍,意味短期内无需对数据库进行分区或自建集群,用户拥有了更大的空间来满足未来业务增长的需要。

  3、 自动存储扩展,Aurora采用分布式、容错型、自我修复式的存储系统,可自动最高扩展至 64 TB,无需手动扩展数据库的存储容量。

  4、 低复制延迟以实现读取扩展,最高可配置 15 个低延迟的 Aurora 副本,提高了可用性并支持读取扩展,典型的复制延迟在100毫秒以下。

  当然,这2个案例只是针对MySQL的迁入,但这并不意味着Aurora只能替代MySQL,另外一篇Oracle迁移到Aurora PostgreSQL的教程很说明问题,Aurora的目标还有Oracle数据库。

关键字: 数据库 , Aurora , 亚马逊
  • IT168企业级IT168企业级
  • IT168文库IT168文库

扫一扫关注

行车视线文章推荐

首页 评论 返回顶部