一个表的10个项目的batchGet((与#of tables项目5000、10000、20000、40000、80000是否有任何差异？还是不管桌子大小，它都应该是恒定的？
Dynamo有潜力扩展到您需要的任何级别，但要确保它能够扩展，您必须考虑几个因素。值得庆幸的是，它们很容易掌握，但如果在餐桌设计阶段没有完全理解，你可能会遇到问题。
读/写容量分为读容量单元(RCU(和写容量单元(WCU(。这些仅仅意味着你每秒可以发送多少数据。除了1xRCU是2KB或4KB取决于请求类型，1xWCU是1KB之外，两者的想法是相同的。换句话说，它们的价格不同。
因此，如果你必须阅读10个项目，每个项目都是8KB，那么最终一致的阅读需要20个RCU。
第一个陷阱是您提供的表格中没有足够的RCU。这不太可能发生，因为DDB引入了"；"按需"；表是几年前的默认值，它会自动为您增加这些容量，但您仍然可以用1个RCU来配置已配置的表，因此您需要检查您正在使用的内容。
然后是容量的第二个限制；分区。项目基于组合主键存储在一个或多个分区中。映射到特定分区的不是密钥本身，而是密钥的散列。你不需要管理任何关于分区的东西，但你需要确保你使用的键将你的项目均匀地映射到哈希函数映射到的分区。分区是DDB如此高效的原因，但每个分区只能有3000个RCU。值得庆幸的是，DDB会根据需要为您创建更多的项目，但同样，您需要确保主键将项目均匀地分布在分区中。这是通过提供高基数键来实现的，您应该阅读完整的解释。
最后，Dynamodb中的项目大小可以达到400KB。事务读取成本为每2KB 1xRCU。因此，对一个全尺寸项目的事务读取将花费200个RCU。如果您的分区键选择不好，并且有一个热分区，那么在DDB返回容量错误之前，您的最大值为(3000/200(=15个项目。
总之，Dynamodb将为您处理所有扩展的艰苦工作，但如果您的分区键不好，那么随着项目数量的增长，您可能有一天会得到一个令人讨厌的惊喜。
无论表大小或项计数如何，您都应该期望相当一致的延迟。这是DynamoDB核心设计的一部分。
有贯穿始终的限制，有充分的记录，但在这些限制中，您可以看到相当稳定的性能和延迟。