我有一个正在运行的 AWS Aurora 数据库集群，它 99.9% 都专注于写入。在高峰期，它将运行 2-3k 写入/秒。
我知道 Aurora 默认对写入进行了一些优化，但作为 AWS 的新手，我想问一下 - 使用 Aurora 的写入性能有哪些最佳实践/技巧？
【问题讨论】：
标签： mysql database amazon-web-services amazon-aurora
根据我的经验，Amazon Aurora 不适合运行具有大量写入流量的数据库。至少在 2017 年左右实施。也许随着时间的推移会有所改善。
我在 2017 年初为一个写入繁重的应用程序进行了一些基准测试，我们发现，考虑到我们的应用程序和数据库，RDS（非 Aurora）在写入性能方面远远优于 Aurora。基本上，Aurora 比 RDS 慢了两个数量级。亚马逊声称 Aurora 的高性能显然完全是营销驱动的废话。
2016 年 11 月，我参加了在拉斯维加斯举行的 Amazon re:Invent 大会。我试图找到一位知识渊博的 Aurora 工程师来回答我关于性能的问题。我能找到的只有初级工程师，他们被命令重复声称 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 只读副本，并仅在只读副本中创建二级索引以支持您的 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 服务器自己安装在使用本地存储的 EC2 实例上，尤其是带有本地连接 NVMe 的 i3 实例。我知道实例存储不可靠，因此需要运行冗余节点。
MySQL 服务器自己安装在我们数据中心的物理主机上，使用直连 SSD 存储。
使用 Aurora 作为托管云数据库的价值不仅仅在于性能。它还具有自动监控、备份、故障转移、升级等功能。
【讨论】：
对于我的用例，我在使用 Aurora 时获得了相对积极的体验。我相信（时间已经过去）我们正在推动接近每秒 20k DML 的最大实例类型（我认为是 db.r3.8xlarge？）。为含糊而道歉，我不再有能力获得该特定系统的指标。
我们做了什么：
该系统不需要对给定的插入“立即”响应，因此写入被排入单独的进程。此过程将收集 N 个查询，并将它们分成 M 个批次，其中每个批次与一个目标表相关联。这些批次将放在一个 txn 中。
我们这样做是为了实现批量写入的写入效率，并避免跨表锁定。有 4 个独立的（我相信？）进程执行此出列和写入行为。
由于写入负载如此之高，我们绝对必须将所有读取推送到只读副本，因为主节点通常占用 50-60% 的 CPU。我们通过简单地创建随机数据写入器进程来预先审查这个架构，并在我们将实际应用程序提交给它之前对一般系统行为进行建模。
写入几乎都是INSERT ON DUPLICATE KEY UPDATE 写入，并且表有许多二级索引。
我怀疑这种方法对我们有用，仅仅是因为我们能够容忍信息出现在系统中与读者实际需要它之间的延迟，从而允许我们批量处理更高的数量。 YMMV。
【讨论】：
对于 Google 员工：
解决问题（更像是一种变通方法）：
我说的是“小心”而不是“不要使用”，因为许多场景都可以通过巧妙的架构设计来解决。数据库写入性能几乎无法依赖。
【讨论】：