【问题标题】:AWS RDS Provisioned IOPS really worth it?AWS RDS 预置 IOPS 真的值得吗?
【发布时间】:2013-09-17 14:17:45
【问题描述】:

据我了解,RDS 预置 IOPS 与标准 I/O 速率相比相当昂贵。

在东京地区,P-IOPS 费率为 0.15 美元/GB,标准部署为 0.12 美元/IOP。 (Double the price for Multi-AZ deployment...)

对于 P-IOPS,所需的最小存储空间为 100GB,IOP 为 1000。 因此,不包括实例定价,P-IOPS 的起始成本为 135 美元。

就我而言,使用 P-IOPS 的成本大约是使用标准 I/O 速率的 100 倍。

这可能是一个非常主观的问题,但请给出一些意见。

在最优化 RDS P-IOPS 的数据库中,性能是否物有所值?

AWS site 提供了一些关于 P-IOPS 如何提高性能的见解。有没有实际的基准?

自我回答

除了 zeroSkillz 写的答案,我还做了一些研究。但是,请注意,我不是阅读数据库基准的专家。此外,基准和答案基于 EBS。

根据“Rodrigo Campos”写的an article,性能确实有显着提升。

从 1000 IOPS 到 2000 IOPS,读/写(包括随机读/写)性能翻倍。根据 zeroSkillz 的说法,标准 EBS 块提供大约 100 IOPS。想象一下当 100 IOPS 上升到 1000 IOPS(这是 P-IOPS 部署的最低 IOPS)时性能的提升。

结论

根据基准,性能/价格似乎合理。对于性能关键的情况,我想有些人或公司应该选择 P-IOPS,即使他们的收费是 100 倍以上。

但是,如果我是中小型企业的财务顾问,我会逐渐扩展我的 RDS 实例(如 CPU、内存),直到性能/价格与 P-IOPS 匹配。

【问题讨论】:

  • 请注意,亚马逊在提出此问题后引入了由 SSD 支持的 EBS。 SSD 支持的 EBS 的每个 OPS 成本显着降低,这使得证明 PIOP 的合理性变得更加困难。当然,PIOP 的最大性能为 4000 OPS,而不是 SSD 提供的 3000(或磁性提供的 40-200)。
  • 当然,亚马逊会间歇性地提高这些选项的性能上限。有关最新指标,请参阅 aws.amazon.com/ebs/details/#VolumeTypes

标签: performance amazon-web-services amazon-rds


【解决方案1】:

好的。这是一个不好的问题,因为它没有提到分配的存储大小或设置的任何其他细节。我们使用 RDS,它有其优点和缺点。首先,您不能将临时存储设备与 RDS 一起使用。使用 RDS 服务时,您甚至无法直接访问存储设备。

话虽如此 - RDS 的存储介质被假定基于亚马逊的 EBS 变体。标准 IOPS 的性能取决于卷的大小,并且有许多消息来源指出,超过 100GB 的存储它们开始“条带化”EBS 卷。这在读取和写入时提供了更好的平均案例数据访问。

我们目前运行大约 300GB 的存储分配,并且在几个小时的时间段内大约 85% 的时间可以获得 2k 写入 IOP 和 1k IOP。我们使用 datadog 来记录这个,所以我们可以实际看到。我们已经看到了高达 4k 写入 IOP 的爆发,但没有像这样持续。

我们从应用程序端看到的主要症状是如果写入的 IOPS 不够,则会出现锁争用。您在应用程序日志中获得这些的数量和频率将为您提供耗尽标准 RDS IOPS 的症状。您还可以使用 datadog 之类的服务来监控 IOPS。

预置 IOPS 的问题在于,它们假设写入/读取量处于稳定状态,以便具有成本效益。这几乎不是一个现实的用例,也是亚马逊启动云服务来修复的原因。使用 P-IOPS 获得的唯一保证是您将获得保留的最大吞吐量能力。如果不使用它,您仍然需要付费。

如果您可以运行副本,我们建议您将只读副本作为 NON-RDS 实例运行,并将其放在常规 EC2 实例上。通过自己管理副本,您可以以更便宜的价格获得更好的读取 IOPS。我们甚至使用 stunnel 在 AWS 之外设置副本,并将 SSD 驱动器作为主要块设备,我们的报告系统获得了惊人的读取速度——实际上比我们从 RDS 获得的速度快 100 倍。

我希望这有助于提供一些真实世界的细节。简而言之,在我看来 - 除非您必须始终确保(或在任何给定点)具有一定水平的吞吐量能力(或您的应用程序将失败),否则提供的 IOPS 有更好的替代方案,包括读写分离与读取-replicas memcache 等。

【讨论】:

  • 我们喜欢 RDS 的主要原因是多可用性故障转移自动化。我们通过 SSD 支持的只读从属设备和尽可能在应用层中的读写分离来弥补较差的 IOPS。
【解决方案2】:

所以,我刚和一位亚马逊系统工程师通了电话,他对这个问题有一些有趣的见解。 (即,这是第二手知识。)

标准 EBS 块可以很好地处理突发流量,但最终它会逐渐减少到大约 100 iops。这位工程师提出了几种替代方案。

  1. 一些客户使用多个小的 EBS 块并将它们条带化。这将提高 IOPS,并且是最具成本效益的。您无需担心镜像,因为 EBS 在幕后进行镜像。

  2. 一些客户在 EC2 实例上使用临时存储。 (或 RDS 实例)并有多个从站以“确保”耐用性。临时存储是本地存储,比 EBS 快得多。您甚至可以使用 SSD 预置的 EC2 实例。

  3. 一些客户会将主服务器配置为使用预配置的 IOPS 或 SSD 临时存储,然后将标准 EBS 存储用于从服务器。预期性能良好,但故障转移性能下降(但仍可用)

无论如何,如果您决定使用这些策略中的任何一个,我会与亚马逊重新核实,以确保我没有忘记任何重要步骤。正如我之前所说,这是第二手知识。

【讨论】:

  • 这是关于使用 RDS 还是通过 EC2 管理您自己的数据库?
  • 此评论试图回答预置 IOPS 与标准 EBS 块的问题,尽管一些更奇特的建议听起来像是针对 EC2 托管的 EBS 块。 (亚马逊工程师讨论的是 MongoDB 的解决方案,而不是 RDS 本身。)
猜你喜欢
  • 1970-01-01
  • 2014-10-26
  • 1970-01-01
  • 2016-04-18
  • 1970-01-01
  • 1970-01-01
  • 2017-09-15
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多