基于Firestore开发隐藏已浏览帖子的探索信息流的最优文档结构方案

你的初始方案最大的问题是新帖发布时的批量写入成本——给10k+用户逐一更新feed，不管日活高低，这种写入量都是不可持续的，而且完全没必要。以下是几个写入量更低的替代方案：

方案一：存储用户已浏览记录，而非预生成个人Feed #

核心思路是反向记录：不维护每个用户的待看feed，而是记录用户已经看过的帖子，查询时动态过滤已看内容。

• 数据结构设计：
  • 保留Posts集合存储所有帖子，Users集合存储用户基础信息。
  • 在用户文档中添加viewedPosts字段（用数组存储已浏览帖子ID），如果用户浏览量很大（比如超过几百条），改用用户文档下的ViewedPosts子集合，每个文档存单个帖子ID和浏览时间戳。
• 查询逻辑：
  • 当用户加载探索页时，从Posts集合中查询符合推荐规则（比如按热度、发布时间排序）的帖子，同时排除用户viewedPosts里的ID。
  • 若用子集合存储已浏览记录，先拉取用户所有已浏览的帖子ID列表，再在查询时用not-in过滤（注意Firestorenot-in最多支持10个值，若超过10个，可分批次查询或前端辅助过滤）。
• 写入量对比：新帖发布时无需任何写入操作，只有用户浏览帖子时，才给该用户的已浏览记录添加1条数据，写入量直接降到日活用户量级，大幅降低成本。

方案二：时间窗口+已浏览标记的混合策略 #

如果担心全量过滤帖子的查询效率，可以结合时间分片优化：

• 数据结构设计：
  • 将Posts按时间分片存储，比如按天创建子集合（如Posts_20240520），每个子集合存储当天发布的帖子。
  • 用户文档中记录已浏览的时间窗口和对应窗口内的帖子ID（比如viewedByWindow: { "20240520": ["post1", "post2"] }）。
• 查询逻辑：
  • 优先拉取最新时间窗口的帖子，过滤掉该窗口内用户已看的ID；当当前窗口无未读内容时，再拉取上一个时间窗口的内容。
• 优势：既减少了单次查询的数据范围，又降低了已浏览记录的存储复杂度，同时新帖发布时只需写入对应时间窗口的集合，无批量用户写入操作。

方案三：前端缓存+异步更新已浏览记录 #

为了进一步降低后端写入频率，可以结合前端缓存：

• 前端本地缓存用户已浏览的帖子ID（比如用LocalStorage或IndexedDB），每次加载新帖子时先在本地过滤已看内容。
• 后台异步批量更新用户的已浏览记录（比如用户退出APP或停留超过5分钟时，一次性同步本地缓存的已看ID到Firestore）。
• 补充：给Posts集合添加hotScore字段（综合点赞、评论、曝光等计算），查询时按hotScore降序排列，确保用户优先看到高热度的未读内容，提升体验。

总结 #

优先推荐方案一，实现成本最低，写入量优化最明显，完全适配你“总用户多但日活低”的场景。当用户浏览量增长到一定规模后，再逐步优化为子集合存储已浏览记录，或结合方案二的时间窗口策略提升查询效率。

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