在DynamoDB中将过期/非活跃数据存至单独表降本是否合理？

你的想法完全站得住脚，把活跃数据和归档/过期数据分开存储，确实能有效降低日常扫描、查询的成本，甚至还能提升主表的性能。下面我从几个维度拆解一下：

为什么分开存储更优？ #

• 直接降低主表的读写成本：DynamoDB的查询/扫描费用是按读取的数据量（RCU）计算的。主表只保留7天内的活跃数据，数据量小了，日常高频操作（比如用户查询最新数据、业务系统更新活跃记录）需要消耗的RCU会明显减少。同时，主表的全局二级索引（GSI）大小也会同步缩小，索引的维护成本和查询效率都会提升。
• 隔离访问模式，灵活配置资源：活跃数据和过期数据的访问频率天差地别——前者是高频读写，后者可能只是偶尔的审计、回溯查询。分开后，你可以给归档表配置更经济的资源策略：比如用按需模式代替主表的预留容量，或者设置极低的预留读写容量，进一步压缩成本；而且主表的性能不会被归档数据的偶尔访问拖慢。
• TTL+Lambda的实现路径成熟：你提到的用TTL自动标记删除过期数据，再通过Lambda同步到归档表的流程是可行的。更稳妥的做法是监听DynamoDB Streams（TTL删除事件会被Stream捕获），让Lambda处理Stream中的删除记录，这样能避免TTL直接触发的偶发性遗漏。记得给Lambda加重试机制和幂等性处理（比如归档表主键和主表一致，重复写入也不会破坏数据），防止数据丢失。

什么时候可以考虑不分开？ #

当然，也有不需要分开的场景：

• 如果你的总数据量极小，即使全部放在同一表，日常查询/扫描的成本可以忽略不计，那分开的收益就不大，反而增加了维护复杂度。
• 如果业务经常需要跨活跃/过期数据做联合查询（比如一次性查询用户近30天的所有数据），跨表查询会增加代码复杂度。这种情况如果数据量不大，暂时可以合并存储，用时间范围条件过滤；但如果数据量增长后，还是建议分开，再通过ETL工具定期聚合跨表数据，或者用DynamoDB PartiQL做跨表查询。

额外注意事项 #

• 归档表的设计要适配需求：归档表的主键建议和主表保持一致，方便后续快速回溯单条记录；如果不需要复杂查询，别创建多余的GSI，能省不少存储和索引成本。
• 极端低成本的归档选项：如果过期数据几乎不需要查询，还可以把归档表的数据定期导出到S3（用DynamoDB Export to S3功能），然后删除归档表中的数据，进一步降低长期存储成本——S3的存储费用比DynamoDB低很多，只是查询起来不如DynamoDB方便。

总的来说，只要你的业务符合“活跃数据高频访问、过期数据极少访问”的模式，这个拆分方案就是非常值得落地的优化手段。

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