了解Firestore推荐的最大客户端推送速率为1文档/秒

Question

上下文

我的团队正在构建一个下一代的、实时的、虚拟的图书俱乐部(虽然不是，但它简化了我的应用程序的实际用例)。

当图书俱乐部开会的时候，用户将加入他们各自的图书俱乐部，并投票决定下一本书的内容。图书俱乐部的用户往往在10-15人之间，每个俱乐部倾向于对25-30本书进行投票。每个用户都可以根据自己的意愿对多少本书投一票。这些图书俱乐部的投票会议持续约3-4分钟，所有俱乐部的用户都在这段时间内投票。

当前Firestore体系结构

我的数据结构看起来如下：

• bookClubs (集合)
  • bookClub1 (文档)
    • 图书(收藏)
      • book1 (文件)
      • book2 (文件)
      • ..。
      • bookX (文档)，其中X通常是< 30

​

    - users (collection)  
        - user1 (document)
        - user2 (document)
        - ...
        - userY (document) where Y is usually < 15

​

​

- bookClub2 (document)  
    - ...

​

​

选票存储在图书文档的映射数组中，其中每个映射包含用户的uid、名称和其他元数据。每个图书俱乐部用户都在使用snapshotChanges()监听bookClubX文档上的更改，以及嵌套图书集合和嵌套用户集合。

我们这样做是为了让每个用户客户能够实时地看到对每本书和每本书的选民投了多少票。

局限性

在发展过程中，对于拥有3-4个用户的俱乐部来说，事情似乎很顺利，他们正在对8-12本图书进行投票。昨晚，我们举行了我们的第一次真正的图书俱乐部会议，有15个用户和大约30-35本书，而事情崩溃并烧毁了。设备变得反应迟钝，移动网络浏览器开始崩溃，数据不同步。

在图书俱乐部会议休会后，我们的开发团队不得不用旧学校的纸和笔进行不幸的投票，我们的开发团队回到了画板上去了解事情可能会失败的地方。

我们在Fi还原文档中遇到了以下推荐的最佳实践：

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

在我们的示例中，每个加入bookClubZ文档并调用snapshotChanges()的用户都必须在两个bookClubZ子集合中提取bookClubZ文档以及每个book文档和user文档。这相当于为每个图书俱乐部用户客户端初始化时正在读取的1 bookClubZ文档+ 30 book文档+ 15 user文档+15user文档，更不用说当用户对一本书进行投票时发生的每一次更新。

我们是否已经超越了Firestore的能力？显然，我们似乎严重违反了上述推荐的最佳实践。这个场景是否更适合像Socket.io、PubNub、Ably等？我们的Firestore数据结构是愚蠢和低效的吗？

Answer 1

您正在执行46次每秒读取，这非常少。即使您有大量的用户，这些读取操作也将继续很好地扩展。

您引用的限制是特定于将吞吐量写入单个文档。因此，您可以(平均)每秒写入每个文档一次。实际上，它比这更复杂，并且与Firestore必须更新的索引有关，而且在操作被认为完成之前，所有数据都被提交到多个数据中心。但是，在设计数据结构时，要记住每秒写1次文档是一个很好的保守估计。

但是，当您超出此限制时，Firestore不会崩溃；您的写操作将只是排队，直到服务器能够处理它们。

这只是对你所引用的限制的一个快速解释。如果不看到我们可以用来复制它的最小代码，就不可能说出您的用户经历了什么。我的第一个问题是您是否在自由计划上，如果是，请检查发生了多少文档读取。如果您达到了项目/计划的配额限制，就很容易用一个幼稚的数据结构将每个用户的读取挂起，而Firestore将停止工作。