咨询Aurora数据库专家三个性能问题

Question

【以下的问题经过翻译处理】 咨询Aurora数据库专家的3个性能问题：

* 对于我们的生产RDS MySQL实例，AWS的一位工程师强烈建议我们使用预配置IOPS而不是普通GP IOPS以确保始终保持良好的性能。Aurora是否也有不同IOPS类型的概念，如果有，哪些适合生产工作负载？

我的想法：与标准RDS不同，Aurora的IOPS报告方式不同，因为Aurora不使用传统的块存储。我推测主实例必须连接到一些磁盘，但是怀疑没有IOPS的配置选项，对吗？

* 我们的一些查询会进行复杂的数学计算（haversine距离计算等）。相比于原生MySQL，当在Aurora上执行这些查询时，我们应该对CPU负载和性能有什么样的期望？

我的想法：考虑到Aurora的解耦架构，我认为Aurora的的表现会比 RDS MySQL 更好，但是我找不到任何支持这一点的数据。

* 我们想在现有MySQL主实例下添加Aurora读副本来测试Aurora在生产负载下的性能。类似这样：

```
                  现有MySQL主实例
                     /      \
                    /        \
                   /          \ 
                 现有MySQL读副本  新的Aurora读副本
```

将 MySQL 和 Aurora 的异构读副本组合在一起是个好主意吗？如果这样做，可能会发生什么问题？

我的想法：考虑到Aurora的架构方式，在我看来似乎不是一个好办法。Aurora的架构方式是这样的，您有一个主实例与共享存储连接。然后可以添加读副本（最多 15 个），它们连接到相同的底层共享存储。所以，虽然我欣赏这种"开箱即用"的思路，但我认为这并不完全符合 Aurora 的架构模式 - 不过我会确认并更新！

Answer

【以下的回答经过翻译处理】 * 对于我们的生产RDS MySQL实例，AWS的一位工程师强烈建议我们使用预配置IOPS而不是普通GP IOPS以确保始终保持良好的性能。Aurora是否也有不同IOPS类型的概念，如果有，哪些适合生产工作负载？

有多种考虑因素，PIOPS提供更高的最大性能(IOPS)和更好的性能稳定性。由于RDS存储基于EBS，因此这里描述的存储卷特性也适用于RDS。但是，RDS会将较大的存储容量条带化到多个底层EBS卷上。当客户使用较小的实例类型时也要注意这点：“\* 这些实例类型可以每24小时至少可以提供一次持续30分钟的最大性能。例如，c5.large实例每24小时至少可以提供一次持续30分钟的437.5 MB/s的吞吐量。”-来源：

I/O heavy analytical queries that benefit from sequential block read operations on a filesystem, might be slower in Aurora.

Aurora I/O不同，不能与块级I/O进行比较，写入仅为重做日志，而非完整数据页，我们也对其进行了批量操作。读取是完整的数据页。在大多数情况下，从I/O的角度来看，Aurora的设计更有优势。但是也有例外——对于在文件系统上受益于顺序块读取操作的重的分析查询，在Aurora中可能会较慢。

* 我们的一些查询会进行复杂的数学计算（haversine距离计算等）。相比于原生MySQL，当在Aurora上执行这些查询时，我们应该对CPU负载和性能有什么样的期望？

必须进行测试来了解性能如何。没有可靠的方法来预测。数据在缓冲池中的缓存程度可能是最大的影响因素。

* 我们想在现有MySQL主实例下添加Aurora读副本来测试Aurora在生产负载下的性能。[...] 将 MySQL 和 Aurora 的异构读副本组合在一起是个好主意吗？如果这样做，可能会发生什么问题？

可以通过控制台进行此操作。Amazon RDS 支持将 Aurora MySQL 集群作为托管的读取副本附加到 RDS MySQL 数据库实例。附加一个额外的 binlog 只读副本可能会对主实例产生性能影响。由于读写进程之间访问binlog时发生争用，MySQL 5.6 上的影响更大。在 MySQL 5.7 中这种影响有所降低。

从负载测试的角度来看，binlog将使Aurora副本与更改保持同步，但不会反映在主实例上发生的写入并发性。从测试条件的角度来看，这可能是一个问题，测试不能很好地反映在生产环境中遇到的并发争用情况。

咨询Aurora数据库专家三个性能问题

相关内容