Firestore引入了新的聚合查询count()，这对我来说非常有用。我在试着了解它的速度和成本。
文档提到了性能:
性能取决于您的索引配置和数据集。
和
大多数查询是基于结果集的大小来扩展的，不是数据集。但是，聚合查询是基于大小进行伸缩的和扫描的索引条目的数目。
和定价:
现在假设我有两个集合，第一个集合100,0001'000'000文档。我在两个集合上运行您将为每批最多1000个索引收取一次文档读取费用查询匹配的条目。
someQuery.count()，都返回1500。以下是一些问题:
- 两个查询将被收取相同的(2文件读取)?
- 由于第二个集合有更多的文档，第二个查询会比第一个查询花费更长的时间吗?如果是-多长时间(线性，对数，等等)?
- 文档中性能取决于您的索引配置是什么意思?我可以配置集合和它们的索引，使
count工作更快吗?
如果能得到一些答案就太好了，我非常依赖count(我知道，它还在预览中)。
COUNT()查询的收费是基于匹配的索引条目的数量通过这个查询。本质:
- 取返回的计数，
- 除以1000，四舍五入，
- 如果结果为0，则加1。
这是您需要阅读文件的次数。
COUNT()查询的性能取决于所计数的项数。计算更多的条目将花费更长的时间，因为数据库必须匹配大量的索引条目。
这类似于您实际检索文档而不仅仅是它们的计数:获取更多文档也会花费更多时间。当然:计算文档比实际获取文档要快，但是计算更多的文档仍然比计算更少的文档花费更多的时间。
由于Firestore能够跨索引执行z - zg -merge-join(该功能现在可能有不同的名称，但它仍然在做类似的事情)，即使您没有针对您使用的确切字段组合的特定索引，也可以进行某些查询。这减少了数据库所需的索引数量，从而降低了相关成本。它也可能影响计数的性能，但不是以一种容易计算的方式。我建议不要尝试在这里进行优化，直到你真正需要它，即当你注意到某些查询比数据库中的其他类似查询慢。