我制作了一个包含1346个条目的表，每个条目的大小都小于4KB。我调配了1个读取容量单位，因此我预计平均每秒读取1个项目。然而，对所有1346个项目的简单扫描几乎立即返回。
我在这里缺少什么？
这可能归结为突发容量，即您在300秒内获得容量以用于突发操作（例如扫描整个表）。
这意味着，如果您使用了所有这些信用，其他交互将会受到影响，因为它们没有足够的可用容量。
您可以通过 CloudWatch 指标或在 DynamoDB 接口本身（通过指标选项卡）中查看使用的 WCU/RCU 量。
除了说“每个项目都小于4KB”之外，您不会给出条目的大小。少多少？
1个RCU将支持每秒2次最终一致读取敢达4KB的项目。
换言之，通过1个RCU和最终一致的读取，您可以每秒读取8KB的数据。
如果您的记录是 4KB，则您将获得 2 条记录/秒
1KB、8/秒
512B、16/秒
256B、32/秒
因此，已经提到的“突发”功能允许您使用55个RCU。但你的记录太小，55个RCU几乎可以“立即”返回数据
这里有两件事对您有利-一件是Scan操作所需的RCU比您认为的小物品少得多。另一个问题是“突发容量”。我将尝试解释这两个问题：
DynamoDB定价页面说“对于最大4 KB的项目，一个RCU每秒可以执行两个最终一致的读取请求。”这表明，即使项目大小为10字节，读取具有最终一致性的项目也需要花费一半的RCU。然而，尽管他们没有在任何地方说明这一点，但这种成本仅适用于检索单个项目的GetItem操作。在Scan或Query中，事实证明您不会为每个单独的项目单独付费。相反，这些操作按顺序扫描存储在磁盘上的数据，并且您为因此读取的数据量付费。如果您有1000个小项目并且DynamoDB必须从磁盘读取的总大小为80KB，您将支付80KB/4KB/2或10个RCU，而不是500个RCU。
这解释了为什么您读取了1346个项目，并且只测量了55个rcu，而不是1346/2 = 673。
对您有利的第二点是，DynamoDB具有“突发容量”功能，如下所述：
DynamoDB当前保留最多5分钟（300秒）的未使用读写容量。在偶尔爆发的读或写活动期间，这些额外的容量单位可以被快速消耗，甚至比您为表定义的每秒调配吞吐量容量还要快。
因此，如果您的数据库在您请求之前存在了5分钟，DynamoDB会为您保存300个RCU，您可以很快用完。由于300个RCU比您的扫描所需的要多得多（55），因此您的扫描发生得非常快，没有限制。
