Fra*_*len 3 nosql firebase google-cloud-firestore
我看到 Firestore 有计数、总和和平均值运算符，用于计算服务器上的聚合值。
但还有两个记录在案的解决方案用于计算聚合值和保留分布式计数器。
这些解决方案有什么区别？我什么时候应该使用其中之一？
TL;DR：内置运算符执行读取时聚合，而记录的解决方案执行写入时聚合。
Firestore 最初发布时不支持任何聚合操作，例如计算文档。虽然这在 NoSQL 数据库中并不罕见，但许多开发人员都在询问如何处理此类操作 - 这就是记录聚合和分布式计数器解决方案的原因。
这些解决方案在写入时聚合值，这意味着您：
虽然这些解决方案运作良好，但它们需要开发人员进行大量的规划和工作。
从那时起，Firestore 一直在添加允许读取时聚合操作的运算符：首先count()于 2022 年末添加，然后于 2023 年末添加 和sum()。average()
现在 Firestore 的聚合运算符（计数、总和和平均值）已经推出一段时间了，我已经开发了一种描述它们的特定方法。
新的运算符允许您跨多个文档执行读取时聚合。它们比阅读完整文档要高效得多，因为它们可以仅使用索引中的数据。由于这对我们来说执行成本要低得多，因此提供这些运算符的费用仅为阅读完整文档成本的一小部分（1/1000）。
现有的解决方案提供跨多个文档的写入时聚合。虽然这比读取时运算符需要更多的前期工作，但它们在以下情况下仍然有用：
您必须汇总大量文档。
当我测试时，读取时间计数运算符在大约 4000 万个文档时超时：Cloud Firestore 中的文档计数有多快？
许多用户需要访问聚合值。
虽然聚合运算符比阅读完整文档便宜得多，但计算数百万个人用户的数百万文档仍然需要花费$$$。
您希望获得聚合值的实时更新或希望在离线时访问这些值。
读取时聚合运算符目前不支持侦听器，也不能离线使用，而写入时聚合只是普通文档中的值。
另一方面，对我来说，新的读取时聚合运算符在以下情况下更方便：
您提前不知道您可能需要哪些聚合值。
如果您发现自己始终需要临时查询数据，请考虑使用更适合该用例的数据源，例如 BigQuery。
您需要为合理数量的用户计算合理数量的文档。
您想要生成包含聚合值的定期报告。