Dynamodb 读写单元答案

【问题标题】：Dynamodb reading and writing unitsDynamodb 读写单元
【发布时间】：2014-01-08 15:14:19
【问题描述】：

我一直在阅读有关 Amazon DynamoDB 的各种文章，但对于如何使用这些读/写单元，我仍然有些困惑。例如，使用免费版本，我每秒有 5 个写入单元和 10 个读取单元可用，每个单元代表 1kb 的数据。但这究竟意味着什么？

这是否意味着每秒最多可以执行 10 个读取请求或每秒最多可以请求 10kb 的数据（无论是 10 还是 100 请求）？因为这方面对我来说不是很清楚。因此，如果我有 20 个用户同时访问我网站上的一个页面（这导致执行 20 个查询来检索数据），会发生什么？他们中的 10 个会立即看到数据，而另外 10 个会在 1 秒后看到数据吗？或者如果请求的数据（乘以 20）小于 10kb，他们会立即看到数据吗？

另外，如果读取单元不够，100个用户同时请求每个1kb的数据，是不是意味着所有的请求都需要10秒才能完成？？

另外，定价有点令人困惑，因为我不明白这些价格是为保留或消耗的单位支付的？例如，他们说价格是“写入吞吐量：每 10 个写入容量单位每小时 0.00735 美元”。这是否意味着即使在一天中没有提出任何写作请求，人们也会支付 ($0.00735*24=$0.176)？

【问题讨论】：

标签： amazon-dynamodb

【解决方案1】：

您是正确的，因为容量与正在读取/写入的对象的大小紧密相关。

2016 年 2 月更新

AWS 更新了他们计算吞吐量的方式，并将其计算的对象从 1 KB 增加到 4 KB。下面的讨论仍然有效，但某些计算现在不同了。

请始终查阅最新的 DynamoDB 文档，以获取有关如何计算吞吐量的最新信息和示例。

旧文档

来自 AWS DynamoDB 文档（截至 2014 年 1 月 8 日）：

写入所需的容量单位 = 每次写入的项目数第二个 x 项目大小（四舍五入到最接近的 KB）

读取所需的容量单位* = 每次读取的项目数第二个 x 项目大小（四舍五入到最接近的 KB）

如果您使用最终一致性读取，就每秒读取而言，您将获得两倍的吞吐量。

根据您的示例问题，如果您想每秒读取 10KB 的数据，则需要配置 10 个读取单元。无论是对 1 KB 数据发出 10 次请求，还是对 10 KB 数据发出单个请求，都没有关系。您被限制为 10KB/秒。

请注意，所需的读取容量单位数已确定通过每秒读取的项目数，而不是 API 的数量来电。例如，如果您需要每秒从您的表，如果你的项目是 1KB 或更少，那么你需要 500 个单位读取容量。 500个单独的GetItem没关系调用或 50 个 BatchGetItem 调用，每个调用返回 10 个项目。

对于您的 20 个用户示例，请注意数据会四舍五入到最接近的 KB。因此，即使您的 20 个用户请求 0.5 KB 的数据，您也需要 20 个读取单元来同时为所有用户提供服务。如果您只有 10 个读取单元，那么其他 10 个请求将被限制。如果您使用 Amazon DynamoDB 库，它们具有自动重试逻辑以再次尝试请求，因此它们最终应该得到服务。

对于您关于 100 个用户的问题，其中一些请求可能只是被限制并且重试逻辑最终可能会失败（代码只会在停止尝试之前重试请求多次） - 所以您需要准备好处理来自 DynamoDB 的 400 个响应代码并做出相应反应。 在使用 DynamoDB 时监控您的应用程序并确保您不会在应用程序关键事务上受到限制，这一点非常重要。

关于定价的最后一个问题 - 您按小时支付预订费用。如果您保留了 1000 个读取单元，而您的网站完全没有流量，那太糟糕了，您仍然需要为这 1000 个读取单元按小时付费。

为了完整性 - 请记住，吞吐量是按表提供的。因此，如果您有 3 个 DynamoDB 表：用户、照片、朋友，那么您必须为每个表配置容量，并且您需要确定适合每个表的容量。在这个简单的示例中，可能在您的应用程序中访问照片的频率较低，因此与您的用户表相比，您可以提供更低的吞吐量。

最终一致的读取非常适合节省成本，但您的应用必须设计为能够处理它。最终一致读取意味着如果您更新数据并立即尝试读取新值，您可能无法取回新值，它可能仍会返回之前的值。最终，如果有足够的时间，您将获得新的价值。由于不能保证读取最新数据，因此您支付的费用更少 - 但如果您设计得当，那是可以的。

【讨论】：

仍然不清楚请求数限制。 Aurel 在他的回答中说请求的数量不相关，但您说数据四舍五入到最接近的 kb。所以我假设读取单元将始终支持最多 1 个请求是正确的。因为如果请求仅返回一个带有小字符串的项目（与大小无关），则数据将四舍五入为 1 kb，因此它将消耗 1 个读取单元。对吗？
是的，这是正确的 - 1 个读取单元只会让您获得 1 个项目。如果您使用最终一致的读取，则可以加倍。
您说过，如果我们得到 500 个单独的 GetItem 调用或 50 个 BatchGetItem 调用（每个调用返回 10 个项目），这并不重要。但是根据这个文档docs.aws.amazon.com/amazondynamodb/latest/developerguide/… 据说如果我们使用 Query 它只需要考虑已处理项目的累积大小
@user7 这句话是从 2014 年 1 月 8 日的 AWS 文档中复制而来的。从那时起，他们进行了一些很棒的更新。
假设我有一个查询将获取 3000 条记录，每条记录为 1KB。所以累积大小为 3000 KB。吞吐量应该是 3000/4=750 吗？有必要这么高吗？我猜查询结果不会在一秒钟内被检索到，所以我们可以有一个较低的吞吐量。

【解决方案2】：

将其视为管道直径：您为每秒可能的数据吞吐量付费。请求的数量无关紧要。

此外，如果您要求 10 个读取单元，那么您确实会为 10 个单元付费，而不管您的实际流量如何。

如果您的流量超过限制，您首先会收到警告（假设达到您预置流量的 80%）。然后请求开始花费更多时间。如果您在很长一段时间内仍超出限制，则可能会在几分钟内拒绝新连接。

希望有帮助

【讨论】：

所以，如果我理解正确的话，如果你有一个间隔运行的作业，当该作业开始时它需要写入 100 条记录，然后它会再休眠 5 分钟，然后再次写入.您需要预置足够的写入容量来支持这种突发活动，它不是一天中的平均值。
你是对的。现在也许 aws 没有那么严格，所以它无论如何都可以用于小爆发。也许您还应该仔细检查规则，因为这是 2014 年编写的 :)

【解决方案3】：

• 添加和更新项目会消耗您的写入吞吐量，而请求/查询项目会消耗您在 dynamo db 中的读取吞吐量。 DynamoDB 表中单个项目的最大大小为 400 kb，项目越大，消耗的吞吐量越多，成本也会越高。如果您在 DynamoDB 中使用键进行搜索，则不会发生表扫描，并且您需要与项目大小相等的吞吐量，例如，如果您的项目大小为 4kb，那么您需要 1 个读取容量单位（1 个单位相当于 4KB/秒），如果您想每秒读取 40KB 的数据，则需要配置 10 个读取单元。无论您是对 4 KB 数据发出 10 次请求，还是对 40 KB 数据发出一次请求，都没有关系。您被限制为 40KB/秒。但是如果你在除了键之外进行搜索，那么 DynamoDB 会从表中扫描完整的数据，而当数据库中的数据很高时，扫描 db 会跨越预置的吞吐量限制，我们可以将表的吞吐量增加到扫描时所需的最大值，但这会增加成本，并且会使数据库大部分时间处于完全空闲状态。

【讨论】：

【解决方案4】：

请阅读这篇文章，所有细节都在那里：

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ProvisionedThroughput.html#ItemSizeCalculations.Reads

一般来说，您为每件商品付费，其中每件商品的大小四舍五入到下一个 1KB/4KB 以进行写入/读取操作。

此规则的唯一例外是当您执行查询/扫描调用时：

所有返回的项目都被视为单个读取操作，其中 DynamoDB 计算所有项目的总大小，然后向上舍入到下一个 4 KB 边界。如果查询返回 1500 项，每项 64 字节，则累积大小为 96 KB。

【讨论】：