尽管预置容量很高，但 DynamoDB 更新/放置受到限制

Question

我发现我在 DynamoDB 表上的更新受到了一些限制。我知道节流阀每秒工作，有时可以吸收高于配置容量的峰值，但不能保证。我知道应该平均分配负载，我没有这样做。

但是请查看指标中的 1 分钟平均图表；随附的。使用的容量远低于预置容量。这些油门从哪里来？因为所有的写入都进入了一个特定的分片？

没有批量写入。工作负载分布是无法轻易控制的。

Answer 1

DynamoDB 建立在这样的假设之上：要充分发挥预置吞吐量的潜力，您的读取和写入必须在空间（哈希/范围键）和时间（并非所有都在完全相同的秒内进入）均匀分布。

根据图表上分配的吞吐量，您仍然很可能位于一个分片上，但如果您之前将吞吐量提高到当前水平以上并将其降低到当前水平，则可能存在两个或更多分片现在。虽然这是需要注意的事情，但它可能不是直接导致这种限制行为的原因。如果您的表中有很多数据，超过 10 GB，那么您肯定会有多个分片。这意味着您的表中可能有很多冷数据，这可能会导致此问题，但这似乎不太可能。

最可能的问题是您有一些热键。具体来说，您有一个或只有几条记录正在接收大量读取或写入请求，这会导致限制。本质上 DynamoDB 可以支持大量的 IOPS 写入和读取，但您不能将所有这些 IOPS 应用到几条记录上，它们需要在理想情况下均匀地分布在所有记录中。

由于您显示的油门数量在 10 到 100 的数量级之间，因此您不必担心。只要您使用的是官方 AWS 开发工具包，它就会自动使用指数退避重试请求，在完全放弃之前重试几次。

虽然在许多情况下很难控制对表的读取和写入分布，但可能值得重新审视一下您的哈希/范围键设计，以确保它真正适合您的读取和写入模式到桌子上。此外，对于读取，您可以通过 Memcached 或 Redis 使用缓存，即使缓存仅在几分钟或几秒钟内过期，以帮助减少热键的影响。对于写入，您需要查看应用程序中的逻辑，以确保没有执行任何可能导致此问题的不必要的写入。

最后一点与批量写入有关：DynamoDB 中的批量操作不会减少不同子请求所消耗的读取或写入的消耗量，它只是减少发出多个 HTTP 请求的开销。虽然批处理请求通常有助于提高吞吐量，但它们在降低 DynamoDB 中出现节流的可能性方面没有用处。