新旧时代的更迭
「尽享云端数据库之美。」
——胖头陀
可加微信 1126699 联系作者
◆ ◆ ◆
撰文 | 康翔 编辑 | 阿由
毫不夸张地说，我们今天习以为常的现代商业和数字生活，其技术基础深深植根于数据库管理系统，尽管很多人对此可能毫无感知。
作为计算机科学最重要的分支之一，数据库技术完全改变了我们与数据的交互模式，使得高效地管理海量数据成为可能，人类能够藉此进一步挖掘数据，从而释放出其价值。
相信我！无论你此刻正在生产线上查看相关信息，或是在手机上浏览和追踪网购的物流信息，抑或在亚马逊上查看琳琅满目的商品信息，本质上你其实是徜徉和穿行在数据库中……
数据库与经济社会已经无法割裂开来，并且伴随着人类文明的进程而不断演进。
新旧时代的更迭
然而，越来越多的企业逐渐意识和感受到，传统的RDBMS（关系数据库管理系统）已经步履蹒跚，难以满足企业的实际需求。
原因只有一个：云计算。
毋庸置疑，云计算为现代企业的运营模式带来了巨大改变，企业可以根据流量和业务增长，随时使用强劲、稳健和高可扩展的云架构，完全不必耗费精力于既往庞大繁杂的IT基础设施上。
云计算带来的变革和颠覆，用“革命性”来形容亦不为过。
不过我们仍是注意到，尽管上云已经成为当前的主流，无数的企业和机构纷纷将各种业务迁移到公有云环境，但是它们似乎是刻意地避开了数据库，仍是固执地将之保留在本地系统中。
到底是业务的沦丧还是数据的至上（请允许我略微放松下），乃至于要被区别对待？这一切究竟是为什么？
数据库承载着企业最具价值的资产之一——数据，可谓“牵一发而动全身”，出于某种惯性或是惰性，加之数据库的迁移难度实在太大，企业往往被供应商告诫：不要异动。
于是这就造成了一番奇怪的光景：企业的业务运行在公有云上，但是数据库系统仍盘踞在本地。不难想象，当“云上”业务撒开了欢往前飞奔时，就会不断地遭受到“云下”数据库的桎梏。
基于此，云原生数据库应运而生，Amazon Aurora关系数据库正是其中的佼佼者，被很多方面认为是当前最佳的数据库选择。
凭借着仅仅相当于高端商业数据库十分之一的成本，以及与之匹敌乃至胜出的性能和可用性，Aurora已经成为AWS有史以来发展速度最快的服务项目。
目前，Aurora关系数据库方案已经赢得数万客户的青睐——其具体数量已经达到去年同期的约2.5倍之多，足以佐证该服务在市场中所受欢迎的程度。
Aurora的客户名单中包括了大量的知名企业与机构，新增的客户包括了ADP、Autodesk、TIBCO、亚利桑那州立大学等，原有的客户则包括Verizon、通用电气、道琼斯、Netflix、爱彼迎、纳斯达克等，广泛分布于金融、电信、工业、旅游、科技等领域。
“夫风生于地，起于青萍之末。”
虽然与目前仍被束缚在企业数据中心中的数百万套数据库相比，AWS已有的数万套数据库的迁移显得体量不大，但是越来越多用户对云数据库理念的认同，实际上亦代表着旧时代的终结与新时代的开始。
设计理念与技术实践
设计者认为，当前数据库的最大瓶颈不再是计算或者存储资源，而在于网络。
基于这样的设计理念，Aurora提供了一种存储计算分离的架构，将日志处理下推到分布式存储层，存储节点与数据库实例（计算节点）松耦合，并包含部分计算功能。
作为AWS云平台上兼容MySQL的企业级关系数据库引擎，Aurora提供一种在云中建立、运行和扩展的关系数据库服务，它完美契合了企业级数据库系统对高可用性、性能和扩展性、云服务托管的需求，可以说是应“云”而生。
其架构并不是类似于Google Spanner的NewSQL数据库，而是一种基于MySQL实现的数据库，复用了很多MySQL的功能，开发周期相对较短，也更容易出成果，用户可以完美地从MySQL切换到Aurora，保证了数据业务的连续性。
目前的Aurora可跨3个可用区的6路复制，存储从10GB开始按用量增长，最大支持64TB。支持最多15 Replicas，在30秒内便可完成故障转移，同时具备快速的crash recovery能力。
故障恢复是一个比较耗时的操作，并且与检查点操作频率强相关。通过提高检查点频率，可以减少故障恢复时间，但是这会直接影响到系统处理前台的请求吞吐，因此需要在检查点频率和故障恢复时间做一个权衡，而得益于出色的设计理念和架构，Aurora不需要做这种权衡。
在Aurora中，写副本实例和至多15个读副本实例共享一套分布式存储服务，因此增加读副本实例并不会消耗更多的磁盘IO写资源和磁盘空间，这也是Aurora的一大优势，即零存储成本增加新的读副本。
相对于单个实例的本地存储，Aurora的存储空间利用率大大提升，并且非常方便扩展；另一方面，所有数据库引擎共用一份存储，零存储成本增加数据库引擎，能大幅降低成本。
Aurora的数据库实例与存储服务层相互独立，存储服务层向上为数据库实例提供统一的数据视图，数据库实例从存储服务层获取数据与从本地读取数据一样。
值得一提的是，在性能方面，Aurora比RDS MySQL 5.6和5.7版本快5倍。
除此之外，Aurora可以和其他的AWS云平台服务无缝集成，充分利用了AWS的众多资源，降低了管理人员的工作负载。在大部分情况下，管理人员只需要完成查询优化的工作即可。
炮制而来的“好故事”
亚马逊是美国最大的网络电子商务公司，同时也是全球领先的科技企业，因此也秉持着“Eating your own dog food”的开发理念。既然Amazon Aurora有千般好处，那么亚马逊总该自己先尝尝味道吧？
平心而论，对于亚马逊来说这是一次极大的考验。尽管公司对新生的Amazon Aurora有着充足的信心，但是毕竟亚马逊已经使用甲骨文数据库长达20年之久，有着大量的数据积淀。
尤为重要的是，迁移关系到千万用户和供应商的数据及隐私，以及这家世界上最大的交易平台的稳定运行。
不过考虑到业务的长期需求，亚马逊终于将数据库迁移提上议事日程，借着前不久的Prime Day开始迅速行动起来，很快就在配送中心实现了92%的数据库从甲骨文迁移到Aurora。
孰料一个软件堆栈引起的保存点问题，就被外界别有用心地解读成“亚马逊使用Aurora替换Oracle，导致Prime Day促销日瘫痪”。很抱歉，这里用得是云头条翻译而来的中文标题，本文的始作俑者是国外科技媒体CNBC的某位编辑。
CNBC显然是得到了一份亚马逊内部的CoE（错误更正）文档，以为能够挖掘出一篇轰动业界的深度报道，于是这位编辑找到了美国卡耐基梅隆大学的数据库助理教授Andy Pavlo。
教授好心地为这位编辑科普了一番数据库常识与术语，并明确告诉对方：“保存点问题不是什么大问题，它只发生在一个配送中心，而不是引起网站问题的原因。”
不过这位编辑觉得，问题没有那么简单。他固执地认为，亚马逊贸然进行数据库迁移的行为，才是问题的初衷，这也表明Aurora难以担负起甲骨文数据库原先承担的工作。
于是在一番操作之后，上面那篇近乎标题党的文章粉墨登场，CNBC和这位编辑也得以“扬名”天下。尽管教授在Twitter上一再申明文中的谬误，但是对方选择了回避和无视。
对此，Amazon CTO Werner Vogels认为，“这是一篇愚蠢和充满误导的文章。”显然，在事实和“好故事”之间，该报道选择了后者。
据他介绍，实际上这个问题只出现在一个配送中心（亚马逊在全球有超过185个配送中心），仅仅导致了1%的包裹递送出现了短暂的延迟，客户甚至不会感受到。
该问题很快就被诊断出来，技术人员只需简单地去掉不必要的、疏忽于零售应用中的保存点，问题就被彻底解决了，与Aurora没有任何关系。
从2015年出人意料地杀入数据库魔力象限的领导者象限之后，AWS就经常遭受到不同方面的质疑甚至攻讦，本次的“好故事”无疑是AWS数据库发展历程中又一次生动的注解。
“经得住多少诋毁，就担得起多少赞美。”Amazon Aurora，当之无愧！
联系客服
