对于慢速查询和“正常”活动，什么是高效的 RDS 实例类型？

Question

背景

我们目前在 AWS 上托管一个应用程序，前端使用 S3，LB/autoscaling-group 后面有 2 个 API 服务器用于 API，以及 Aurora postgresql RDS。

最近我们引入了一些数据库计算，需要一些时间来计算（如果我们没有看到任何活动，则需要 800 毫秒；如果活动正常，大约需要 2 秒；但在活动高峰期间，需要 5/6 秒）。 db.t4g.medium 无法承受负载（CPU 达到 100%），因此我们升级到 t4g.large，但看起来它并没有做更多的事情。我不确定到底是什么问题。连接量似乎很好（根据记忆，我们可以达到 400，并且我们在 40 时达到最大），但每个请求都开始花费越来越多的时间。 计算应该仅是 SELECT，因此不会锁定数据库。 请注意，API 服务器运行良好。

T 实例进行了调整，因为我们在某些高峰活动期间使用积分，并在夜间恢复。但由于这些新功能的数据库计算量较高，而且我们的用户量迅速增加，CPU积分无法恢复，我们一直在使用积分。所以看起来我们的规模很小。

我们正在做什么/做过什么

一方面，我们正在努力通过将大查询切成小查询、添加索引来优化查询。但这需要一些时间，因此我们希望做好准备，最终升级为新的实例类型，如果有信心的话，稍后再缩小规模。

我研究了 work_mem 参数，但我不确定我们是否担心，因为 ANALYZE 在外部排序中仅返回几 kb。 RDS 上的活动内存和可用内存相当不错。活动内存约为 1.3Gb，可用内存约为 5Gb。

有什么建议吗？

我不确定还需要检查什么？什么样的数据库对于我们的负载类型是有效的。我没有找到像这样的混合用例的好的建议（通常他们会为纯 OLAP 推荐这个或那个，或者纯粹的超快速查询，但对于混合则没有太多推荐）。

你们有什么建议吗：

• Postgres 参数有哪些值得调整的地方？
• Postgres 是否已经适应了这一点，或者我们是否应该考虑迁移 MySQL？
• RDS实例类型适应这样的负载？

谢谢！

Answer 1

快速更新，向某些表添加索引极大地提高了性能。它将查询持续时间划分为 50 到 100 左右。过去需要 4 秒的查询现在只需要大约 50 毫秒，这太疯狂了。

问题仍然存在，作为一般用途，哪些实例类型最适合实际的慢速查询和快速写入操作？