开发实时匿名投票平台应选用哪款Firebase数据库？

针对你提到的匿名用户句子点赞/点踩投票场景，结合你已经接入Firebase匿名Auth的前提，两种数据库的选型逻辑如下：

优先选择Firestore的情况 #

• 你未来有功能扩展计划：如果后续还要做用户投票历史查询、句子按热度筛选、句子标签分类等功能，Firestore的结构化查询能力、文档-子集合的层级结构能大幅降低开发成本。
• 防重复投票逻辑更简单：你可以直接在每个句子的文档下新建user_votes子集合，每条投票记录直接用匿名用户的uid作为文档ID，配合安全规则就能天然拦截重复投票，不需要额外做去重校验。
• 计数准确性更有保障：直接用Firestore内置的FieldValue.increment()原子增量操作，多用户同时投票时也不会出现计数偏差，不需要自己处理并发冲突。
• 小流量场景成本更低：Firestore按读写操作次数计费，投票这种单操作数据量极小的场景，在用户量不大的情况下成本会远低于Realtime Database按带宽/存储计费的模式。

优先选择Realtime Database的情况 #

• 你的功能非常单一，仅需要实时同步投票数：Realtime Database的实时同步延迟比Firestore更低，端侧拿到最新计数的速度更快。
• 单内容高并发投票：如果你的场景存在单条句子同时有数千甚至上万人投票的情况，Realtime Database的单节点并发承载能力更强，不容易出现请求限流。
• 全量投票监听需求更强：Realtime Database的树形结构对单节点监听的成本更低，只需要监听对应句子的计数字段就能实时拿到更新，不需要额外配置查询逻辑。

通用注意事项 #

不管你最终选择哪款数据库，都要做好两个基础配置：

• 配合安全规则限制写入权限：仅允许已经通过匿名Auth认证的用户提交投票请求，且单个uid对同一条句子只能提交一次投票。
• 计数操作必须使用官方提供的原子增量接口，不要在客户端计算计数后再提交，避免并发场景下的计数错误。

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