优化AWS Aurora实例的写入性能

Question

我有一个运行的AWS Aurora数据库集群,99.9%专注于写入.在它达到峰值时,它将以每秒2-3k的速度运行.

我知道Aurora在默认情况下对写入有所优化,但我想问一下AWS的相对新手 - Aurora的写性能最佳实践/技巧是什么？

Answer 1

根据我的经验,Amazon Aurora不适合运行具有大量写入流量的数据库.至少在大约2017年的实施中.也许它会随着时间的推移而改善.

我在2017年早些时候为一个写入量大的应用程序做了一些基准测试,我们发现RDS(非Aurora)在写入性能方面远远优于Aurora,因为我们的应用程序和数据库.基本上,Aurora比RDS慢两个数量级.亚马逊声称Aurora的高性能显然完全是以营销为导向的废话.

2016年11月,我参加了在拉斯维加斯举行的Amazon re:Invent大会.我试图找到一位知识渊博的Aurora工程师来回答我关于性能的问题.我所能找到的只是初级工程师,他们被要求重复声称Aurora神奇地比MySQL快5-10倍.

2017年4月,我参加了Percona Live会议,并看到了如何使用开源组件CEPH开发类似Aurora的分布式存储架构的演示.这里有一个关于同一主题的网络研讨会:https://www.percona.com/resources/webinars/mysql-and-ceph,由我见过的工程师Yves Trudeau共同主持.

使用MySQL与CEPH的关系是,工程师必须禁用MySQL更改缓冲区,因为无法将更改缓存到二级索引,同时还要分配存储.这会导致写入具有辅助(非唯一)索引的表的巨大性能问题.

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

因此,如果您绝对必须将Aurora用于具有高写入流量的数据库,我建议您必须做的第一件事就是删除所有二级索引.

显然,如果需要索引来优化您的某些查询,则会出现问题.当然,SELECT查询和一些UPDATE和DELETE查询都可以使用二级索引.

一种策略可能是制作Aurora集群的非Aurora只读副本,并仅在只读副本中创建二级索引以支持SELECT查询.根据https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/,我从未这样做,但显然这是可能的.

但是这仍然无助于UPDATE/DELETE语句需要二级索引的情况.我对这种情况没有任何建议.你可能运气不好.

我的结论是,我不会选择使用Aurora来进行大量写入.也许这将在未来发生变化.

Answer 2

对于谷歌员工：

• Aurora需要实时写入多个副本，因此必须有一个带有锁定、等待、检查机制的队列
• 当存在连续写入请求时，这种行为不可避免地会导致超高的 CPU 利用率和延迟，而这些请求只有在多个副本同步时才会成功
• 自 Aurora 成立以来一直到 2020 年，这个问题就一直存在，如果我们要保持服务的低存储成本和公平的计算成本，从逻辑上讲，解决这个问题即使不是不可能，也是很困难的
• Aurora MySQL 的大容量写入性能可能比 RDS MySQL 差 10 倍以上（来自个人经验并得到上述答案的证实）

解决问题（更像是解决方法）：

• 如果超过 5% 的工作量用于写入，请小心 Aurora
• 如果您需要大容量写入的近实时结果，请小心 Aurora
• 正如 @Bill Karwin 指出的那样，删除二级索引以提高写作水平
• 批量应用插入和更新可以改善写作

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

Answer 3

对于我的用例，我在使用 Aurora 时获得了相对积极的体验。我相信（时间已经过去）我们正在推动接近每秒 20k DML，最大的实例类型（我认为 db.r3.8xlarge？）。为含糊而道歉，我不再能够获得该特定系统的指标。

我们做了什么：

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

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

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

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

我怀疑这种方法对我们有用，仅仅是因为我们能够容忍系统中出现信息和读者实际需要它之间的延迟，从而允许我们批量处理更高的数量。天啊。