Cloud Firestore 限制大量更新同步

Dav*_*542 9 firebase google-cloud-platform google-cloud-firestore

(注意:抱歉,如果我在这里使用关系数据库术语。)

假设我有十个客户端连接到数据库。该数据库的持续吞吐量约为每秒 1k 次更新。显然,每秒向 Web 浏览器发送 1k 次更新(假设每秒更改 1MB 数据)对于最终用户来说不会是良好的体验。Firebase 是否可以控制客户端在开始限制之前可以“接受”多少数据?我知道它可能会批量请求,但我的观点是,谷歌可以比浏览器更快地接受数据/更新(可能来自互联网连接较弱的手机),那么有哪些控制或技术可以控制这种体验最终用户?

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

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

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

Pri*_*dra 0

该主题在此处进行了介绍,将用于编码的语言放在一边,该答案中的链接代码可以提供帮助。

一般来说,如果您的客户端应用程序配置为侦听 Firestore 更新,它将接收该侦听器的所有更新事件(就像您提到的那样)。

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

综上所述,这并不是最佳选择,只能治标不治本。如果侦听器返回太多更新,您应该考虑数据的结构,并考虑隔离更新,以便仅需要更新需要它的侦听器。

同样,可以通过确保较小的记录包含导致数据较少的更改来减轻大型更新的影响。一个通用的示例是更新两个数据字段,但记录大小为 150 个字段。不是返回完整的 150 个字段,而是将字段分片为不同的数据集,因此这两个字段位于其自己的记录中,并带有一个附加参考字段,用于与其余 148 个字段(加上参考字段)的第二个数据集关联。当更新较小的记录时,客户端应用程序接收该小更新,确定该更新是否适用于其自身,如果是,则获取相应的较大记录。