DDB分区键存储多值的方案咨询：JSON字符串利弊及缺失属性处理

我们需要将多个值关联为DynamoDB（DDB）记录的分区键，考虑将其存储为JSON字符串，示例数据如下：

这类账单记录分为分组和未分组两种：分组记录会关联对应的groupId；未分组记录则无groupId。

现有备选方案 #

1. 将isGrouped布尔值与groupId一同存入分区键，BillingRecordId格式示例：

   {"transactionId":"10509091","groupId":1,"isGrouped":true}
   {"transactionId":"10509091","groupId":null,"isGrouped":false}
   

2. 不使用JSON序列化字符串，根据是否分组创建拼接式分区键：

   10509091
   10509091.1
   

3. 将groupId设为可空字段，或存储为JSON列表[]，格式示例：

   {"transactionId":"10509091","groupId":null}
   {"transactionId":"10509091","groupId":[]}
   

技术问询解答 #

一、使用JSON字符串作为分区键的弊端 #

• 性能损耗：DDB的分区键会用于哈希计算分配存储节点，JSON字符串比紧凑的拼接格式或原始数据更长，哈希计算开销更大；查询时还需额外做序列化/反序列化操作，增加处理时间。
• 一致性风险：JSON序列化格式可能存在差异，比如键的顺序、空格不同，逻辑等价的JSON会被DDB判定为不同的分区键，导致数据分散或查询失败。
• 查询复杂度提升：无法直接基于分区键的部分属性查询（比如按transactionId批量获取所有关联记录），必须构造完整JSON字符串，或额外创建全局二级索引（GSI），增加成本和维护负担。
• 存储成本增加：JSON包含大量语法字符（如{}、引号），相比紧凑格式占用更多存储空间，长期会推高存储费用。

二、处理缺失属性的高层次方案 #

• 统一格式占位符：为未分组记录分配固定占位符（如0或UNGROUPED）作为groupId，让分区键统一为<transactionId>.<groupId>格式，避免因类型不同导致的结构差异。
• 拆分存储逻辑：将分组、未分组记录分别存入不同DDB表，或给分区键加前缀区分（如GROUP#<transactionId>.<groupId>和UNGROUP#<transactionId>），快速定位对应类型的记录，同时保持分区键结构简洁。
• 利用稀疏索引特性：主表分区键设为transactionId，创建以groupId为分区键的GSI。未分组记录不填充groupId，GSI中仅保留分组记录，既可以通过主表查询所有交易记录，也能通过GSI快速检索分组数据。
• DDB原生复合类型：若业务允许，使用DDB原生的Map类型作为分区键，DDB会保证其序列化一致性，避免自定义JSON的格式问题，但仍存在查询复杂度高的问题，仅适合查询灵活性要求低的场景。

内容的提问来源于stack exchange，提问作者saurabh.kg001