基于AWS Amplify Datastore的交友App匹配数据库选型：单表vs关联表

需求背景 #

为类似Tinder的交友App设计数据库Schema，后端基于AWS Amplify Datastore，需支持以下核心查询：

• 获取用户参与的所有matches（匹配记录）
• 获取与特定用户存在匹配关系的所有users（用户）

现有方案分析 #

方案1：单表设计

• 设计思路：使用单表存储匹配记录，为user1_id和user2_id分别创建GSI（全局二级索引）
• 查询逻辑：由于用户可能作为user1_id或user2_id存在，需同时查询两个GSI来获取该用户的所有匹配记录，查询后可直接得到匹配用户列表和status状态
• 优势：合并两次GSI查询即可拿到完整所需数据，无需跨表关联，查询效率较高
• 劣势：需维护两个GSI，数据写入时存在额外索引开销；后续扩展匹配相关字段时，单表结构易出现冗余

方案2：关联表设计

• 设计思路：引入USERSMATCHES关联表，为表中user_id创建GSI，单独维护matches表存储匹配状态等核心信息
• 查询逻辑：
  1. 获取用户匹配记录：先查询USERSMATCHES的GSI拿到所有matches_id，再用这些ID查询matches表获取status
  2. 获取匹配用户列表：先得到matches_id列表，再逐个查询USERSMATCHES表获取对应的关联用户ID
• 优势：表结构职责清晰，matches表专注存储匹配核心信息，关联表专注维护用户与匹配的关系，扩展性较好
• 劣势：查询需多次跨表操作，尤其是获取匹配用户列表时的N次查询，会带来明显性能损耗，高并发场景下表现较差

推荐方案：优化后的单表设计 #

针对方案1的不足做优化，保留单表结构同时调整索引策略：

1. 将匹配记录设计为无向关系：规定user1_id始终存储ID较小的用户ID，user2_id存储ID较大的用户ID
2. 为user1_id和user2_id分别保留GSI，或创建一个复合GSI

这样查询时，仅需根据用户ID的大小选择查询对应的GSI（用户ID较小查user1_id的GSI，反之查user2_id的GSI），避免同时查询两个索引，减少查询次数和索引维护开销。这种设计既保留了单表查询的高效性，又降低了索引维护成本，完全满足两个核心查询需求。

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