Firebase存储帖子点赞选用Firestore还是Realtime Database的疑问

把点赞数据存储到Realtime Database（RTDB）是非常合理的选择，完全适配你当前的业务场景，具体原因和配套实现方案如下：

• 成本层面：Firestore按写入次数计费的规则确实不适合点赞、浏览计数这类高频轻量写入场景，每次点赞消耗1次写入配额的成本过高。而RTDB按存储容量和下行流量计费，单条点赞记录仅不到100字节，即使是百万级点赞量产生的存储成本也可以忽略，完全不会占用你Firestore的写入配额。
• 功能层面：RTDB天生支持毫秒级实时状态同步，用户点赞/取消点赞后可以立即在前端看到状态更新，体验比Firestore写入后再刷新的逻辑更好。

你可以继续保留帖子基础数据存在Firestore的设计，搭配RTDB存点赞数据，做好数据联动即可：

• RTDB存储点赞明细：设计数据结构为likes/{帖子ID}/{用户ID}，值存储布尔值true代表已点赞，删除对应节点代表取消点赞，既方便校验用户是否已点赞，也方便后续统计总点赞量。
• 点赞总数冗余存储：将单帖总点赞数存在Firestore对应帖子的文档中，不要每次点赞都触发更新，可以通过Cloud Functions配置聚合逻辑，每累计50次点赞操作或者每隔2分钟批量更新一次Firestore中的点赞总数，能把Firestore的写入消耗降到几乎可以忽略的水平。
• 权限规则配套：在RTDB安全规则中限制仅登录用户可修改自己对对应帖子的点赞节点，防止恶意刷赞。

如果你的业务后续规模进一步扩大，还可以给热点帖子的点赞数据加本地缓存，进一步降低RTDB的读取压力。

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