DynamoDB单表设计：基于细粒度问题数据实现QuestionGroup列表方案咨询

当前模型 #

我们目前采用细粒度存储，每条数据对应单个问题的响应，结构如下：

PK = <questionId>
SK = <actorId>
Type = Response
Value = <value>

这种设计能很好支持基于问题ID或参与者ID的查询需求。

新需求 #

现在需要开发一个列表API，返回的每一行对应一个QuestionGroup（更高层级的逻辑实体）：

• QuestionGroup是包含所有关联问题及响应的完整逻辑单元
• 可关联状态、时间戳、备注等工作流字段
• API要求：
  • 每个QuestionGroup仅返回一行数据
  • 稳定、可预测地返回所有QuestionGroup
  • 禁止使用扫描操作，必须保证查询性能可控

解决方案与权衡点 #

下面分享几种DynamoDB单表设计中适配这类需求的常用方案，以及各自的取舍：

方案1：反规范化聚合条目+全局二级索引（GSI） #

做法

1. 新增QuestionGroup聚合条目：在单表中添加专门存储QuestionGroup元数据的条目，设计为：

PK = ALL_GROUPS
SK = GROUP#<groupId>
Type = QuestionGroup
Status = <状态值>
Timestamp = <创建/更新时间戳>
Notes = <备注信息>
GroupId = <groupId>

2. 改造原有响应条目：给每条Response添加GroupId属性，并创建一个GSI，配置：
   • GSI分区键（GSI1PK）：GROUP#<GroupId>
   • GSI排序键（GSI1SK）：QUESTION#<questionId>
     改造后的Response条目结构：

PK = <questionId>
SK = <actorId>
Type = Response
Value = <value>
GroupId = <groupId>
GSI1PK = GROUP#<groupId>
GSI1SK = QUESTION#<questionId>

3. 查询逻辑：
   • 列表查询：直接对主表执行Query，条件为PK = 'ALL_GROUPS'，并通过SK前缀GROUP#过滤，可稳定分页，性能可控。
   • 获取单个Group的完整数据：先通过主表Query拿到Group元数据，再通过GSI执行Query（GSI1PK = 'GROUP#<groupId>'）获取所有关联响应。

权衡点

• 优势：完全符合API要求，列表查询性能稳定；原有基于问题/参与者的查询不受影响；单个Group的元数据和响应可通过两次高效Query获取。
• 劣势：存在数据冗余，写入时需同时维护聚合条目和响应条目，增加写入成本；需通过DynamoDB事务保证数据一致性；若Group关联的响应过多，聚合条目里无法存储完整响应列表（受限于单条目400KB上限），只能存摘要或分开查询。

方案2：复合排序键的层级结构设计 #

做法

重新设计主表的PK和SK，构建以QuestionGroup为顶层的层级结构：

// QuestionGroup元数据条目
PK = GROUP#<groupId>
SK = GROUP_METADATA
Type = QuestionGroup
Status = <状态值>
Timestamp = <时间戳>
Notes = <备注>

// 问题基础信息条目（若需存储问题本身）
PK = GROUP#<groupId>
SK = QUESTION#<questionId>
Type = Question
QuestionText = <问题内容>

// 响应条目
PK = GROUP#<groupId>
SK = RESPONSE#<questionId>#<actorId>
Type = Response
Value = <value>

同时创建一个GSI用于列表查询：

• GSI分区键：ALL_GROUPS
• GSI排序键：GROUP#<groupId>
  将所有QuestionGroup元数据条目同步到该GSI中。

权衡点

• 优势：数据层级清晰，查询单个Group的所有关联数据（元数据、问题、响应）只需一次Query（PK = 'GROUP#<groupId>'，SK范围覆盖所有前缀），效率极高；
• 劣势：原有基于问题ID/参与者ID的查询需要额外创建GSI支持，增加存储和写入成本；需迁移现有数据，重构成本较高。

方案3：基于DynamoDB Streams的物化视图 #

做法

利用DynamoDB Streams和Lambda异步构建QuestionGroup的聚合视图：

1. 给原有Response条目添加GroupId属性，无需修改原有写入逻辑；
2. 配置DynamoDB Streams捕获Response的写入/更新事件，触发Lambda函数；
3. Lambda函数异步更新对应的QuestionGroup聚合条目，维护元数据和响应摘要（或完整列表），聚合条目设计同方案1；
4. 列表查询直接通过主表Query（PK = 'ALL_GROUPS'）获取所有Group。

权衡点

• 优势：无需修改原有写入流程，原有访问模式完全保留；聚合视图异步构建，不影响写入性能；
• 劣势：存在数据延迟（Lambda处理通常有几秒到数分钟延迟），不适合强一致性场景；需维护Streams和Lambda的配置，增加运维复杂度；同样受限于单条目400KB上限，响应过多时需做数据拆分。

选择建议 #

• 若要求强一致性、且能接受写入时的额外开销，优先选方案1；
• 若正在重构表结构、希望数据层级更清晰，优先选方案2；
• 若原有写入逻辑无法修改、且能接受数据延迟，选方案3。

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