Firestore：将所有集合设为users子集合是否为最佳实践？

你的理解是否正确？ #

是的，你的理解完全正确。Firestore中子集合属于独立集合，每个子集合的配额（包括写入速率限制）都是单独计算的。比如users/{userId}/books和users/{userId}/articles这类子集合，各自的写入速率限制遵循独立集合的规则（比如带顺序索引字段的集合每秒500次写入），不会与根集合或其他子集合共享配额。

该做法是否为最佳实践？ #

这要结合业务场景判断，不能一概而论：

适合采用的场景 #

• 数据访问逻辑天然和用户绑定：比如books是用户私有藏书、articles是用户发布的内容，大部分查询都是基于特定用户ID获取对应数据，这种结构贴合业务逻辑，查询效率更高。
• 存在单集合写入速率瓶颈：如果原根集合的写入量接近甚至超过单集合的速率限制，拆分为用户子集合后，每个子集合独立占用配额，能有效分散写入压力。

需要规避的情况 #

• 有大量跨用户的全局查询需求：如果经常需要做全局范围的查询（比如统计全平台热门书籍、获取所有用户的最新文章），这种子集合结构需要使用集合组查询，不仅写法复杂，还需额外配置集合组索引，查询性能和成本也会高于根集合的全局查询。
• 数据批量操作需求多：子集合数量会随用户量增长而剧增，后续如果要批量更新所有书籍的某个字段、清理过期数据等，操作难度远大于根集合。
• 无实际写入压力：如果books或articles的写入量远低于单集合配额限制，强行拆分只会增加数据结构的复杂度，完全没必要。

总结 #

如果你的业务以用户维度的私有数据访问为主，且确实存在单集合写入速率瓶颈，这种结构是合理的解决方案；但如果有大量全局数据查询需求，或写入压力不大，直接使用根集合会更简洁高效。

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