amazon-dynamodb - 尽管配置容量高，但DynamoDB Update/Put仍受限制

Question

我在DynamoDB表上的更新上看到了一些限制。我知道 throttle 是每秒工作的，有时可以吸收但不能保证超过配置容量的峰值。我知道应该平均分配负载，而我还没有这样做。

但请查看指标的1分钟平均图表；随附的。所使用的容量远低于所提供的容量。这些 throttle 从哪里来？因为所有的写都去了一个特定的分片？

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

Answer 1

DynamoDB建立在以下假设之上:要充分利用预配置的吞吐量，您的读取和写入操作必须在空间(哈希/范围键)和时间(并非全部都在同一秒)内均匀分布。

根据图上分配的吞吐量，您仍然最有可能使用一个分片，但是如果您先前已将吞吐量提高到当前水平以上并将其降低到现在的水平，则可能存在两个或更多分片。尽管这是要注意的事情，但可能不是直接导致这种节流行为的原因。如果表中有很多数据，超过10 GB，那么您肯定会有多个分片。这将意味着您的表中可能有很多冷数据，这可能是导致此问题的原因，但是可能性似乎较小。

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

由于您显示的节气门数量大约在10s到100s的数量级之间，因此不必担心。只要您使用的是官方的AWS开发工具包，它就会自动处理具有指数补偿的重试，以在完全放弃之前多次重试请求。

尽管在许多情况下很难控制对表的读写分布，但是值得对您的哈希/范围键设计进行另一番研究，以确保它真的适合您对表的读写模式。此外，对于读取，您可以通过Memcached或Redis进行缓存，即使缓存在几分钟或几秒钟内过期也可以帮助减少热键的影响。对于写操作，您需要查看应用程序中的逻辑，以确保没有执行任何可能导致此问题的不必要写操作。

最后一点与批处理写入有关:DynamoDB中的批处理操作不会减少读取的消耗量或写入不同的子请求所消耗的消耗量，它只是减少了发出多个HTTP请求的开销。尽管批处理请求通常有助于提高吞吐量，但它们对减少DynamoDB中限制的可能性没有用。