如何减少Cloud Firestore实体写入操作次数？

一、写入次数暴增的核心原因 #

Firestore 和 Firebase Realtime Database 的写入计数规则确实有本质区别：

• 在 Realtime Database 中，你把 Records 作为数组存在主节点里，不管数组包含多少元素，整个数组的写入只算1次写入操作。
• 但在 Firestore 中，子集合里的每一个文档都是独立的资源。如果你的每个主对象对应10条 Records 子集合文档，那写入1个主对象 + 10条子集合文档，就会产生11次写入。2000个主对象的话，2000*(1+10)=22000次，和你看到的2万次完全吻合。

简单总结：Firestore 是按单个文档来计数写入操作的，而 Realtime Database 是按节点路径计数，节点下的所有子数据都算一次。

二、为什么用 Batch 没效果？ #

Firestore 的 Batch() 作用是合并多个写入请求，减少网络往返次数，但它并不会改变写入次数的计数规则。Batch 里的每一个子集合文档创建/更新操作，依然会被单独计入配额。比如你在一个 Batch 里放500条子集合文档，还是会消耗500次写入配额，只是这些操作会一次性发送到服务器，而不是分500次请求。

三、优化建议 #

根据你的业务场景，有两个可行方向：

1. 回归数组存储（最直接减少写入次数） #

如果你的 Records 结构简单，不需要单独查询子集合里的单个文档，也不会因为数组过大导致主文档超过 Firestore 的1MB 大小限制，那完全可以把 Records 作为数组字段直接存在主文档里。这样写入1个主对象只算1次写入，2000个对象就是2000次，和原来的 Realtime Database 逻辑一致。

2. 必须用子集合时的配额优化 #

如果因为业务需求必须用子集合（比如需要单独查询某个 Record、主文档大小超限等），那可以：

• 排查重复写入：检查是否不小心重复创建了子集合文档，或者更新了不需要变更的字段。
• 利用原子批量写入：虽然不能减少计数，但可以确保所有写入要么全部成功要么全部失败，避免部分写入导致的配额浪费。
• 调整配额：如果业务确实需要这么多写入次数，可以考虑申请提高 Firestore 的配额限制。

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