Firestore集合组查询likes子集合的读操作成本核算

核心结论 #

你描述的场景下，集合组查询产生的计费读次数和最终匹配到的文档总数完全相等。如果执行db.collectionGroup("likes").where("liked", "==", true)查询命中了1万条liked: true的likes文档，就会产生整整1万次读操作的计费，不存在额外的扫描计费、跨路径遍历计费。

具体计费逻辑拆解 #

• Firestore的读操作计费仅以实际被查询引擎返回给应用侧的文档为统计依据，和查询类型是普通单集合查询、还是跨层级同名子集合的集合组查询没有本质差异
• 你提到的嵌套结构posts/{postId}/users/{userId}/likes下的所有三级子集合，会被集合组查询统一遍历统计：所有路径下满足liked == true筛选条件的文档，每1个计1次读操作
• 查询过程中被引擎扫描过、但不满足筛选条件的未命中文档，不会计入读操作账单
• 即便你在应用层没有完整读取文档内容、提前中断了分页拉取，只要是被引擎返回给客户端的文档，都会被计入读操作计费

常见认知误区 #

• 不要误以为集合组查询会因为跨多路径扫描就产生额外的遍历开销计费：Firestore的查询引擎本身会借助索引完成检索，不会把索引扫描的中间步骤折算成额外的读操作费用
• 如果查询缺少对应要求的复合索引，首次触发索引构建的操作会单独按索引构建的规则产生费用，这部分成本和正常查询的读计费是独立分开的，不会和查询命中的文档数绑定

补充说明：如果后续做分页拉取的时候设置了单页返回上限，比如每次返回100条，那么每一页的拉取操作就会按对应页的实际返回文档数计费，累计总计费数和最终拉取到的所有匹配文档总数保持一致。

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