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

Question

我是 Firestore 用户，最近深入研究了“原子”更新的概念，尤其是 Firestore 文档的增量更新。有一个classic article在原子更新上下文中的 Firestore 增量上。我的问题来了。

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

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

This Firestore instance only has a single document, and numerous users-maybe 10000 users maximum- update a single document using increment method, which increments a same field value as much as a random double number between 0 and 1 each, WITHIN a single second: 10000 updates in 1 second;

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

但是，这只是理论上和概念上的想法，当 Firestore(或什至任何其他数据库系统)执行这样一组极端的 increment 操作时，似乎真的很难不异常(exception)它必须线性地处理其他即将到来的操作。这意味着 Firestore 实例将继续处理即将到来的 API 请求。实际上，这是一个现实世界的问题。比方说一位可爱的歌手，Ariana Grande 的 Instagram 帖子刚刚上传。如果我们使用 Firestore 文档处理该事件，我们将不得不每秒处理数千个点赞的增量请求。

所以，我希望知道atomic increment 方法是否真的没有限制，即使有一组非常并发的increment 请求 到很少的数量的目标文件。希望社区中的 firebase 专家能回答这个问题!非常欢迎评论!提前致谢 [:

Answer 1

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

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

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

虽然使用 increment() 操作意味着客户端和服务器之间不需要往返，但它对需要在服务器本身上读取/写入的数据没有影响。因此它对 documented throughput limits 没有影响.

如果您需要执行超出记录的吞吐量限制的计数，请查看有关使用 distributed counter 的文档.