基于Firebase的群组电影推荐系统架构优化咨询

问题拆解 #

当前方案每次用户进入活动都要全量拉取Votables，再和MemberVotes里的已看电影做对比，重复计算太多，既费资源又影响体验，得从数据结构和查询逻辑上调整，同时满足「优先推已展示过的电影」「不重复推给同一用户」这两个核心约束。

数据结构优化 #

1. 给Votables新增「已展示用户」字段 #

在每个Votables的电影文档里，添加exposedTo数组字段，专门存储已经看过这部电影的用户ID：

• 用户进入活动时，直接查询Votables中exposedTo不包含自身ID、且exposedTo长度>0的电影（即已推给过其他成员的内容），优先展示这类电影。
• 只要给用户展示过某部电影，立刻将用户ID加入exposedTo数组，从根源上避免重复推荐。

2. 拆分Votables为两个子集合 #

把原有的Votables拆分成两个独立子集合：

• SharedVotables：存储已经推给过至少两名成员的电影，专门用于优先推荐，贴合「避免无共同喜好」的需求。
• NewVotables：存储从API拉取的新电影，仅推给单个用户；当这部电影被推给第二个用户时，直接将其从NewVotables迁移到SharedVotables。
  这样用户进入活动时，先查询SharedVotables中未看过的内容，无结果再查NewVotables，大幅缩小查询范围。

3. 给MemberVotes新增「已看电影列表」 #

在MemberVotes的用户文档里，新增exposedMovies数组，记录该用户所有看过的电影ID（无论喜欢还是跳过）：

• 查询推荐内容时，直接筛选Votables中movieID不在exposedMovies里的内容，无需全量对比。
• 用户每看一部电影，先将电影ID存入exposedMovies；若选择喜欢，再同步加入likedMovies数组。

业务流程调整 #

推荐流程 #

1. 用户进入活动，先查询SharedVotables（或带exposedTo长度>0的Votables）中不在自身exposedMovies的电影，按exposedTo长度倒序推荐（推给的人数越多，优先级越高）。
2. 若SharedVotables无未展示内容，从API拉取新电影存入NewVotables，展示给当前用户，同时更新该电影的exposedTo和用户的exposedMovies。
3. 当一部新电影推给第二个用户时，将其迁移到SharedVotables，后续优先推送给其他成员。

投票更新流程 #

用户点击「喜欢」时：

• 直接更新对应电影Votables文档中的投票用户列表，添加当前用户ID。
• 同步更新MemberVotes中该用户的likedMovies数组。
• 全程无需全量对比数据，因为展示逻辑已通过exposedTo和exposedMovies完成过滤。

性能优化细节 #

• 创建Firebase索引：给Votables.exposedTo、SharedVotables.exposedTo、MemberVotes.exposedMovies建立复合索引，提升查询速度。
• 使用批量写入：迁移电影集合时，采用Firebase批量操作，保证数据一致性。
• 按需拉取字段：查询时仅获取必要的电影信息（如ID、标题、海报），减少带宽消耗。

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