DynamoDB数据结构选型：嵌套字典还是多条目？

嘿，你的这个问题刚好戳中了DynamoDB设计里「明细存储」和「聚合存储」的经典权衡点，结合你用Python Lambda处理自动化测试数据的场景，我来给你捋捋两种方案的优劣，再给你个兼顾效率和灵活性的最优思路：

一、先说说你当前扁平结构的利与弊 #

你现在用testName（分区键）+testRunID（排序键）的扁平结构，这个主键设计其实是合理的，但统计需要全表扫描确实是硬伤——尤其是测试量上来后，全表扫描不仅慢，还会吃掉大量读容量单位（RCU），成本也跟着涨。不过扁平结构也有不可替代的优点：

• 写入简单：每次测试完成直接PutItem就行，不用先读旧数据再更新
• 历史数据安全：所有测试记录都是独立条目，不会因为更新统计值而覆盖或丢失历史
• 无体积顾虑：DynamoDB单条item上限400KB，扁平结构完全碰不到这个限制

二、嵌套结构的优势与潜在坑 #

你设想的嵌套结构把同testName的所有测试记录和统计值存在一个item里，确实能解决统计计算的效率问题，但要注意几个容易踩的坑：

优势 #

• 统计值实时可用：每次新增测试时，读取现有item、更新tests数组、重新计算stats再写回去，查询时直接拿现成的统计值，不用额外聚合
• 查询效率高：按testName查一次就能拿到所有历史数据和统计，不用做Query后再在内存里聚合

要警惕的问题 #

1. item体积膨胀：如果某个testName的测试次数特别多（比如上万次），tests数组会很快突破400KB的限制，直接导致写入失败
2. 并发写入冲突：如果同一个testName的多个测试同时完成，多个Lambda实例同时读取、更新、写入item，会出现乐观锁冲突——虽然能用ConditionCheck解决，但会增加代码复杂度
3. 历史数据查询灵活性差：如果以后需要按时间范围过滤测试记录，嵌套在数组里的话只能全量读取后在内存过滤，没法用DynamoDB的Query条件做高效筛选
4. 统计计算耗时：每次更新都要重新计算均值、标准差，数据量大时会拖慢Lambda执行时间，甚至触发超时

三、最优方案：混合模式（兼顾明细与聚合） #

既然两种结构各有优劣，咱们可以取其所长，设计一个「主表存明细 + 统计表存聚合」的混合模式：

1. 主表：存储单条测试记录（沿用你的扁平结构） #

主键还是testName（分区键）+testRunID（排序键），字段和你原来的一致：

{
  "testName": "login_flow_test",
  "result": "SUCCESS",
  "testEndedAt": 1699999999,
  "testStartedAt": 1699999900,
  "testRunID": "run_12345",
  "timeAdded": 1699999999,
  "totalTime": 99
}

这个表专门存所有历史测试数据，支持按testName查询全量记录，或者按testRunID精确查找，写入简单无冲突。

2. 统计维度表：存储实时统计指标 #

单独建一个表，主键是testName（唯一分区键），存储统计指标和元数据：

{
  "testName": "login_flow_test",
  "totalRuns": 150,
  "totalTimeSum": 14280,
  "totalTimeSquareSum": 1365000,
  "maxExpectedTime": 120,
  "lastUpdatedAt": 1699999999
}

这里我建议存储中间计算值而不是直接存均值、标准差，这样可以用DynamoDB的原子更新操作，避免并发冲突。需要均值和标准差时，查询后实时计算：

• 均值：mean = totalTimeSum / totalRuns
• 标准差：stDev = sqrt( (totalTimeSquareSum / totalRuns) - (mean)**2 )

3. Lambda执行流程优化 #

每次测试完成后，Lambda只需要做两步：

• 第一步：向主表调用PutItem，写入单条测试记录（无锁，高效）
• 第二步：向统计表调用UpdateItem，原子更新中间计算值：
  用UpdateExpression来增量更新总和、平方和、总次数、最大预期时间，比如：

  update_expression = """
    SET totalRuns = totalRuns + :inc,
        totalTimeSum = totalTimeSum + :time,
        totalTimeSquareSum = totalTimeSquareSum + :time_sq,
        maxExpectedTime = if_not_exists(maxExpectedTime, :time) if :time > maxExpectedTime else maxExpectedTime,
        lastUpdatedAt = :now
  """
  expression_attribute_values = {
      ":inc": 1,
      ":time": total_time,
      ":time_sq": total_time ** 2,
      ":now": int(time.time())
  }
  

  这种方式完全是原子操作，多个并发请求会按顺序执行更新，不会出现冲突。

四、额外的优化小技巧 #

• 批量写入：如果测试是批量生成的，用BatchWriteItem把多条测试记录打包写入主表，减少API调用次数，降低Lambda执行时间
• TTL自动清理：如果不需要永久保存所有测试记录，给主表的timeAdded字段设置TTL，自动删除旧数据，节省存储成本
• 全局二级索引（GSI）：如果需要按时间范围查询测试记录，给主表的timeAdded字段加一个GSI，用testName+timeAdded作为GSI主键，这样可以高效筛选某个时间段内的测试记录
• 缓存统计值：如果查询统计值的频率很高，把统计表的数据缓存到Redis（ElastiCache）里，减少DynamoDB的读请求，提高查询速度

总结 #

如果你的测试量不小，或者需要灵活查询历史数据，混合模式绝对是最优选择——主表存明细保证了写入效率和历史数据的完整性，统计表存聚合指标解决了统计计算的效率问题。如果你的测试量很小（每个testName的测试次数不会超过几千次），嵌套结构也可以用，但一定要注意并发冲突和item体积的问题。

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