Firebase 实时数据库群聊结构答案

【问题标题】：Firebase realtime database group chat structureFirebase 实时数据库群聊结构
【发布时间】：2021-08-24 16:20:27
【问题描述】：

我想在实时数据库中创建可扩展的聊天结构以支持私人和群聊
这是我目前的结构

.chats
  .chat1
    .type: private
    .lastMessage
    .users
      .uid1: true
      .uid2: true
  .chat2
    .type: group
    .groupName
    .groupImage
    .lastMessage
    .users
      .uid1: true
      .uid2: true
      .uid2: true
      ... other users

.userChats
  .uid1
    .chat1:
      .lastMessage
      .lastMessageTime
      ...
    .chat2:
      .lastMessage
      .lastMessageTime
      .image
      .groupName
      ...

当用户登录应用程序时，我想收听他/她的聊天列表并将其显示在列表中。这就是为什么我有userChats。
这里的问题是，在一个群聊中，我们可以有（例如）50 个用户，当任何用户在群中发送新消息时，我们需要为每 50 个用户更新 lastMessage 字段（在 userChats 中），所以他们可以立即更新他们的列表。
但这似乎不是正确的方法。
有没有更好的结构来实现这个目标？

【问题讨论】：

标签： firebase firebase-realtime-database

【解决方案1】：

这种结构对我来说看起来不错。我有一个open source project，它使用了一个非常相似的结构：

群聊数据：

用户的私人和群聊：

Firebase 非 SQL 数据库需要两次甚至更频繁地保存某些数据。当您开始使用它时，有时会感到奇怪和错误，但请相信我，这不是:)

【讨论】：

感谢您的关注。但我仍然认为这不是一个可扩展的解决方案。想想 100 个组，每个组有 100 个成员，每个组中的用户在完全相同的时间发送消息。在这种情况下，我们需要立即更新 10,000 个用户的聊天信息！
当使用实时数据库时writing 或多或少是FREE 在带宽旁边。如果我们在哪里使用 Firestore 数据库，我会担心，但那 10.000 次写入只会花费您云函数的时间和处理时间。如果您在批量更新中执行此操作，那还不错，因为您无论如何都需要发送通知，因此运行功能的数量将是相同的。他们只需要运行更长的时间来执行这些更改。
如果您想通过查询或从chats 列表以外的其他位置获取最后的消息，我想说的是：这些可能会比从后端（云功能）。这在客户端也会更加复杂。
我正在考虑只保留userChats 的updatedAt 字段，当聊天更新时，我只能更改该字段并且可以通知客户端更改，然后客户端可以执行get 查询相关聊天并将其存储在客户端直到下次更新。在这种情况下，我们有更少的重复字段，代价是来自客户端的额外get 查询。您对此有何看法？
如果您只更新 updatedAt 或用它 lastMessge 更新成本将是相同的，因为无论如何您都会更新文档。由于额外的收益，您只会付出更多的代价，但根本没有任何好处。