DynamoDB表设计方案选择咨询：JSON模型VS顶级属性模型

业务需求回顾 #

• 追踪用户按分组归类的操作，操作随账户分组动态变化
• 用户可属于多个分组
• 核心查询需求：查询某账户的所有操作、查询某账户某分组的所有操作
• 初始数据量超200万条，单分组操作JSON大小不超过20KB

两种方案对比 #

Design-1：嵌套JSON存储（PK=accountid, SK=groupName） #

每条记录对应一个账户+分组的所有操作，用JSON字段存储操作状态：

accountid (PK)       groupName (SK)       json
1234567891023        groupName1234        { clicked: true, opened: true }

优势：

• 查询效率高：按分组查询时，一次GetItem或Query就能拿到该分组下所有操作，无需客户端聚合
• 存储成本低：合并同分组操作，条目数远少于扁平化方案，适合操作数量不多的场景
• 更新简便：新增/修改操作时，只需用UpdateExpression更新JSON内的特定字段，无需新增条目

劣势：

• 细粒度查询受限：无法直接通过DynamoDB查询过滤单个操作状态（比如仅查clicked），必须先获取整个JSON再解析
• 并发更新需注意：多个操作同时修改同一条JSON时，需用ConditionExpression处理版本冲突

Design-2：扁平化单操作存储（PK=accountid, SK=groupName#action） #

每条记录对应一个账户+分组+单个操作的状态（建议SK拼接groupName和action保证唯一性）：

accountid (PK)       groupName#action (SK)       status
1234567891023        groupName1234#clicked       true
1234567891023        groupName1234#opened        true

优势：

• 灵活性强：支持细粒度查询（比如直接查某账户某分组的clicked状态），便于后续扩展操作级别的统计
• 并发冲突低：新增操作只需PutItem，无需修改现有记录，减少冲突概率
• 数据原子性：单个操作状态独立，删除/修改单个操作更简单

劣势：

• 存储成本高：条目数是Design-1的N倍（N为单分组平均操作数），200万初始数据会大幅膨胀
• 查询聚合成本高：查询账户所有操作或分组操作时，需返回多条记录并在客户端聚合，性能略低于Design-1

方案选择建议 #

1. 优先选Design-1：如果核心场景是批量获取分组操作，且操作数量稳定（JSON不超20KB说明操作数有限），这种方案更高效、经济。
2. 选Design-2：如果未来需要频繁做单操作查询、操作数量会大幅增长，或者需要基于操作类型做统计分析，扁平化结构的扩展性更好。

补充优化点 #

• Design-1更新JSON时，避免直接覆盖整个字段，用SET json.clicked = :newVal这样的表达式修改特定属性
• Design-2可根据扩展需求添加GSI，比如PK=accountid, SK=action，支持按操作类型查询账户的所有相关记录

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