优化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 change buffer，因为无法将更改缓存到二级索引，同时还要分配存储。这会导致对具有辅助（非唯一）索引的表的写入产生巨大的性能问题。

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

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

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

一种策略可能是制作Aurora集群的非Aurora只读副本，并仅在只读副本中创建二级索引以支持SELECT查询。根据{{​​3}}

，我从未这样做过，但显然这是可能的

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

我的结论是，我不会选择将Aurora用于大量写入应用程序。也许这将在未来发生变化。

Answer 2

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

我们做了什么：

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

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

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

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

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

Answer 3

对于Google员工：

• Aurora需要实时写入多个副本，因此必须有一个带有锁定，等待，检查机制的队列
• 这种行为在连续写入请求中不可避免地导致CPU利用率过高和延迟，只有在同步多个副本时才会成功
• 自Aurora成立到2020年，这种情况一直存在。如果要保持服务的低存储成本和合理的计算成本，这在逻辑上很难甚至不可能解决
• Aurora MySQL的大写性能可能比RDS MySQL差10倍以上（根据个人经验并得到以上答案的证实）

要解决此问题（更像是变通方法）：

• 如果您的工作量超过5％，则对Aurora保持谨慎
• 如果需要近乎实时的大量写入结果，请谨慎使用Aurora
• 删除@Bill Karwin指出的二级索引以改善写作
• 批量应用插入和更新可能会改善写作效果

我说“要小心”，但不能说“不要使用”，因为通过巧妙的体系结构设计可以解决许多情况。数据库写性能几乎不能依赖。