如何确定DynamoDB Scan/Query的最优页面大小？

核心权衡点 #

• 读取负载分散 vs 总耗时：更小的页面大小会将读取操作分散到更长周期，避免短时间内读取量激增，不会挤占表的吞吐量资源（尤其适用于多业务共享的表），但总耗时会上升——因为每次请求存在网络往返开销，页面越小，请求次数越多，累计延迟越高。
• 资源占用与业务影响：接近1MB的大页面单次请求会消耗更多读取容量单位（RCU），如果表承载其他核心业务流量，可能导致其他请求延迟升高；小页面每次消耗RCU更少，对其他业务的干扰更小，但总RCU消耗和大页面基本持平（毕竟最终要读取全量数据，总数据量对应的RCU是固定的，除非有过滤条件）。
• 客户端内存压力：大页面单次返回的数据量更大，客户端需要一次性处理更多数据，内存占用更高；小页面则能降低内存压力，适合Lambda这类资源受限的客户端环境。

极端场景：页面大小设为1条数据是否合理？ #

如果完全不介意耗时，理论上可以这么设置，但并不推荐。因为每次请求的网络往返、服务端固定处理开销会被大幅放大，导致总耗时急剧增加，同时会产生大量API请求，虽然DynamoDB的API限额较高，但极端场景下仍可能触发调用频率限制。更合理的做法是结合业务可接受的耗时、表的吞吐量情况，选择一个平衡值（比如100-1000条，具体取决于单条数据的大小）。

全量扫描时页面大小的实际影响 #

即便最终目标是获取所有数据，页面大小依然会带来以下影响：

• 对表业务的冲击程度：大页面会在短时间内消耗大量RCU，可能导致表的吞吐量被占满，影响其他读写操作；小页面则平稳消耗资源，对业务的干扰更小。
• 客户端处理效率：大页面适合客户端能高效批量处理数据的场景，减少循环迭代次数；小页面适合逐批处理、内存有限的场景。
• 故障恢复成本：如果扫描过程中出现中断，小页面场景下从LastEvaluatedKey恢复时，需要重新获取的数据量更少，恢复速度更快；大页面则可能需要重新读取更多数据，恢复成本更高。

内容的提问来源于stack exchange，提问作者Scott Thiessen