我有一个正在运行的 AWS Aurora 数据库集群，它 99.9% 专注于写入。在高峰期，它将运行 2-3k 写入/秒。
我知道 Aurora 默认情况下针对写入进行了一定程度的优化，但作为 AWS 的相对新手，我想问一下 - 关于 Aurora 写入性能的一些最佳实践/技巧是什么？
最佳答案
根据我的经验，Amazon Aurora 不适合运行写入流量大的数据库。至少在 2017 年左右实现。也许它会随着时间的推移而改进。
我在 2017 年初为一个写入密集型应用程序制定了一些基准测试，我们发现 RDS(非 Aurora)在写入性能方面远优于 Aurora，考虑到我们的应用程序和数据库。基本上，Aurora 比 RDS 慢两个数量级。亚马逊声称 Aurora 的高性能显然完全是营销驱动的废话。
2016 年 11 月，我参加了在拉斯维加斯举行的亚马逊 re:Invent 大会。我试图找到一位知识渊博的 Aurora 工程师来回答我关于性能的问题。我所能找到的都是初级工程师，他们奉命重复声称 Aurora 神奇地比 MySQL 快 5-10 倍的说法。
2017 年 4 月，我参加了 Percona Live session ，看到了关于如何使用标准 MySQL 和 Ceph 为开源分布式存储层开发类似 Aurora 的分布式存储架构的演示。这里有一个关于同一主题的网络研讨会:https://www.percona.com/resources/webinars/mysql-and-ceph ，由我在 session 上发言的工程师伊夫·特鲁多 (Yves Trudeau) 共同介绍。
关于将 MySQL 与 Ceph 一起使用变得清楚的是，工程师必须禁用 MySQL change buffer因为没有办法缓存对二级索引的更改，同时也有分布式存储。对于写入具有二级(非唯一)索引的表，这会导致巨大的性能问题。
这与我们在使用 Aurora 对我们的应用程序进行基准测试时看到的性能问题是一致的。我们的数据库有很多二级索引。
因此，如果您绝对必须将 Aurora 用于具有高写入流量的数据库，我建议您必须做的第一件事是删除所有二级索引。
显然，如果需要索引来优化您的某些查询，这就是一个问题。当然，SELECT 查询以及一些 UPDATE 和 DELETE 查询都可能使用二级索引。
一种策略可能是创建 Aurora 集群的非 Aurora 只读副本，并仅在只读副本中创建二级索引以支持您的 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 要好得多。这可能就是他们声称 Aurora 比 MySQL 快 5 倍的地方。但 Aurora 并不比我测试的其他一些替代方案快，而且实际上无法匹配:
MySQL Server 使用本地存储将自己安装在 EC2 实例上，尤其是带有本地附加 NVMe 的 i3 实例。我知道实例存储不可靠，因此需要运行冗余节点。
MySQL Server 使用直连 SSD 存储在我们数据中心的物理主机上安装。
将 Aurora 用作托管云数据库的值(value)不仅仅在于性能。它还具有自动监控、备份、故障转移、升级等功能。
关于mysql - 优化 AWS Aurora 实例的写入性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46383763/