云Firestore正在阻止大容量更新同步

Question

（注意：如果我在这里使用关系数据库术语，很抱歉。）

假设我有十个客户端连接到一个数据库。该数据库的持续吞吐量约为每秒1k次更新。显然，对于最终用户来说，每秒向web浏览器发送1k个更新（比如每秒1MB的数据更改）并不是一个好的体验。Firebase是否可以控制客户端在开始限制数据之前可以“接受”的数据量？我理解它可能会批量请求，但我的观点是，谷歌接受数据/更新的速度比浏览器更快（可能是通过弱互联网连接的手机），那么有什么控制或技术可以控制最终用户的这种体验呢？

我从文档中看到的唯一项目是：

您不应每秒更新单个文档超过一次。如果您更新文档太快，那么您的应用程序将遇到争用，包括更高的延迟、超时和其他错误。

https://firebase.google.com/docs/firestore/best-practices#updates_to_a_single_document

Answer 1

为了防止大量写操作淹没客户端的快照侦听器，可以定期将写操作复制到客户端监视的代理集合。

文档需要一个字段来记录最后一次重复写入代理集合的时间，并且执行写入的进程应避免写入代理集合，直到频率持续时间结束。

由于您拥有的任何并发进程，可能仍会发生少量不必要的写入，但这些写入在实践中可能无关紧要（复制频率相当长）。

如果数据属于某个用户，而不是全局数据，则可以动态地或基于用户配置调整每个用户的写入频率，以适应其连接。

通过这种方式，您的进程可以控制客户端看到的写入频率，而无需限制或以其他方式拒绝入口写入（这对上游进程来说可能是个坏消息）。

留档的相关部分如下。

https://firebase.google.com/docs/firestore/best-practices#realtime_updates

限制收集写入速率
1000次操作/秒

将单个集合的写入操作速率保持在1,000次/秒以下。

将单个客户端推送速率限制为每秒1个文档

将数据库推送到单个客户端的文档速率保持在每秒1个文档以下。

Answer 2

这个主题在这里被涵盖，把用来编码的语言放在一边，答案中的链接代码可以提供帮助。

在一般说明中，如果您的客户端应用程序配置为侦听Firestore更新，它将向该侦听器接收所有更新事件（就像您提到的正在发生的一样）。

您可以考虑轮询Firebase进行更改。轮询甚至可以是客户端应用程序代码的扩展，其中代码跟踪接收更新的频率，并具有每秒更新的最大值，当达到该值时，会导致客户端断开作为侦听器的连接，并对数据执行定期轮询。在一段时间后，当更新更少时，可以重新建立侦听器以继续正常的工作流。

综上所述，这并不是最佳的治疗方法，而是针对症状而非原因。如果监听器返回的更新太多，您应该考虑数据的结构，并将更新隔离开来，以便只需要更新到需要更新的监听器。

类似地，可以通过确保较小的记录包含导致数据较少的更改来缓解较大的更新。一个广义的例子是更新两个字段的数据，但记录的大小为150个字段。与其返回完整的150个字段，不如将字段分成不同的数据集，这样这两个字段就位于各自的记录中，另外一个参考字段用于与其余148个字段（加上参考字段）的第二个数据集相关联。当更新较小的记录时，客户端应用程序接收到较小的更新，确定更新是否适用于自身，如果适用，则获取相应的较大记录。