Firebase云函数中Firestore全表查询耗时远超写入的性能问题咨询

原因说明 #

你观察到的读取耗时远高于写入是正常现象，和Firestore本身的读写性能优先级无关，核心差异来自操作逻辑：

• 你调用全集合get()时，需要把2.3万条文档的完整数据从Firestore存储节点拉取到云函数实例内存，还要完成Firestore序列化格式到JS对象的全量反序列化，这两步的IO和CPU开销都很高
• Bulk Writer的批量写入仅需要向Firestore提交更新指令，不需要拉取任何全量数据到云函数，所有写入执行逻辑都在Firestore集群内部完成，仅产生控制信令的网络开销，耗时自然更低

可行优化方案 #

• 使用投影查询仅拉取必要字段
  如果你仅需要文档ID来完成更新操作，不需要读取文档的其他字段，使用仅查询文档ID的投影查询，可以把拉取的数据量从6MB降到几十KB，反序列化开销也几乎可以忽略，实测可以把查询耗时降到1秒以内：

const { FieldPath } = require('firebase-admin/firestore');

let querySnapshot = await admin.firestore()
    .collection("enrollment")
    .select(FieldPath.documentId()) // 仅返回文档ID，不加载其他字段
    .get()

• 分批分页读取
  不要一次性拉取全集合2.3万条数据，使用limit() + startAfter()做分批拉取，每批拉取1000~2000条，多批并行处理既可以降低单请求的超时概率，也能提升整体读取效率。
• 采用流模式边读边写
  不需要等待全量快照加载完成再开始写入操作，使用Firestore的流读取接口，边拉取文档边提交写入任务，进一步压缩整体耗时。
• 提升云函数实例配置
  如果你的云函数使用的是128MB内存的最低配置，实例的CPU性能会非常受限，2.3万条文档的反序列化很容易出现CPU瓶颈。把函数内存配置提升到256MB或512MB，CPU性能会同步提升，解码速度可以快2~3倍。

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