DynamoDB单表多用户共享场景下单查询返回关联对象全量详情

核心设计原则 #

DynamoDB本身没有SQL的join能力，想靠一次查询就拉全量，所有要返回的数据必须落在同一个分区键对应的条目集合里，不存在什么隐式关联能帮你跨分区拉数据。单辆车多用户共享的需求靠车辆维度下挂载多份关联关系就能实现，配合可控的条目副本同步，完全可以平衡读写成本，没必要搞复杂的多层GSI跳转。

表结构配置 #

主表键配置 #

• 分区键（PK）：支持两种前缀格式，分别承载两类数据聚合
  • USER#<userId>：用户维度聚合，查询用户全量数据时直接查该分区
  • CAR#<carId>：车辆维度聚合，作为车辆全量明细的数据源，供车辆维度的后台管理操作使用
• 排序键（SK）：统一格式为<层级1>#<层级2>#<资源ID>，保证同组数据按规则自然排序

全局二级索引配置 #

不需要保留原来的PK/SK反转索引，仅需保留1个车辆维度查询用GSI即可（满足按车辆查所有关联用户的需求）：

• GSI1分区键（GSI1PK）：CAR#<carId>
• GSI1排序键（GSI1SK）：和主表SK规则一致
  如果没有反向查询车辆关联用户的需求，甚至可以不建GSI，进一步降低存储成本。

条目示例 #

以用户9128、共享车辆1001为例，主表条目结构如下：

写入与同步规则 #

所有写操作统一用TransactWriteItems事务完成，保证数据一致性：

• 新增车辆：先写入CAR#<carId>分区下的全量车辆明细条目作为数据源，再给创建车辆的用户写入USER#<userId>分区下的对应车辆明细副本，同时写入双向关联关系条目。
• 添加共享用户：
  1. 先在CAR#<carId>分区下写入新的USER#<newUserId>#REL关联条目，标记对应权限
  2. 遍历CAR#<carId>分区下的所有明细条目，复制用户可见的字段到USER#<newUserId>分区下，SK按CAR#<carId>#<资源类型>#<资源ID>规则填充
• 更新车辆明细：先更新CAR#<carId>分区下的源条目，再查询CAR#<carId>下所有USER#*#REL的关联用户列表，批量更新每个USER#<userId>分区下对应的副本条目。
• 移除用户共享权限：直接删除CAR#<carId>下的USER#<userId>#REL关联条目，同时删除USER#<userId>分区下所有SK前缀为CAR#<carId>#的条目即可。

查询方式 #

仅需一次Query调用即可拿到指定用户的全量关联数据：

// 核心查询参数
TableName: 你的单表名
KeyConditionExpression: "PK = :userPk"
ExpressionAttributeValues: {
  ":userPk": "USER#9128"
}

返回结果可以直接按SK前缀做客户端组装，不需要额外请求：

• SK等于PROFILE：当前用户基础信息
• SK前缀为<carId>#REL：对应车辆的共享权限信息
• SK前缀为<carId>#META：对应车辆基础信息
• SK前缀为<carId>#ENGINE：对应车辆发动机明细
• SK前缀为<carId>#TIRE：对应车辆轮胎明细
• SK前缀为<carId>#OWNERSHIP：对应车辆权属信息
  由于SK按车辆ID排序，同一辆车的所有明细会连续返回，客户端解析成本极低。

方案权衡说明 #

• 多用户共享支持：车辆维度分区下可以挂载任意数量的用户关联条目，没有数量上限，天然支持单辆车多用户共享的需求。
• 成本说明：这个方案本质是用写的时候多复制几份数据，换读的时候一次拿全的低延迟和低读成本。按绝大多数资源共享场景的规模，单辆车关联用户不超100个、单车下明细条目不超1000条的话，总成本比你多次查询拼接数据要低得多；真遇到单车共享给上千人的极端场景，也可以灵活调整，只在用户分区存最常用的车辆核心字段，冷门的保养记录、历史权属这种数据留到用户点详情的时候再查就行，不用死磕全量副本。
• 一致性：所有写入走事务，不会出现用户看到车辆条目但看不到明细、权限回收后数据仍可见的不一致问题。

内容的提问来源于stack exchange，提问作者Peter Van Katwyk