Amazon Aurora：云时代的数据库 ( 下）

接《Amazon Aurora：云时代的数据库 ( 中）》

6. 性能测试结果

在这一节中，我们分享自2015年7月Aurora GA之后在生产环境运营的经验。首先介绍标准的工业基准测试的结果，接着是一些来自客户的性能测试结果。

6.1 标准基准测试的结果

我们使用标准的基准测试工具SysBench和TPC-C类似测试工具来进行测试，对比了Aurora和MySQL在不同场景下的性能表现。我们在带有20K IOPS EBS的EC2实例上进行测试，除非特殊说明，这些实例的规格为32 vCPU,244G内存，Intel Xeon E5-2670 v2（Ivy bridge）处理器。实例上的buffer cache设为170G。

6.1.1 随实例规格扩展

在这个测试中，我们发现Aurora的吞吐量可以随着实例规格线性增长，在最高实例规格上吞吐量是MySQL5.6或者MySQL5.7的5倍。而Aurora目前是基于MySQL5.6的代码库的。我们在EC2 r3系列实例（large，xlarge，2xlarge，4xlarge，8xlarge）上运行1GB数据量大小（250张表）的只读或者只写的基准测试。R3系列的每个实例的vCPU和内存数量是下一个比它大的规格的一半。

[1501475360000_5911_1501475360133.png]

[1501475369668_406_1501475369789.png]

测试结果度量的是每秒钟读写的语句数量，如图6和图7所示。Aurora的性能随着实例规格的提升而翻倍，在最大的r3.8xlarge的实例规格上可以获得121K writes/sec和600K reads/sec，是MySQL5.7的20K writes/sec和 125K reads/sec的五倍。

6.1.2 不同数据集大小下的吞吐量

在这个测试中，我们发现Aurora的吞吐量远大于MySQL，即使使用更大的数据集且包括cache之外的数据。表2展示使用SysBench的纯写入测试，使用100GB大小数据集Aurora可以比MySQL快67倍。即使是使用1TB包含Cache外数据的测试集，Aurora也比MySQL快34倍。

[1501475385455_3084_1501475385573.png]

6.1.3 随用户连接数扩展

在这个测试中，我们发现Aurora的吞吐量可以随着客户端的连接数量而扩展。表3展示了运行SysBench OLTP基准测试的writes/sec结果，测试中连接数从50到500再到5000。Aurora可以从40K writes/sec扩展到110K writes/sec，MySQL的吞吐量在500个连接左右时达到峰值，然后随着连接数扩展到5000而急速下降。

[1501475431046_8788_1501475431168.png]

6.1.4 随副本数扩展

在这个测试中，我们发现Aurora读副本的延时比MySQL低很多，即使Aurora处在更高的负载情况下。表4展示了，随着负载从1K writes/sec到10K writes/sec，Aurora读副本的延时从2.62ms增长到5.38ms。相反，MySQL读副本的延时从1s增长到300s。在10K负载情况下，Aurora的副本延时比MySQL低几个数量级。副本延时通过一个被提交的事务在副本上可见所需要的时间来度量的。

[1501475445680_2163_1501475445797.png]

6.1.5 随Row Contention扩展

在这个测试中，我们发现相对于MySQL，Aurora在像TPC-C基准测试中有hot row contention的负载下也能表现的很好。我们在Aurora、MySQL5.6、MySQL5.7上运行Percona TPC-C类似工具，运行实例规格为r3.8xlarge挂载IOPS为30K的EBS。表5展示了Aurora可以保持相对MySQL5.7 的2.3倍到16.3倍的吞吐量，负载从10GB数量、500个连接，到100GB数据、5000个连接。

[1501475470034_730_1501475470256.png]

6.2 客户真实负载的测试结果

在这一小节中，我们分享一些客户在生产环境从MySQL迁移到Aurora的测试结果。

6.2.1 应用程序在Aurora的响应时间

一个互联网游戏公司将生产环境的服务从MySQL迁移到r3.4xlarge实例的Aurora上。在迁移之前，网络事务的平均响应时间为15ms。与之对应的，迁移之后的平均响应时间为5.5ms，差不多有了3倍的提升，如图8所示。

[1501475505999_7170_1501475506138.png]

6.2.2 Aurora中执行语句的延时

一个教育公司主要业务是帮助学校管理学生的笔记本电脑，将他们的服务从MySQL迁移到了Aurora。Select和单条记录insert语句在迁移前的中位点和95分位点如图9和图10所示。

[1501475522035_451_1501475522235.png]

在迁移之前，95分位延时在40ms到80ms之间，比中位点1ms差得远了。本文之前介绍了，应用程序会遇到这种少数性能极差的情况。在迁移之后，95分位的延时显著降低，接近中位点延时。

[1501475535756_6819_1501475535942.png]

6.2.3 多个副本下的复制延时

如Pinterest的Weiner所指出的，MySQL副本经常远落后于他们的写副本，会引起非常奇怪的bug。对于上面提到的那个教育公司，副本延时有时可能飙升到12分钟而影响到应用程序的正确性，所以这些副本只能作为一个备机。与之相对的，在迁移到Aurora之后，4个副本集的复制延时从未超过20ms，如图11所示。复制延时的显著改善让这家公司转移了一大部分应用程序的负载到只读副本上，既节约了成本又提高了可用性。

[1501475548150_4619_1501475548353.png]

7. 心得

我们遇到过运行各种各样的应用的客户，从小的互联网公司到大型的组织机构。他们很多的使用场景都是标准的，这里我们重点放在在云服务中比较常见的场景和期望，而这些导致我们走向了新的方向。

7.1 多租户和数据库聚合

很多我们的客户都经营SaaS服务，自己使用或者为他们自己的客户提供SaaS模型的服务。我们发现这些客户依赖的应用程序很难被改变。因而，他们通常将自己的很多客户集中在某一个实例上，使用库或者表来作为租赁的基本单位。这种模式可以节约成本：由于他们自己的客户不太可能同时使用，这样可以避免为每个客户申请一个单独的实例。举个例子，我们有些客户称他们自己有超过50K的客户。

这个模型与Salesforce.com著名的多租户应用场景有很大的不同，他们将数据打包到一个统一的表中，按行来租赁。因而，我们发现很多客户有很多张表。生产环境中数据库表超过150K是非常常见的。这给一些管理元数据的组件，如字典cache，带来很大压力。更重要的是，这些客户需要（a）保持高吞吐量和连接数，（b）存储容量按使用扩展和收费，因为很难提前预知需要多大的存储，（c）减少抖动，这样一个租户的峰值对其他租户的影响很小。Aurora支持所有的这些特性，而且很适合SaaS应用。

7.2 高并发自动扩展的负载

互联网的负载通常需要应对突发事件引起的网络流的尖峰。我们有个重要客户在一个很火的全国电视节目时，遇到过一次远超过平时负载吞吐量高峰的流量，不过没有对数据库构成压力。为了支持这样的突发流量，数据库需要同时能处理很多并发的请求。Aurora在这种场景下也能处理的很好，因为它的底层存储系统扩展性极好。我们有很多客户每秒钟的连接数超过8000次。

7.3 Schema演进

现代Web应用程序框架如Ruby on Rails深入集成了ORM工具。因而，应用程序可以很方便的改变数据库的schema，然而却让DBA们很难把握schema会如何演进。在Rails应用程序中，这些称之为DB迁移，我们听到一线的DBA称他们一周可能会有几十次DB迁移，或者会提前准备好策略来让未来的变更会比较容易。这些问题在MySQL中被放大，因为MySQL提供自由的schema变更语义，使用整表拷贝的方式来实现大多数变更。既然频繁的DDL是一个现实问题，我们在Aurora中实现了高效的在线DDL，（a）为每一个数据页关联一个schema版本，通过schema的变更历史来解码单个数据页，（b）用modify-on-write的方式按需将单个数据页更新到最新的schema。

7.4 可用性和软件更新

客户对云上的数据库的一些迫切的期待与我们如何运营系统和如何给服务器升级可能是相互矛盾的。由于我们的客户主要用Aurora来作为一个OLTP服务支撑线上应用程序，任何的干扰都可能导致严重的后果。因而，很多客户对我们更新数据库软件的容忍度是非常低的，即使在六周内只计划30s的服务暂停时间也不行。我们近期发布了一个Zero Downtime Patch ZDP特性，使得我们可以在保证已有的数据库连接不受干扰的情况下，更新服务器。

如图12所示，ZDF的原理是，首先找到一个没有活动连接的实例，将实例的应用程序状态导出到持久化存储中，给引擎升级，然后导入应用程序状态。在这个过程中，用户的session不受影响，对引擎的升级是无感知的。

[1501475579277_1373_1501475579450.png]

8. 相关工作

在本节中，我们介绍其他人的贡献以及它们如何Aurora中采用的方案关联的。

存储计算分离。尽管传统的数据库系统都会被构造成一个庞然大物，近期有一些数据库方面的工作将内核解耦为不同的组件。举个例子，Deuteronomy10就是这样的系统，它分离了提供并发控制的事务组件，和提供恢复功能构建在LLAMA34的数据组件，其中LLAMA是一个无锁、日志结构的缓存和存储管理器。Sinfonia39和Hyder40这些系统将事务的方法抽象成一个可扩展的服务，数据库系统的实现可以使用这些抽象。Yesquel36实现了一个多版本的分布式平衡树，将并发控制和查询处理器分开。Aurora比Deuteronomy、Sinfonia、Hyder和Yesquel在更低的层次将存储解耦出来。在Aurora中，查询处理器、事务、并发控制、buffer cache和访问方式是与日志、存储、故障恢复解耦的，后者被实现为可扩展的服务。

分布式系统。在分区的条件下，正确性和可用性的折中，以及one-copy序列化是不可能的是CAP理论里有名的结论。更近一些的，Brewer的CAP理论在16中证明得到结论：一个高度可用的数据库系统在网络隔离的情况下不可能提供强一致性。这些结论以及我们对云级别规模的复杂且相互关联故障的经验，促使我们定下即使在一个AZ不可用的条件下仍然保持一致性的设计目标。

Bailies等人12研究了高可用事务HATs，HAT既不会受网络分区导致的不可用的影响，又不会导致高的网络延时。他们的工作说明了Serializability,Snapshot Isolation, Repeatable Isolation不是HTA兼容的。Aurora提供所有这些隔离级别，基于一个简化的前提：在任意一个时间点，只有一个写副本在生成日志，这些日志的LSN在同一个有序空间里分配。

Google的Spanner24提供外部一致25的读和写，全局一致的指定时间点的读。这些特性可以让Spanner提供全局的一致的备份，全局的一致的分布式查询处理，全局的原子的schema更新，即使是在有事务正在执行的情况下。就像Bailis所描述的，Spanner是为Google读负载高的场景定制的，在读和写的时候依赖于两阶段提交和两阶段锁。

并发控制。 弱一致性17以及隔离模型18在分布式数据库中是众所周知的，也导致了乐观复制技术19和最终一致性系统的出现。集中式系统的一些方案包括，经典的悲观锁方式，如Hekaton29中的MVCC的乐观锁方式，如VoltDB30中的分片模式，Hyper31中的时间戳序列模式，还有Deuteronomy。Aurora的存储服务为数据库引擎提供了一个本地盘的抽象，让引擎来决定隔离级别和并发模式。

日志结构的存储。日志结构的存储在1992年首先出现在LFS33中。最近的Deuteronomy以及LLAMA34中的相关工作，还有Bw-Tree35在存储引擎栈中以多种形式使用了日志结构的技术，像Aurora一样，它们通过只写数据页的变更来减少写放大。Deuteronomy和Aurora实现的都是纯粹的REDO日志方式，并跟踪事务确认回复的最大的LSN。

故障恢复。传统的数据库都依赖于类似ARIES5的恢复协议来实现故障恢复，近期很多系统为性能的考虑选择了其他的路径。举个例子，Hekaton和VoltDB使用某种更新日志来重建它们的内存状态。类似Sinfonia39的系统，使用process pairs和状态机复制技术来避免故障恢复。Graefe41介绍了使用每页的日志记录链来加快按需的page-by-page的REDO以加快恢复速度。跟Aurora一样，Deuteronomy不需要REDO恢复，这是因为Deuteronomy只会将已经提交的更新写入存储。因而，不像Aurora，Deuteronomy里的事务数量是受限制的。

9. 结论

我们在云环境下将Aurora设计为一个高吞吐量的OLTP数据库，不牺牲可用性和可持久性。主要的思想是避免传统数据库庞大复杂的结构，将存储和计算解耦。具体来说，我们将数据库内核最下面一小部分移到一个独立可扩展分布式的负责日志记录和存储数据的存储服务中。由于这时所有的IO都通过网络，我们最根本的限制变成了网络。因而，我们将重点放在缓解网络开销、增加吞吐量的技术上。我们依赖的技术有：多数派模型—可以处理在大规模云服务环境下复杂关联的故障，避免最差性能点的惩罚，通过日志处理来减少整体的IO负担，异步的一致性来避免沟通复杂且代价昂贵的多阶段同步协议，离线故障恢复，在分布式存储中建立检查点。我们的方案能得出一个简化的复杂度降低的系统，可以很方便的扩展，并为以后的演进奠定基础。

10. 致谢

在此，我们对Aurora开发团队的所有成员的努力表示感谢，包括现有的成员，以及我们优秀的同事们（James Corey，Sam Mckelvie，Yan Leshinsky, Lon Lundgren, Preadeep Madhavarapu, Stefano Stefani）。我们要特别感谢我们的客户，他们在生产环境使用我们的服务，并且给我们分享他们的经验和期望。同时，我们也要感谢评审们的宝贵意见。