事务中的Firebase多位置更新？

我需要帮助找出在我的用例中使用firebase的最佳方法。我正在制作一个twitter克隆，但与我的帖子不同，它是可变的

我的数据库结构如下：

房间，本质上是一个你可以订阅的帖子提要。会议室成员可以向该会议室发帖：

rooms/{roomId}/posts/{postId}/->具有标题、评论数、喜欢等属性的帖子摘要

房间/{roomId}/users/{userId}/->订阅此房间的所有用户的列表

房间/{roomId}/info/->房间大小、类型、名称等

用户，所有用户的全局列表：

用户/{userId}/feed/{postId}->用户订阅的所有房间/{roomId}/posts/的集合

users/{userId}/rooms/{roomId}->用户订阅的所有房间的列表

帖子，实际帖子内容的全局列表：

posts/{postId}/comments/{commentId}->嵌套注释

posts/{postId}/users/{userId}->需要此post上的推送通知的用户

posts/{posted}/info/->评论、喜欢、作者、发布日期等的数量

posts/{postId}/content/->实际内容

学校、房间列表：

学校/{schoolId}/rooms/{roomName}/info->学校房间列表。房间名称在学校中是唯一的

学校/{schoolId}/admins/{userId}->具有不同授权规则的管理员列表

现在，前两个用例很好。如何制作和编辑对帖子的引用是一个困惑。我的用例是：

用例0：用户希望创建房间

多位置将房间对象更新为/rooms/，并将相应的房间摘要对象更新为schools/{schoolId}/rooms/，以及users/{userId}/rooms/

用例1：用户想要预订房间

在rooms/{roomId}/上运行事务。将{userId}添加到rooms/{roomId}/users/并将房间大小增加1

事务完成后，拍摄该快照并执行多位置更新。复制rooms/{roomId}/posts到users/{userId}/feed，将{roomId}添加到user/{userId}/rooms/并将新大小写入/schools/{schoolId}/rooms/{roomName}/info

如果多重写入失败，则从文件室/{roomId}/users/中删除{userId}

用例2：用户希望向房间发送帖子

从文件室/{roomId}/users检索用户列表

多位置使用post摘要和post对象更新所有用户提要和全局post表 问题是，如果另一个用户在我们的用户检索到用户列表后立即加入这个房间，那么他就不是多位置更新的一部分，无法接收这个新帖子

当我试图更新帖子上的评论数量时，我也面临着类似的难题。如果一篇文章有15条评论，并且两个人同时向该文章添加了一条新评论，那么当在事务中完成时，全局文章对象将正确更新为17条，但取决于之后扇出的顺序，每个人的文章摘要对象可能有16条评论。当用户加入房间时，房间的大小也是如此

---

我该怎么做？有没有一种方法可以更好地为我的数据建模，或者有没有一种方法可以在事务期间正确地进行多位置更新？

当我看到您的用例时，我认为您的数据模型有点太复杂了

Firebase对我来说就像：

没有sql数据存储

发布/订阅服务器

启用web套接字的前端服务器

客户端库

这意味着我不会存储此

users/{userId}/feed/{postId}

，而是在客户端登录时执行以下操作：

“连接”到用户订阅的每个房间

从订阅的房间获取所有最近的帖子

在客户端订购帖子

这样，当有人发表新的帖子/评论时，它将只在一个位置写入

rooms/{roomId}/posts/

---

我还将删除你的like/post/comment计数器，当我需要这些信息时，调用该方法以避免不必要的并发访问。

Hmm，我之前已经按照你所说的对数据进行了结构化，但是客户端的重新排序和分页并不是件小事。获得一个包含最近100篇文章的页面意味着从所有房间获得100篇文章，以确保它们是按最新情况排序的。这种情况很快就会失控。除此之外，我还想优化读写。Tbh，我对off by one错误和不同统计数据（如喜好、用户等）的计数不一致表示满意，但我对用户错过房间帖子的可能性表示不满。我必须承认，第一次加载可能很难实现，但为什么不从每个房间获取最新的帖子并向客户展示呢。一旦你的页面/应用程序加载了一些帖子，检查是否有有趣的老帖子，就像在一些聊天应用程序中那样，只加载最新的消息，而不是所有未读的消息。如果所有房间都差不多处于活动状态，那么从每个房间获取100/n个最新帖子来显示~100篇帖子就可以了，但我的领域不允许我对不同房间的活动做出任何这样的假设。即使这些文件室同样处于活动状态，用户订阅的每个文件室每次读取都需要一个网络RTT，而as写入只需要一个网络RTT。我宁愿换一种方式，优化阅读。我从来没有说过这是一个完美的解决方案，只是给出了一个想法，但你说“每个阅读需要一个用户订阅的每个房间一个网络RTT，而写只需要一个”不。Firebase与Web套接字一起工作。客户端上的任何更新都会传输到服务器，而不会启动新连接，因为连接已经存在。服务器将更新推送到其他连接的（和感兴趣的）客户端，因为连接已经存在。i、 e：你的加载时间只取决于你的数据长度，对于FirebaseAh来说，“RTT”可以忽略不计，我没有意识到这一点。谢谢没有API来执行mult