firebase - Firestore 增量中原子更新的强度

Question

我是 Firestore 用户，最近深入研究了“原子”更新的概念，尤其是 Firestore 文档的增量更新。有一篇关于原子更新上下文中 Firestore 增量的经典文章。我的问题来了。

increment(number)问，这个原子更新有多强？当涉及到真正的原子操作时，这个操作真的没有限制吗？

让我用一个例子来解释一些细节。我们知道 Firestore 每个数据库实例的写入限制为 10,000（每秒最多 10 MiB），而且我们还知道 Firestore 的increment方法以原子方式更新文档。所以，我希望知道下面的极端示例是否可以完美地自动运行。

这个 Firestore 实例只有一个文档，并且众多用户（最多可能 10000 个用户）使用增量方法更新单个文档，该方法在一秒钟内将相同的字段值增加为 0 到 1 之间的随机双精度数： 1秒10000次更新；

上述案例尽可能使用 Firestore 每秒写入速率限制，所有操作都在更新同一文档的单个字段。如果increment方法真正以原子方式处理更新请求，我们可能会说所有 10000 个详细信息都将正确计算到单个字段中。

increment但是，这只是理论上和概念上的想法，当 Firestore（甚至任何其他数据库系统）必须线性处理其他即将到来的操作时，当它执行如此极端的操作集时，似乎真的很难不例外。这意味着 Firestore 实例将继续处理即将到来的 API 请求。实际上，这是一个现实世界的问题。假设是一位可爱的歌手，Ariana Grande 的 Instagram 帖子刚刚上传。如果我们使用 Firestore 文档处理事件，我们将不得不increment requests每秒钟处理数千个点赞。

所以，我希望知道是否真的没有atomic increment方法的限制，即使有一组大量的极并发increment requests到极少数的目标文档。希望这个问题能传达给社区中的 Firebase 大师！评论真的很受欢迎！提前致谢 [：

标签： firebasegoogle-cloud-firestore

Answer 1

我不确定我是否完全理解您的问题，但无论如何我都会尝试通过解释 Firestore 及其increment操作的工作原理来提供帮助。

Firestore 的主要写入限制来自这样一个事实，即每次写入操作都需要在数据中心之间同步数据。这不是配额类型的限制，而是数据传输速度的物理限制。

由于您谈论的是对单个文档的频繁写入，因此您很快就会达到每个文档每秒 1 次持续写入的软限制。这也是数据库工作方式的物理性质造成的，需要在服务器/数据中心之间同步文档和索引。

虽然使用该increment()操作意味着客户端和服务器之间不需要往返，但它对需要在服务器本身读取/写入的数据没有影响。因此，它对记录在案的吞吐量限制没有影响。

如果您需要执行超出记录的吞吐量限制的计数，请查看有关使用分布式计数器的文档。