Firestore集合是否物理隔离？单库多租户部署性能与扩容咨询

底层存储逻辑说明 #

Firestore底层采用分布式分片存储架构，所有数据并非存储在单个blob/文件中。集合属于逻辑资源，底层数据会按文档键的范围自动拆分到不同的存储节点，不同集合的分片调度完全独立，正常情况下单个集合的规模、负载不会对同库下其他集合的性能、存储产生影响，不会出现高负载租户拖累轻量租户的问题。

核心问题解答 #

1. 单库扩容能力 #

单个Firestore数据库没有官方公布的硬存储上限，单集合存储数十亿条记录属于完全支持的场景。Firestore的查询性能仅和返回的结果集大小相关，和集合/数据库的总数据量无关。
只要符合以下设计规范，单库可以实现接近线性的水平扩容：

• 避免使用单调递增的字段作为文档ID或索引字段，防止产生写入热点
• 减少高频跨集合的聚合查询、分布式事务操作
• 超大租户的集合提前做好键值散列设计，分散分片负载
  默认单库的写入QPS软限制可以通过提交工单申请提升，没有硬性天花板。

2. 模式适配与差异 #

优先选择*Firestore Native（原生模式）*适配该多租户场景：

• 两种模式底层共享同一套分布式存储引擎，前述的扩容能力、集合间性能隔离特性完全一致，没有差异
• Native模式支持实时数据监听、集合组查询、更灵活的安全规则配置，更适配多租户业务的灵活开发需求
• Datastore模式仅用于兼容原有基于App Engine Datastore开发的遗留应用，无特殊兼容需求无需选择

3. 扩容瓶颈替代方案 #

如果业务规模确实超出单Firestore数据库的承载能力，可按优先级选择以下方案：

• Firestore多库拆分：同一个Google Cloud项目支持创建多个独立的Firestore数据库，可将数据量超大、负载极高的租户单独拆分到独立Firestore库，实现完全的物理资源隔离，隔离性强于单库下拆集合，同时可复用现有Firestore业务逻辑，改造成本最低
• Cloud Bigtable：如果需要支持单表万亿条记录、数十万以上的读写QPS，优先选择全托管的Cloud Bigtable，其支持按行键自动分片，租户间隔离性更强，和GCP生态集成度高，运维成本远低于开源分布式数据库
• Cassandra：仅在有多云部署需求、不希望绑定云厂商的场景下选择，特性和Bigtable接近，但需要自行承担集群运维、扩容、故障修复的成本，不建议优先考虑

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