优化AWS Aurora实例的写入性能

Question

我有一个AWS Aurora DB集群在运行，它99.9%专注于写操作。在它的峰值，它将运行2-3k写入/秒。

我知道Aurora在默认情况下对写入进行了一些优化，但作为AWS的相对新手，我想问一下- Aurora的写入性能有哪些最佳实践/提示？

Answer 1

根据我的经验，Amazon Aurora不适合运行写入流量很大的数据库。至少在2017年左右的实施中。也许随着时间的推移，它会有所改善。

2017年早些时候，我为一个写繁重的应用程序做了一些基准测试，我们发现，考虑到我们的应用程序和数据库，RDS (非Aurora )在写入性能上远远优于Aurora。基本上，Aurora比RDS慢两个数量级。亚马逊声称Aurora的高性能显然完全是营销驱动的胡说八道。

2016年11月，我参加了在拉斯维加斯举行的亚马逊re:发明大会。我试图找到一位知识渊博的Aurora工程师来回答我关于性能的问题。我所能找到的都是初级工程师，他们被命令重复声称极光神奇地比MySQL快5-10倍。

2017年4月，我参加了Percona Live大会，看到了一篇关于如何使用标准MySQL和CEPH为开源分布式存储层开发类似于Aurora的分布式存储体系结构的演示文稿。这里有一个关于同一主题的网络研讨会：https://www.percona.com/resources/webinars/mysql-and-ceph，由我在会议上看到的工程师Yves Trudeau共同提出。

在使用MySQL和CEPH时，很明显工程师必须禁用MySQL change buffer，因为无法缓存对辅助索引的更改，同时还可以分布式存储。这给写入具有辅助(非唯一)索引的表带来了巨大的性能问题。

这与我们在使用Aurora对应用程序进行基准测试时看到的性能问题是一致的。我们的数据库有很多二级索引。

因此，如果您绝对必须使用Aurora来处理具有高写入流量的数据库，我建议您必须做的第一件事就是删除所有辅助索引。

显然，如果需要索引来优化某些查询，这将是一个问题。当然，无论是SELECT查询，还是某些UPDATE和DELETE查询，都可以使用辅助索引。

一种策略可能是创建Aurora集群的非Aurora read副本，并仅在read副本中创建辅助索引以支持您的SELECT查询。根据https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/的说法，我从来没有这样做过，但显然这是可能的

但是，在UPDATE/DELETE语句需要辅助索引的情况下，这仍然没有帮助。对于这种情况，我没有任何建议。你可能不太走运。

我的结论是，我不会选择将Aurora用于编写繁重的应用程序。也许这种情况在未来会有所改变。

2021年4月更新：

写完上面的内容后，我已经针对Aurora版本2运行了sysbench基准测试。我不能分享具体的数字，但我得出的结论是，目前Aurora的改进更适合于写繁重的工作负载。我确实运行了很多二级索引的测试，以确保。但我鼓励任何认真考虑采用Aurora的人运行自己的基准测试。

至少，Aurora比使用EBS存储的传统Amazon RDS for MySQL要好得多。这可能就是他们声称极光比MySQL快5倍的地方。但Aurora并不比我测试的其他一些替代方案更快，而且实际上无法与之匹敌：

• MySQL服务器将我自己安装在使用本地存储的EC2实例上，尤其是具有本地连接的NVMe的i3实例。我知道实例存储不可靠，因此需要运行冗余节点。

• MySQL服务器使用直接连接的固态硬盘存储，将我自己安装在数据中心的物理主机上。

使用Aurora作为托管云数据库的价值不仅仅在于性能。它还具有自动监控、备份、故障切换、升级等功能。

Answer 2

对于我的用例，我对Aurora有一个相对积极的体验。我相信(时间已经过去了)我们的速度接近每秒20k DML，最大的实例类型(我认为db.r3.8xlarge？)。很抱歉，我不再有能力获得该特定系统的指标。

我们所做的：

该系统不需要“立即”响应给定的插入，因此写入被排入一个单独的进程。这个过程将收集N个查询，并将它们分成M个批次，其中每个批次都与一个目标表相关。这些批次将被放入单个txn中。

我们这样做是为了从批量写入中获得写入效率，并避免交叉表锁定。有4个独立的(我相信？)执行此出队和写入行为的进程。

由于这种高写入负载，我们必须将所有读操作都推送到一个读副本，因为主副本通常占用50-60%的CPU。我们通过简单地创建随机数据写入器进程预先审查了这个拱门，并在提交实际应用程序之前对一般系统行为进行了建模。

这些写操作几乎都是INSERT ON DUPLICATE KEY UPDATE写操作，并且这些表有许多二级索引。

我怀疑这种方法之所以对我们有效，仅仅是因为我们能够容忍信息出现在系统中和读者真正需要它之间的延迟，从而允许我们以更高的数量进行批量处理。YMMV.

Answer 3

面向谷歌用户的：

• Aurora需要实时地写入多个复制品，因此必须存在一个具有锁定、等待、检查mechanisms
• This行为的队列，当存在仅当多个复制品被同步时才成功的连续写入请求时，这将不可避免地导致超高的CPU利用率和滞后。
• 这从Aurora成立以来一直存在，直到2020年，如果我们要保持service
• High-volume的低存储成本和公平计算成本，即使不是不可能解决，逻辑上也是困难的。Aurora MySQL的写入性能可能比RDS MySQL差10倍以上(根据个人经验，并得到上述答案的证实)

解决问题的(更像是一种变通方法)：

• 小心使用Aurora如果超过5%的工作负载正在写入
• 如果您需要接近实时的大容量写入结果
• 删除辅助索引@Bill Karwin指出要改进

插入和更新可能会改进写入

我说的是“要小心”，而不是“不要使用”，因为许多场景都可以通过巧妙的架构设计来解决。数据库写入性能很难依赖。