亚马逊AWS官方博客

Amazon Aurora Update – PostgreSQL 兼容性

就在两年前 (恍如昨日)，我在我发布的帖文 Amazon Aurora – New Cost-Effective MySQL-Compatible Database Engine for Amazon RDS 中向大家推荐了 Amazon Aurora。在那个帖文中，我告诉大家 RDS 团队如何以全新、不受限的观点来看待关系数据库模型，并解释了他们如何为云端构建关系数据库。

自那之后，我们收到了一些来自客户的反馈，非常感人。客户非常喜欢 MySQL 兼容性，重视高可用性和内置加密。他们对以下事实充满期待：Aurora 围绕具有容错能力和自我修复能力的存储而构建，使他们能够从 10 GB 一直扩展到 64 TB，而无需预先配置。他们知道，Aurora 跨三个可用区创建了其数据的六个副本，并在不影响性能或可用性的情况下将数据备份到了 Amazon Simple Storage Service (S3)。随着他们不断扩展，他们知道自己可以至多创建 15 个低延迟只读副本，这些副本从公用存储中获取。要了解有关我们的客户如何在全球范围的生产环境中使用 Aurora 的详细信息，请花一些时间阅读我们的 Amazon Aurora 客户评价。

当然，客户永远在追求更多，而我们也将竭尽全力了解他们的需求并尽力满足。下面是对我们根据客户的具体反馈所做的一些近期更新的回顾：

10 月 – 从存储过程中调用 Lambda 函数。
10 月 – 从 S3 中加载数据。
9 月 – 读取器终端节点用于实现负载均衡和更高的可用性。
9 月 – 并行预读、更快的索引、NUMA 感知。
7 月 – 从 MySQL 备份中创建群集。
6 月 – 跨区域只读副本。
5 月 – 跨帐户快照共享。
4 月 – RDS 控制台中的群集视图。
3 月 – 额外故障转移控制。
3 月 – 本地时区支持。
3 月 – 亚太区域 (首尔) 可用性。
2 月 – 亚太地区 (悉尼) 可用性。

而且现在提供 PostgreSQL 兼容性

除了功能级的反馈外，我们还收到了许多有关其他数据库兼容性的请求。居于首位的是与 PostgreSQL 的兼容性。该开源数据库 20 年来不断发展，在很多企业和初创公司中受到了广泛应用。客户喜欢使用与 PostgreSQL 相关联的企业功能 (类似于由 SQL Server 和 Oracle 所提供的功能)、性能优势以及地理空间对象。他们希望能访问这些功能，同时又能使用 Aurora 所提供的所有功能。

目前我们正在推出与 PostgreSQL 兼容的 Amazon Aurora 预览版。它提供了以上所列的所有优势，包括高持久性、高可用性以及快速创建和部署只读副本的能力。以下是您将会喜欢的关于该版本的几个方面：

性能 – Aurora 提供的性能是传统环境中运行的 PostgreSQL 性能的两倍。

兼容性 – Aurora 与 PostgreSQL 的开源版本 (版本 9.6.1) 完全兼容。在存储过程方面，我们正在计划支持 Perl、pgSQL、Tcl 和 JavaScript (通过 V8 JavaScript 引擎)。我们还计划支持 Amazon RDS for PostgreSQL 中所支持的所有 PostgreSQL 功能和扩展。

云原生 – Aurora 会充分利用它在 AWS 内运行这一事实。以下是一些交触点：

以下是您从 RDS 控制台访问所有这些的方式。首先选择 PostgresSQL Compatible 选项：

然后选择您的数据库实例类型，决定多可用区部署，命名您的数据库实例，然后设置用户名和密码：

我们正在预览目前美国东部 (弗吉尼亚北部) 区域提供的 Amazon Aurora 的 PostgreSQL 兼容性，并且您可以通过立即注册来进行访问。

快速比较

我的同事 David Wein 和 Grant McAlister 运行了一些测试，将 Amazon Aurora 的 PostgreSQL 兼容性性能与 PostgreSQL 9.6.1 进行比较。数据库服务器在 m4.16xlarge 实例上运行，测试客户端在 c4.8xlarge 实例上运行。

PostgreSQL 利用 45K 的预配置 IOPS 存储运行，该存储由条带化至一个逻辑卷中的三个 15K IOPS EBS 卷组成，还使用了一个 ext4 文件系统。他们启用了 WAL 压缩和积极的 autovacuum，这两者都可以提高他们所测试的工作负载上的 PostgreSQL 性能。

David 和 Grant 运行的是标准 PostgreSQL pgbench 基准测试工具。他们采用了 2000 的缩放因子，这会创建一个 30 GiB 数据库并会使用多个不同的客户端计数。每个数据点运行一个小时，每次运行之前重新创建数据库。下图显示了测试结果：

David 还分享了其中一次运行的最后几秒钟的过程：

Bash

progress: 3597.0 s, 39048.4 tps, lat 26.075 ms stddev 9.883

progress: 3598.0 s, 38047.7 tps, lat 26.959 ms stddev 10.197

progress: 3599.0 s, 38111.1 tps, lat 27.009 ms stddev 10.257

progress: 3600.0 s, 34371.7 tps, lat 29.363 ms stddev 14.468

transaction type:

scaling factor: 2000

query mode: prepared

number of clients: 1024

number of threads: 1024

duration: 3600 s

number of transactions actually processed: 137508938

latency average = 26.800 ms

latency stddev = 19.222 ms

tps = 38192.805529 (including connections establishing)

tps = 38201.099738 (excluding connections establishing)

 
       
他们还分享了涵盖一次类似运行的最后 40 分钟的每秒吞吐量图：
 
       
 
       
如您所见，Amazon Aurora 比 PostgreSQL 提供更高的吞吐量，具有约 1/3 的抖动 (分别为 1395 TPS 和 5081 TPS 的标准偏差)。
 
       
David 和 Grant 现在正在收集数据，用于撰写一篇更为详细的帖文，他们计划于 2017 年初发布这篇帖文。
 
       
即将推出 – Performance Insights
 
       
我们还在研究一项新的工具，旨在帮助您非常详细地了解数据库性能。您将能够深入查看每个查询，并详细了解您的数据库如何处理查询。以下是一个非正式预览的屏幕截图：
 
       
 
       
在预览时，您将能够访问新的 Performance Insights。稍后我将提供更多细节和全部预览。
 
       
— Jeff