Firestore(NoSQL)是否适合社交类应用？点赞存储及未点赞帖子查询如何实现？

帖子总点赞数存储最优方案 #

直接用Firestore官方提供的分布式计数器方案即可，无需对接额外服务，实现逻辑如下：

• 为每个帖子创建计数器分片子集合，路径为 posts/{postID}/counterShards/，提前拆分N个分片文档（分片数量根据峰值点赞写入量决定，100个分片即可支撑每秒100次写入）
• 用户触发点赞/取消点赞操作时，随机选择一个分片文档，对其中的count字段执行原子增减操作
• 读取总点赞数时，批量查询所有分片的count值累加即可

如果要进一步优化读取性能，可以搭配Cloud Functions定时聚合分片计数，每隔数秒将聚合结果写入帖子主文档的totalLikes字段，普通查询场景直接读取主文档字段即可，无需每次遍历所有分片。

「查询当前用户未点赞帖子」实现方案 #

这个需求属于NoSQL典型的反向存在性查询场景，原生不支持直接查询，不是你对Firestore掌握不足，可选择以下生产环境常用的落地方案：

• 方案1（推荐，绝大多数场景适用）：分页拉取+客户端过滤
  每次分页拉取固定数量的帖子（比如单页20条），批量查询当前用户对这部分帖子的点赞状态，过滤掉已点赞的帖子，不足分页数量时继续拉下一页补充。用户单次刷Feed的浏览量有限，该过滤开销可忽略，无任何存储上限问题。
• 方案2（适合帖子发布量较低的场景）：用户未点赞池倒排索引
  新帖子发布时，写入所有活跃用户的unlikedPosts子集合，用户点赞对应帖子后，从自己的unlikedPosts子集合中删除该帖子记录，查询时直接读取该子集合即可。该方案实时性高，但帖子发布时的写入成本随活跃用户数线性增长，需要结合业务规模权衡。
• 方案3（适合非实时查询场景）：离线聚合查询
  将全量点赞关系同步到离线数仓，定期计算每个用户的未点赞帖子列表，写入对应用户文档供业务侧读取，该方案适合推荐召回等非实时场景，实时性要求高的Feed流不适用。

NoSQL是否适合开发社交应用 #

全球top级的社交产品绝大多数底层都采用NoSQL数据库，不存在不适合的问题。只是NoSQL的设计思路和关系型数据库完全不同：需要优先根据查询需求设计数据结构，允许适当的数据冗余，接受部分场景用轻量的端侧/服务侧计算弥补数据库查询能力的短板，不要用关系型数据库的表设计思路套用到NoSQL场景即可。

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