如何将DynamoDB事件源批量大小降至5MB？Lambda传CloudSearch遇瓶颈

1. Lambda内部分拆批次（最直接有效） #

拿到DynamoDB Stream的事件后，不要直接整批发往CloudSearch，而是在Lambda内部做拆分处理：

• 遍历每条记录，将其转换为CloudSearch要求的文档格式（比如补充type、id等字段）
• 实时累加已选文档的序列化后字节大小（要按最终上传的JSON格式计算，不能用DynamoDB原始记录大小）
• 当累加大小接近5MB时（建议留100KB左右冗余，避免序列化后溢出），将当前子批次发送给CloudSearch，重置累加器后继续处理剩余记录
• 最后把未凑满批次的剩余记录单独发送一次

这种方式无需依赖外部存储，逻辑简单，能保证所有记录被正常处理，不会出现数据丢失。

2. 优化DynamoDB Stream的批量记录数，降低超标概率 #

虽然DynamoDB Stream的批量设置仅支持按记录数限制，但可以通过估算单条记录的平均大小，反向推导合适的记录数上限：
比如假设每条记录转成CloudSearch文档后平均为1KB，就把批量记录数设为4800（4800*1KB=4.8MB），留200KB冗余空间。这样大部分批次的总大小会控制在5MB以内，仅极少数包含大记录的批次会超标，再用上面的拆分逻辑兜底即可。

3. 处理单条超大记录的极端情况 #

如果存在单条记录转成文档后就超过5MB的情况，CloudSearch单文档上传也会失败，需要单独处理：

• 将大文档拆分为多个子文档（比如按内容分段，给每个子文档添加唯一ID和关联标识）
• 或者将大文档存储到S3，在CloudSearch文档中仅保留S3链接和摘要信息，根据业务需求调整展示逻辑

是否需要处理这个问题？ #

必须处理。如果直接上传超过5MB的批次到CloudSearch，会触发API错误返回，导致该批次记录同步失败，长期下来会造成DynamoDB与CloudSearch的数据不一致。

内容的提问来源于stack exchange，提问作者Edgar Carrillo