DynamoDB是否适用于大型事件日志表？架构迁移方案咨询

适合DynamoDB的日志表设计模式 #

1. 复合主键+全局二级索引（GSI） #

• 主键设计：用日志类型#时间戳做分区键（PK），用户ID/事件ID做排序键（SK）。这样既能按日志类型+时间范围快速检索，又能通过SK过滤特定用户或事件的日志。
• GSI适配多属性查询：针对高频查询维度创建GSI。比如常用“用户ID”查日志，就把GSI的分区键设为用户ID，排序键用时间戳，秒级拿到某用户的所有日志；如果需要“服务名称+状态”的组合查询，把这俩拼接成GSI分区键（比如payment-service#success），排序键仍用时间戳，完美覆盖这类场景。
• 注意：DynamoDB默认最多支持5个GSI，优先覆盖80%的高频查询，低频场景用其他方式补充。

2. 时间窗口分区 #

如果日志查询以时间范围为主，且数据有生命周期（比如只查近3个月），可以按天/小时做分区键（比如2024-05-20），排序键用时间戳#用户ID。这种模式下，单分区数据量可控，时间范围查询效率拉满，排序键里的附加属性还能支持额外过滤。

3. 稀疏索引处理低频查询 #

对不常用的查询维度（比如特定错误码），可以建稀疏GSI：只有包含该维度值的日志才会被索引。比如给错误码建GSI，只有报错的日志才进入索引，索引体积小，查询速度快。

别用全表扫描 #

DynamoDB全表扫描完全不适合5-10百万行的场景：

• 会占用大量读容量单位（RCU），挤爆其他业务的资源；
• 大表扫描耗时极长，根本满足不了实时查询需求；
• 数据越攒越多，后续成本和性能问题只会更严重。

什么时候该保留原RDS日志表？ #

如果你的日志查询毫无规律、极度灵活（比如经常任意组合N个属性过滤、做复杂聚合统计），或者需要和其他表做关联查询，那留着RDS更合适：

• SQL在复杂多维度过滤、分组统计、多表join上比DynamoDB灵活太多；
• 可以搞冷热分离：近期日志存DynamoDB满足快速查询，历史归档日志丢RDS或者S3+Athena，平衡性能和成本。

迁移小提示 #

• 数据迁移：先把历史数据导出到S3，再用DynamoDB批量导入工具同步；新增日志用CDC工具实时同步，确保数据一致性；
• 容量规划：提前根据查询量预估RCU和WCU，避免出现请求被限流；
• 先测后迁：迁移前模拟高频查询场景，验证DynamoDB的性能能不能达标。

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