DynamoDB多态用户事件数据Schema设计咨询（含ORDER特殊场景）

适配性结论 #

DynamoDB完全适配你的场景，不管是常规的用户事件查询，还是ORDER类型事件的多字段排序需求，都能通过合理的表结构和索引设计实现。优先推荐单表设计，若ORDER事件量级极大且多字段排序查询频率极高，可考虑双表拆分，但单表方案在性能和维护成本上更有优势。

单表设计方案 #

主表结构 #

{
  "PK": "USER#<userID>",          // 分区键：统一前缀+用户ID，方便后续扩展其他用户相关数据
  "SK": "EVENT#<createdAt>",      // 排序键：前缀+毫秒级时间戳，满足按时间排序的核心需求
  "eventType": "<eventType>",     // 事件类型枚举，如"ORDER"、"CLICK"等
  "createdAt": 1699999999999,     // 冗余存储时间戳，方便过滤和索引
  "data": { ... },                // 事件原始数据，ORDER类型包含field1~field20等专属字段
  // 可选：将ORDER事件的专属字段提取为顶级属性（如field1、field2），方便索引投影
  "field1": "<order_field1_value>",
  "field2": "<order_field2_value>"
}

索引设计 #

1. 常规查询优化

针对「获取某用户特定类型事件」的需求，创建全局二级索引（GSI）：

• GSI名称：GSI_User_EventType
• GSI分区键（PK）：PK（与主表一致）
• GSI排序键（SK）：TYPE#<eventType>#<createdAt>
• 投影类型：INCLUDE（指定eventType、createdAt、data及ORDER专属字段）

查询方式：通过Query操作指定GSI，条件为PK = USER#<userID>且SK BEGINS_WITH('TYPE#ORDER#')，直接按时间排序返回结果，避免主表过滤的性能损耗。

2. 特殊场景（ORDER事件多字段排序）

由于DynamoDB单表最多支持5个GSI，需结合高频/低频查询场景区分处理：

• 高频排序字段：为每个高频字段单独创建GSI，例如针对field1：
  • GSI名称：GSI_User_Order_Field1
  • GSI分区键（PK）：PK
  • GSI排序键（SK）：FIELD1#<field1_value>#<createdAt>
  • 查询方式：Query该GSI，条件PK = USER#<userID>，结果将按field1_value排序，相同值的事件按时间戳二次排序。
• 低频排序字段：利用GSI_User_EventType获取该用户所有ORDER事件，在客户端对返回结果按目标字段排序。此方案无需额外索引，适合查询频率低、数据量不大的场景。

双表拆分方案（可选） #

若ORDER事件量级极大（如单用户超10万条）且多字段排序查询极频繁，可拆分出独立的ORDER表：

ORDER表结构 #

{
  "PK": "USER#<userID>",
  "SK": "ORDER#<createdAt>",
  "eventType": "ORDER",
  "createdAt": 1699999999999,
  "data": { ... },
  "field1": "<value>",
  "field2": "<value>",
  ...,
  "field20": "<value>"
}

索引设计 #

为ORDER表的高频排序字段创建GSI（最多5个），逻辑与单表方案一致；低频字段仍用客户端排序处理。主表保留所有事件数据，满足常规查询需求。

关键注意事项 #

• 时间戳建议用毫秒级Unix时间戳，确保排序精度和区间查询的准确性。
• 排序键中追加时间戳，避免相同字段值的事件出现排序混乱。
• GSI投影类型优先选INCLUDE，只投影需要的字段，减少存储成本和索引同步开销。

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