第二版 – Amazon SSD PIOPS 真的更好吗？

对于当今的许多应用程序来说，磁盘速度非常重要，这就是为什么一些 AWS 用户会转向各种可用的弹性块存储 (EBS) 选项。作为一种内存数据库，Redis 主要依赖于内存，使得磁盘速度不太重要，但是——这是一个很大的“但是”——Redis 也是持久的，并且使用磁盘进行复制。那么，当您已经运行 Redis 服务器时，是否值得额外付费从 AWS 获得更快的磁盘？

我们最初的假设是“否”，主要是因为 Redis 在创建 AOF 文件时使用顺序写入，并且在执行复制时，它只是将内存转储到磁盘中。这些操作都没有利用 SSD 的快速分配或 PIOPS 的优势。两年前，我们进行了一些测试，证明了我们的假设，最近我们再次对其进行了测试，以检查结果是否发生了变化。

测试

我创建了三个基准来比较 EBS 磁盘速度与普通磁性磁盘、带 SSD 的 EBS 和带 SSD PIOPS 的 EBS。该基准测试是在三个节点上完成的，每个节点都有自己的 EBS，并且我们的 Redis Clouds 服务安装在其之上。我想使用 PIOPS 的最佳配置，所以我选择了 c3.4xlarge 实例类型（更多关于这一点，请点击这里）。我将 Redis 配置为每秒写入其仅追加文件（即appendfsync everysec），这是 AOF 的默认设置，被认为是常见的用例。最后，我没有使用复制以避免不必要的网络噪音，因为此基准测试的重点是磁盘使用情况。

设置

我们客户端机器的实例类型是 c3.2xlarge，我使用了我们自己开发的 memtier_benchmark 工具来模拟工作负载。

基准测试运行仅执行写入操作。我使用了 10KB 对象，并让基准测试使用 50 个并发连接和 25 的管道大小。供您参考，以下是我在 memtier_benchmark 中使用的命令行参数

 –ratio=1:0 –test-time=120 -d 10000 -t 1 -c 50 –pipeline=25

该比率仅设置为写入 (SET) 操作，测试时间为 2 分钟。我每个测试运行两次，一次使用单线程，一次使用 4 个线程，因为我想检查线程数量的影响（如果有的话）。

结果

令我惊讶的是，这些基准测试表明，在 SSD 和 SSD PIOPS 上运行 Redis 比在磁性磁盘上运行更好

逻辑保持不变，磁盘物理特性也没有改变——就其本身而言，磁性 EBS 应该提供与 SSD EBS 相似的吞吐量和延迟。但是我们发现，使用 SSD EBS 会让您获得更好的硬件和更快的网络，这将使性能翻倍。请注意，将 memtier_benchmark 客户端线程数从 1 增加到 4 会导致性能下降，这表明我们已经有效地饱和了 EBS 设备。

如果您的持久性要求很严格，那么为更快的磁盘支付更多费用是值得的。此外，您可以通过附加多个 EBS 卷来提高存储的吞吐量，但此基准测试中未对此方法进行测试。提高 Redis 设置的每秒事务数 (TPS) 分数的另一种方法是将持久性委托给从实例，从而释放主实例以进行实际的数据处理。但是请注意，复制可能会增加网络的负载并可能降低数据库的一致性。

其他发现

我使用了 Linux 的 iostats 来监控基准测试运行期间每种存储配置的写入吞吐量。每次运行结束后，我还触发了一个手动快照（SAVE 命令）并监控了它的写入吞吐量。以下是结果

分析

1. 在高吞吐量 EBS 设备上，AOF 的速度大约是快照的两倍。这可以用以下事实来解释：默认情况下，快照进程会对它创建的 RDB 文件执行即时压缩，这会延迟 I/O 写入吞吐量。EBS 卷的性能越高（即 SSD），吞吐量比率对 AOF 活动越有利，因为瓶颈从 EBS 访问转移到 CPU。
2. 值得注意的是，虽然 SSD PIOPS 的写入吞吐量是磁性磁盘的 x4.5（96.2MB/秒 vs 21.3MB/秒），但最终的 memtier_benchmark 结果只快了 x2（10484 次写入/秒 vs. 5214 次写入/秒），这有点令人费解。这可以用文件系统缓存以及 Salvatore 在 这篇文章中提供的评论来解释。

结论

尽管 SSD 存储针对随机访问而非仅追加写入模式进行了优化（后者是 Redis 的操作模式），但我们惊喜地发现，对于我们的目的来说，它实际上比磁性磁盘性能更高。此外，AWS 的 SSD PIOPS 确实比常规 SSD 产品提供更好的吞吐量。AWS 团队应该为此出色的服务产品而受到赞扬，我们的建议是：如果您在 EC2 上运行 Redis 并且需要数据持久性，那么您在 PIOPS SSD EBS 卷上花的钱是值得的。