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

Question

上下文

我的团队正在使用 Firestore 构建下一代实时虚拟读书俱乐部（不是真的，但它简化了我的应用的实际用例）。

到了读书俱乐部开会的时间，用户将加入他们各自的读书俱乐部，并投票决定他们接下来想读哪些书。读书俱乐部往往有 10 到 15 名用户，每个俱乐部倾向于对 25 到 30 本书进行投票。每个用户都可以对任意数量的书籍进行投票。这些读书俱乐部投票会持续大约 3-4 分钟，所有俱乐部的用户都会在这段时间内投票。

当前的 Firestore 架构

我的数据结构如下：

• bookClubs（收藏）
  • bookClub1（文档）
    • 书籍（收藏）
      • book1（文档）
      • book2（文档）
      • ...
      • bookX（文档），其中 X 通常为
    • 用户（集合）
      • user1（文档）
      • user2（文档）
      • ...
      • userY（文档），其中 Y 通常为
  • bookClub2（文档）
    • ...

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

我们这样做是为了让每个用户客户端都可以实时看到每本书和每本书的投票者有多少投票。

限制

在开发过程中，对于拥有 3 到 4 名用户并为 8 到 12 本书进行投票的俱乐部来说，事情似乎运作良好。昨晚，我们举行了第一次真正的读书俱乐部会议，有 15 个用户和大约 30-35 本书，事情崩溃和烧毁。设备变得无响应，移动网络浏览器开始崩溃，数据不同步。

在结束读书俱乐部会议并不得不遗憾地用旧纸和笔投票后，我们的开发团队回到绘图板上，以了解事情可能失败的地方。

我们在 Firestore 文档中发现了以下推荐的最佳做法：

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

在我们的例子中，每个加入bookClubZ 文档并调用snapshotChanges() 的用户都必须下拉bookClubZ 文档以及两个bookClubZ 子中的每个book 文档和user 文档收藏品。这相当于 1 bookClubZ doc + 30 book docs + 15 user docs = 每个读书俱乐部用户客户端在初始化时正在阅读的大约 46 个文档，更不用说用户投射时发生的每个更新为一本书投票。

我们是否已经超越了 Firestore 的功能？看起来我们似乎严重违反了上面推荐的最佳实践。这种情况是否更适合 Socket.io、PubNub、Ably 等？我们的 Firestore 数据结构是笨拙且低效的吗？

Answer 1

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

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

不过，当您超过此限制时，Firestore 不会崩溃；您的写入只会排队，直到服务器可以处理它们。

这只是对您引用的限制的简要说明。如果没有看到minimal code that we can use to reproduce it，就不可能说出您的用户经历了什么。我的第一个问题是您是否在free plan，如果是，请检查发生了多少文档读取。使用简单的数据结构很容易为每个用户增加读取次数，如果您达到项目/计划的配额限制，Firestore 将停止工作。