Firestore集合限制与性能：多城市订单存储集合选型建议

核心结论 #

你当前没有跨集合查询需求的场景下，完全不需要拆分为15个独立集合，单集合方案的性能、配额占用和拆分方案没有本质差异，还能保留开发便捷的优势。 #

先澄清一个常见认知误区 #

很多开发者刚接触Firestore时，会把传统关系型数据库"单表数据量过大会导致查询变慢"的经验直接套用过来，觉得集合存的文档多了性能必然下降，这是对Firestore分布式架构的典型误解：
Firestore的集合是原生水平扩展设计，没有单集合文档数量的硬上限，所有读写、监听操作的性能只和单次操作匹配的结果集规模、索引命中情况挂钩，和集合总文档量没有关联。哪怕单集合存储上百亿条订单文档，只要查询能命中索引，性能和存几百条文档的小集合没有可感知的差别。 #

为什么你的场景用单集合不会触发性能或配额问题 #

• 写入配额层面：Firestore单集合的持续写入上限为50000次/秒，读取没有单集合维度的硬阈值。15个城市的餐饮订单场景，除非单集合持续写入超过这个阈值（折算下来平均每个城市每秒产生3000笔以上订单，普通餐饮业务几乎不可能触达这个量级），根本不会触发写入限流。
• 实时监听器层面：监听器的资源消耗只和监听条件匹配到的文档变更频率有关，和集合总大小无关。只要你给每个城市的业务端加上city == "对应城市标识"的过滤条件，监听器只会同步对应城市的订单变更，不会拉取其他14个城市的数据，负载、延迟表现和拆成独立集合完全一致，也不会触发单监听器每秒1000次更新的默认限制。
• 维护成本层面：单集合可以统一配置安全规则、统一创建复合索引、统一编写云函数触发逻辑（比如订单支付后的通知、营收统计逻辑），不用为15个集合编写重复的维护代码，后期迭代效率高很多。

仅在以下场景下，才需要考虑拆分独立集合 #

• 业务写入规模真的达到单集合50000次/秒的持续写入阈值，控制台/接口返回明确的热点写入限流错误。
• 存在强制数据合规要求：不同城市的订单需要物理隔离存储（比如要求某地区数据必须存储在指定地域的服务器节点），单集合无法满足物理隔离要求。
• 权限配置需求极简：需要给不同城市的运营人员配置集合级别的IAM访问权限，不想在安全规则中编写字段级的权限校验逻辑。

单集合方案落地注意事项 #

1. 所有订单查询、实时监听器必须带上city字段作为过滤条件，禁止执行不带城市过滤的全集合扫描操作。
2. 提前为常用查询场景创建复合索引，比如city + createTime（按时间范围查询某城市订单）、city + orderStatus（按订单状态查询某城市订单），避免线上出现索引缺失报错。
3. 配置数据生命周期策略，自动归档超过保留期限的历史订单，减少不必要的存储成本。

内容的提问来源于stack exchange，提问作者N.Sam