Cloud Task运行时Firestore并发限制及批量读写性能问题咨询

1. 每分钟执行一次该查询是否会影响应用整体性能？ #

会产生明显影响：

• 单次查询扫描200万条文档会占用大量Firestore读配额，挤压其他业务正常请求的配额资源，严重时会导致其他业务请求被限流
• 无优化的全量查询延迟极高，很容易触发Cloud Function运行时长上限导致执行失败，重复触发还会进一步浪费资源
• 如果未提前建立PerformAt+Status的复合索引，查询会触发全表扫描，直接拖慢整个数据库的响应速度

2. 该查询会算作200万并发用户还是1个并发用户？ #

仅算作1个并发用户。Firestore的并发用户统计维度是同时建立连接的独立请求发起方，本次查询是单个Cloud Function实例发起的单次请求，哪怕单次请求读取百万级文档，也只会统计为1个并发连接，不会触发100万的并发用户上限。

3. 单次读取200万条Firestore文档大约需要多长时间？ #

没有固定数值，受部署区域、索引配置、读取方式影响：

• 提前建好复合索引的前提下，单线程分页读取的耗时通常在30秒到5分钟区间
• 如果未建索引直接全表扫描，或者不分页直接尝试拉取全量结果，大概率会触发Firestore请求超时限制，直接查询失败。

4. 如何优化解决写入上限1万次/秒的限制？ #

可以通过多层优化适配写入限制：

• 先做读取分页：查询时增加游标分页逻辑，每次仅拉取3000~5000条文档，处理完当前批次的写入再拉取下一批，从源头控制写入请求的生成速度
• 用批量写入能力：调用Firestore的BatchWrite接口，每次批量提交最多500条更新操作，大幅降低请求开销，同时也更容易管控写入速率不超过1万次/秒的阈值
• 异步削峰：如果允许非实时处理，可先将所有需要更新的文档ID写入Pub/Sub队列，配置多个Cloud Function消费者异步消费队列做更新，通过控制消费者数量即可轻松适配写入限速要求
• 长期架构优化：将Scheduled状态的任务按PerformAt的时间粒度（小时/天）分桶存储到不同子集合，每次触发仅查询对应时间桶的子集合，无需全量扫描200万条文档，读写成本都会大幅降低。

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