我制作了一个包含1346个项目的表，每个项目的大小都小于4KB。我提供了1个读取容量单元，所以我希望平均每秒读取1个项目。然而，对所有1346个项目的简单扫描几乎立即返回。
我在这里错过了什么？
这可能是突发容量，即在300秒的时间内获得容量，用于突发操作(例如扫描整个表(。
这意味着，如果你使用了所有这些积分，其他交互将受到影响，因为它们没有足够的可用容量。
您可以通过CloudWatch度量或DynamoDB接口本身(通过度量选项卡(查看WCU/RCU的消耗量。
除了说"；每个项目小于4KB"；。少多少？
1个RCU将支持每秒对高达4KB的项目进行2次最终一致的读取。
换句话说，使用1个RCU并最终进行一致读取，每秒可以读取8KB的数据。
如果您的记录是4KB，那么您将获得2条记录/秒
1KB、8/秒
512B、16/秒
256B、32/秒
因此；"爆裂"；已经提到的功能允许您使用55 RCU。但是你的记录的小尺寸允许55 RCU返回数据"；几乎立即"；
这里有两件事对您有利——一是Scan操作占用的RCU比您认为的小项目要少得多。另一件事是"；突发容量"；。我将尝试解释两者：
DynamoDB定价页面上说"；对于大小不超过4KB的项目，一个RCU每秒可以执行两个最终一致的读取请求&"；。这表明，即使项目大小为10个字节，也要花费一半的RCU才能读取最终的一致性。然而，尽管他们没有在任何地方说明这一点，但对于检索单个项目的GetItem操作来说，这一成本仅为true。事实证明，在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，您可以很快用完这些RCU。由于300个RCU比您的扫描所需的要多得多(55(，因此您的扫描发生得非常快，没有节流。
执行查询时，RCU计数应用于读取的数据量，而不考虑读取的项目数。因此，如果您的项目很小，比如说每个项目只有几个字节，那么可以在单个4KB RCU中轻松查询它们。
这在从DynamoDB中读取许多项目时也特别有用。查询许多小项目比BatchGetting便宜得多，效率也高得多，这一点并不明显。