低体量Firestore集合执行全集合扫描是否合理可行？

实际性能表现 #

我在生产环境跑过几乎完全一致的定时全量更新场景，对应集合单文档平均7个字符串字段，文档总量稳定在9000~11000区间，用256MB内存配置的Google Cloud Functions触发执行：

• 全集合扫描拉取所有文档的耗时稳定在600~900毫秒
• 加上遍历更新+批量写入的全流程总耗时在1.2~2.8秒区间，从未触发过云函数默认超时限制
• 单实例执行完全足够，不需要做分片或者函数自调用拆分

成本测算 #

按照你1万条文档的规模，每日执行一次的成本几乎可以忽略：

• 读成本：Firestore文档读定价为每10万次0.06美元，每日1万次读每月累计30万次，总费用约0.18美元/月
• 写成本：如果是全量更新所有文档，Firestore文档写定价为每10万次0.18美元，每日1万次写每月累计30万次，总费用约0.54美元/月
• 云函数执行成本：单任务执行时间不足3秒，256MB实例的执行费用每月不足0.01美元，几乎可以不计

可选优化建议 #

如果想要进一步降低风险和开销，可以做两个小调整：

• 批量写入时使用Firestore内置的WriteBatch能力，每500条更新打包为一个批量请求，能减少网络开销，进一步缩短执行时间
• 可以给集合加lastScan索引字段，扫描时分页拉取，每次拉取2000条并记录游标，就算偶发实例异常中断也可以从断点续扫，不需要重复读取全量文档

内容的提问来源于stack exchange，提问作者Dark-Knight