【问题标题】:Cloud Firestore throttling high-volume update syncingCloud Firestore 限制大量更新同步
【发布时间】:2022-01-18 09:00:50
【问题描述】:

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

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

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

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

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

【问题讨论】:

  • 嗨,大卫,你在这方面有什么进展吗?我试图在下面提供答案。你有没有机会检查一下,这有意义吗?如果我的回答有用,请点击它左侧的点赞按钮 (▲)。如果它回答了您的问题,请单击复选标记 (✓) 接受它。这样其他人就知道你得到了(足够的)帮助。

标签: firebase google-cloud-platform google-cloud-firestore


【解决方案1】:

here 涵盖了该主题,将用于编码的语言放在一边,该答案中的链接代码可以提供帮助。

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

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

如上所述,这不是最佳选择,而是治疗症状而不是原因。如果侦听器返回的更新过多,您应该考虑数据的结构,并将更新隔离为只需要对需要更新的侦听器进行更新。

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

【讨论】:

  • 您好像忘记在第一行添加链接 This topic is covered in [1] 或者最后一个链接是一个?请更新。
  • 最后一个链接就是那个。让我编辑它以提高可读性和理解性。
【解决方案2】:

为防止大量写入使客户端的快照侦听器不堪重负,您可以定期将写入复制到客户端监视的代理集合。

文档需要一个字段来记录上次重复写入代理集合的时间,并且执行写入的进程应避免在频率持续时间过去之前对代理集合进行写入。

由于您拥有任何并发​​进程,仍然可能会发生少量不必要的写入,但这些在实践中可能是微不足道的(具有相当长的重复频率)。

如果数据属于用户,而不是全局数据,那么您可以调整每个用户的写入频率以适应他们的连接,动态或基于用户配置。 p>

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

以下文档的相关部分。

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

限制集合写入速率
1,000 次操作/秒

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

限制单个客户端推送率 1 个文档/秒

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

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2018-03-17
    • 2019-10-03
    • 2018-06-21
    • 1970-01-01
    • 2019-04-24
    • 2020-03-30
    • 1970-01-01
    • 2020-12-09
    相关资源
    最近更新 更多