在DynamoDB中存储审计日志与变更历史的最优方案是什么？

主表主键设计（适配90%核心查询场景） #

• 分区键（Partition Key）：srcTable#srcId（将srcTable与srcId用分隔符拼接为组合键）
• 排序键（Sort Key）：changedAt（使用毫秒级时间戳，保证相同业务记录的多次变更不会出现主键冲突）
  这种设计完全匹配占比最高的「指定srcId/srcTable查询变更列表」需求：查询时直接指定分区键为${srcTable}#${srcId}，可直接拉取该业务记录的所有变更，还可通过排序键的范围过滤实现按时间段查询、按时间正/倒序排列的需求，性能达到DynamoDB最优的O(1)级，同时解决了你提到的相同srcId/srcTable组合存在多条变更的主键冲突问题。

全局二级索引（GSI）设计，覆盖剩余低频查询 #

GSI1（适配5%~7%的单表全量变更查询） #

• 索引分区键：srcTable（独立存储的原始字段，不要从主分区键中解析）
• 索引排序键：changedAt
  查询时直接指定该索引的分区键为目标表名，即可拉取整张表的所有变更记录，支持按时间维度过滤排序。

GSI2（适配3%~5%的用户维度变更查询） #

• 索引分区键：user（存储操作人ID的独立字段）
• 索引排序键：changedAt
  查询时指定索引分区键为目标用户ID，即可拉取该用户触发的所有变更记录。

可选优化建议 #

• 若存在单业务表变更量极大（单日超百万条）的场景，可将GSI1的分区键调整为srcTable#日期的组合形式，避免单分区过热，查询时按日期聚合即可
• 写入时如果担心同一业务记录同一毫秒发生多次变更导致主键冲突，可在changedAt后追加1~2位随机数作为排序键后缀，不影响正常排序查询

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