分享好友

×
取消 复制
Aurora是全球化数据库吗?
2020-05-18 17:35:50

本文从可用性、性能、数据一致性三个角度对Aurora是否可以称为“全球化”数据库进行了分析。文章作者来自CockroachLabs,与Aurora存在商业竞争关系,客观性受到潜在影响,但整体上仍有阅读价值。

原文链接:
https://www.cockroachlabs.com/blog/just-how-global-is-amazon-aurora/



许多数据库宣称自己是“全球化的”,虽然没有官方定义,但我们认为这个概念值得拆解。如果某个产品承诺具有全球化能力,那它至少要满足三方面的要求:


全球化的可用性:利用节点在理分布上的多样性,保证数据可用。它应该始终处于运行状态,能够抵御设施故障和自然灾害。

全球化的性能:支持的策略能够将数据复制到访问最频繁(读和写)的地点,实现最优的全球延迟。

全球化的一致性:即使全球化分散部署,也能保证数据的一致性
 

CockroachDB从开始就考虑到这些需求,其他产品则是事后将类似能力塞进既有的技术框架中本文将带你回顾Amazon多个产品是如何实现全球化数据库,关注它们如何满足这三个要求。虽然他们可以提供其中些能力,但我们认为他们过于宽泛的使用了“全球化”这个词。

Amazon Aurora

Amazon Aurora 主要采用单区域(singleregion)部署模式。针对读负载较重的场景进行了优化,写操作被限制在单区域内的单主节点(single master node)上。因为全球的写操作都被汇聚到单个区域的一个写节点上,所以无论怎么部署都会遇到延迟的问题。

Aurora的标准实例是用单个写节点处理数据库的全部写操作;同时部署很多读节点,满足读吞吐能力的要求,读节点跨多个AZ(availability zone)但必须在一个区域内。Aurora使用自定义的分布式存储层替代了本地存储,这个存储层由跨多个AZ的SSD存储设备组成。

写数据时会产生6个副本,分布在三个AZ中,每个AZ存储两个副本。当6副本中的4个写入提交后,整个事务就会提交。同时,Aurora使用MySQL或PG作为执行引擎,这个新方法减少了读延迟,还提供了冗余。相对传统自带存储的巨石架构,它更具弹性

AmazonAurora Global Database

去年底,Amazon推出了Aurora全球化数据库,原有的单区域架构发生了改变,允许将读副本扩展到一个附加区域。扩大了读操作的覆盖范围,减少了到附加区域的地理距离延迟。两个区域间通过存储层的异步复制方式,保证数据的同步。

主实例包括写入节点,第二个实例完全由只读节点构成,所以只是为附加区域扩展了读操作能力。


故障发生时,Aurora 全球化数据库允许将附加区域的一个只读节点提升为主写入节点,这样在发生区域性事件时,能够提供业务连续性。但是,由于区域间是异步复制的,数据存在丢失的可能性,最多为1秒钟(RPO不为零),而读节点升级为主写节点耗时最多为一分钟(RTO为1分钟)。

Aurora Multi-Master

前俩种配置都依赖于数据的单点写入。这意味着单点故障引发故障转移风险还有一个重要的RTO问题。此外,单点显然限制了写扩展性,全球化应用系统执行操作时,必须容忍与写节点所在区域间的网络往返开销。对那些写节点区域以外的用户来说,这种地理位置造成的延迟将带来显著的性能影响。这是全球化性能的一个大问题

Amazon通过推出多主架构(Multi-Master)来解决这个问题,最近在四个区域上市,包括US East (N. Virginia), US East (Ohio), US West (Oregon), and EU(Ireland)。多主架构允许存在第二个写节点,但不允许副本读。这就是说最大写入吞吐量翻倍,而代价是最大读取的吞吐量显著降低。事实上,一个完整的读操作被割裂到两个节点,由应用程序中来决定到底查询哪个节点。这也意味着,无法向其他区域扩展读取能力。


AWS的文档介绍了多主产品的附加限制和适用场景。多主模式不支持可串行化隔离级别。虽然Aurora不断改进,但架构设计时间久远,当初没有考虑支持跨区域操作的可扩展性。

它的架构可能会将多主模式永远限制在单个区域,因为在每次读操作过程中要与所有写节点通讯,避免超时。这种一致性上的开销会随着写节点的数量同步增加。对多主架构来说,增加支持额外的区域将提升复杂度,同时引入了地理延迟带来性能的显著下降。

Amazon Aurora vs Global availability

全球化企业必然意味着多于两个区域。让我们总结一下,我们上面定义的全球化运营的三个要求来评估Aurora的产品。

首先也是最重要的,Aurora几乎不能全球化,它只允许向一个附加区域扩展读副本,而全球化则需要向其他区域开放。

还要注意,当启用附加区域后,向其复制数据会带来费用的增加。所以你必须小心选择部署在哪个区域,确定能够覆盖合理的延迟,并注意你的成本。

这个架构还有很多RPO/RTO的提升空间。当写节点失效时,Aurora在一分钟以内将读节点提升为写节点。RPO非零即意味着数据丢失。如果你的工作场景不能接受这一点,并不适合选择Aurora。

分钟级的RPO适于一些工作场景但不是所有。然而,当一个区域失效,RPO时间还会更长。如果整个区域失效(罕见但有可能),Aurora会很聪明的在第二区域启动一个新的写节点作为主节点。这个过程耗时几分钟,而你无法知道数据的状态。不在线的这段时间,你会丢失数据。一旦主节点上线,需要同步数据和清理问题。
 


Amazon Aurora vs Global Performance

谈到性能,有两个问题困扰着Aurora。第一点是上面说到的,依靠单个写入节点应对全球化的写入,第二点是它仅能在一个附加区域扩展读副本(多主模式还不支持)。这个架构面对物理性延迟时,性能会被压缩。

它在一个区域内性能很好,在一个可用区内能够处理故障转移。然而,单个写节点造成了写延迟问题。因为所有的写入都在写节点执行,客户端与该节点的距离决定了延迟时间。让我们考虑一种部署情况,你有一个实例在里士满。东海岸的用户可以低延迟读写,而位于美国另一端的洛杉矶,最少要70ms的延迟。



我们可以扩展到另一个区域,两个区域会带来更好的读取性能,但写入依然单线程的,会增加性能开销。刚才的场景还可以满足,但如果你走向全球化呢?如果写入实例在里士满,如何让悉尼用户有可接受的写延迟呢?最后,为了真正的全球化部署,你要尽可能让数据靠近使用它的地方。对于真正的分布式数据库,达到毫秒级的读写延迟是非常重要的。由于复杂的法律规定和多样化的合规性要求,用某些机制将数据固定在一个特定物理位置变得非常重要,Aurora并没有提供这种能力。

Amazon Aurora vs Global Consistency

它通过存储层解决数据一致性,也就是6副本中4副本落盘的仲裁机制(quorum)。写入节点上可以设置隔离级别,而标准的MySQL和PG执行引擎是写入节点的一部分。

默认情况下,它提供RC(PG)或RR(MySQL)隔离级别,这可能带来写偏序和脏读问题。进一步说,复制到第二节点 “延迟通常小于1秒”,所以即使在可串行化隔离级别依然存在脏读的风险。

如上所述,AWS已经添加了多主能力,但如果选择这种部署方式,你会丧失Aurora的其他好处,不仅不提供可串行化隔离级别,还会增加性能障碍。

Finally, Cost x Performance

除了扩展性、性能、一致性,全球化数据库的成本也是重要的。为了获得成本数字,我们执行了一些benchmark比对不同类型Aurora实例。

Benchmark是一个棘手的话题,但CockroachLabs是非常认真的。我们竭尽全力保证我们的方法是合理的,并且符合公共标准。我们参考了一些Benchmark,TPC-C是其中之一。

当然没有完美的Benchmark,我们希望至少方向正确。我们对这些问题的讨论持开放态度,强烈建议你制定自己的benchmark。

Aurora能够以很低配置来处理OLTP工作负载。我们在最小规模的机器上运行了一个类似TPC-C的工作负载,能够达到TPC-C最大吞吐量的85%。


CockroachDB不仅能够提供最低价格为OLTP工作负载,还提供了最高等级的一致性。通过之前的文章,可以更好的理解这些数字。简单来说,CockroachDB的成本包括三台机器和一个DBA的工资,后者负责监控维护集群。

为了这个比对,我们首先简单调整了TPC-C suite,以便使用与MySQL、PG都兼容的API,但没有修改他们默认的隔离级别。

有趣的是,我们设想的最经济方案是运行在最小规模机器上的Aurora PG兼容数据库。然而,我们发现账单主要来自I/O开销。我们相信Aurora PG的接口实现并没有像MySQL那样得到同等优化。事实上,Aurora PG运行TPC-C的成本有90%与I/O相关。

所以,在默认隔离级别下,虽然AuroraMySQL需要更大规模的机器,成本却比PG低很多。前面的案例放松了对Aurora隔离级别的要求。所以,我们又在可串行化级别上运行了完整的TPC-C 1k,这也是CockroachDB默认的隔离级别。有人认为更高的隔离级别无疑会破坏性能。然而,对于Aurora来说,使用更多的处理器可以解决这个问题。但这样做的缺点是显著增加了I/O数量。看上去问题根源在Aurora MySQL的死锁机制,它不断地引发事务重启,导致返回磁盘的动作大幅增加。

归根到底,我们不是Aurora专家,所以上面的内容应该谨慎使用。然而,它确实显现出一些关键问题,我们想提供一个切实可行的比较,不仅是架构层面还包括成本。

Two Essential Constraints for a Global Database

真正的全球化数据库是全球化的可用性、性能、一致性,不应该纠结于6路复制。它应该提供可串行化的隔离级别,低延迟,零RPO。真正的全球化数据库要对抗的不是架构约束,而是两个事实。

任何东西都可能失效,需要有所准备。

光速是受限的。

如果你购买的是一个“全球化”数据库,它牺牲了性能、可用性或一致性不是因为这两点而有其他原因,那就要重新评估它是否真的像宣称的那样是“全球化”的。

CockroachDB从开始就被设定为全球化的数据库,我们对这两个挑战有深入的思考和敏锐的观察。每个节点都能作为整个数据库的网关,提供读写访问,同时保证任何规模下的性能可靠与可串行化隔离。



分享好友

分享这个小栈给你的朋友们,一起进步吧。

盗火的普罗米修斯
创建时间:2020-05-18 16:41:22
立足金融场景,聚焦于数据技术的普及和引导,以中立者身份对各项技术进行分析和横向比较。这里所指的数据技术包括数据分析和联机事务处理两个大的方向,涉及大数据、分布式等领域。
展开
订阅须知

• 所有用户可根据关注领域订阅专区或所有专区

• 付费订阅:虚拟交易,一经交易不退款;若特殊情况,可3日内客服咨询

• 专区发布评论属默认订阅所评论专区(除付费小栈外)

栈主、嘉宾

查看更多
  • 金融数士
    栈主

小栈成员

查看更多
  • ☀️
  • chenglinjava0501
戳我,来吐槽~