Tag: Amazon Aurora


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 WeinGrant 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