我正在解决以按需模式配置的DynamoDB表的限制问题。我们有一个表看到平均负载非常低，峰值要大得多。在其中一些峰值期间，我们看到了限制错误。我从DynamoDB开发人员指南中看到，在30分钟的窗口后，峰值容量增加到前一个峰值的两倍。我们什么时候可以期待这个容量下降？在下图中，我看到24小时多一点的时间里，容量没有被~3.4K写入容量单位（WCU）限制，然后第二天容量被限制在小于该数量的范围内。
因此，我想了解的是，是否有任何规则或指导方针来管理容量从之前的高水位线下降的行为？这看起来在不到24小时内就会发生，但我想说得更准确一点。
当它为按需容量模式时，本身没有容量增加或减少。底层是分区，每个分区可以处理 3000 IOPS（读取是 1 IOPS，写入是 3 IOPS）。因此，您提到的文档部分所指的是 DynamoDB 试图在可用分区数量方面保持领先于您，这些分区数量可以支持您尝试执行的 IOPS 数量。您可以将该表“纵向扩展”到表之前支持的 IOPS 高水位线的两倍。让我们看一个具体的例子。处于按需容量模式的任何表都可以支持 12000 IOPS，这意味着它至少有 4 个分区。12，000 IOPS 是您可以“默认”支持的。接下来，您开始执行一些流量并达到 10，000 IOPS。DynamoDB 将看到这一点，做出反应并开始代表您添加分区。“嘿嘿，这张表快到最大了，我最好再加几个分区。”不过，这不是瞬间的。DynamoDB 会尝试保留足够的分区，以支持您达到峰值，达到之前的高水位线的两倍。我过于简化了它代表您所做的工作，但希望您能理解这个想法。
也就是说，如果您在屏幕截图中看到的数字是您使用过的最大容量(我们只看到大约一天的一部分)，那么您看到的节流可能是由容量以外的原因造成的。这可能是把热键。你有没有试着打开CloudWatch Contributor Insights一会儿，让它收集数据，看看它是否能确定是否有热键？这将是我的下一步。你不需要打开它很长时间，这需要钱，但是足够长的时间来获得一些关于正在发生的事情的真实数据。
如果您不熟悉热键，热键是一个术语，用于 DynamoDB 表中读取或写入多次的项目，以致：1/ 该项目单独达到每个分区的 IOPS 限制 （3000） 或 2/ 主要对该项目的请求，与分区中的其他项目相结合足以达到每个分区的 IOPS 限制。对于 #2，DynamoDB 会自动代表您将热门项目移动到现有较少使用的分区或新分区。根据表的配置，DynamoDB 在移动热项目以限制热分区方面或多或少会积极。如果热项目本身是麻烦制造者，DynamoDB 可能会尝试将其隔离在自己的分区中，但在某些时候它仍可能达到分区 IOPS 限制，从而导致限制。DynamoDB 采取此操作是一种被动措施，它将尽最大努力随着时间的推移为您缓解问题。最佳做法是通过设计密钥架构来避免这种情况，从而首先避免这种情况。
热键可能由于以下几个问题而出现：
