本地写入 Firebase RTDB 或带有附加侦听器的 Firestore 是否需要读取操作？

Question

在这个firestore官方指南中，它说

应用程序中的本地写入将立即调用快照侦听器。这是因为一个称为“延迟补偿”的重要功能。当您执行写入时，您的侦听器将在数据发送到后端之前收到新数据通知

1. 所以 Firestore 客户端（发布此数据）不会通过侦听器从服务器获取此数据？
2. 这是否仍会作为读取操作收费（如果未从服务器获取数据）？
3. 这个概念也适用于实时数据库吗？

我使用一个客户端向其写入新对象/chats/chatRoomId/并且具有child_addedon侦听器的同一客户端对其进行了测试/chats/chatRoomId/。我关闭了互联网，仍然报告推送新数据正常（我猜是由于离线能力），并且听众也报告收到新数据（即使没有服务器访问权限）

我想构建我的聊天应用程序的数据库，这样我就可以减少不必要的读取成本（如果有的话）在此处和此处 由Firebase的 @FrankVanPuffelen 推荐的聊天数据库结构中。

chats: {
  $roomId: {
    $messageId: {
      senderId: "..."
      message: "..."
    }
  }
}

示例：

考虑一个 1:1 聊天，其中用户 A 和用户 B（在不同客户端上）在聊天室中，并且都向/chats/chatRoomId/. 现在，如果chatRoomId用户 A在 中推送一条新消息，则两个用户 A&B 都将通过他们的侦听器收到这条新消息。这不是浪费用户 A 的带宽和/或读取操作成本，因为他自己推送它，并且可能不需要从服务器获取它。

如果本地写入不会花费我为附加的侦听器读取服务器，我会将来自用户 A 和用户 B 的消息存储在推荐的相同路径/chats/chatRoomId/中

否则，我想要一个数据库结构，以便用户 A 将只收听来自用户 B 的消息。例如，用户A 将向用户B 推送新消息，/chats/uid_A/uid_B/而用户A 将监听用户B 向用户A/chats/uid_B/uid_A/推送新消息的位置。并且客户端会在本地合并按时间排序的两条路径，得到一个聊天流。

它可能会为我节省 50% 的读取次数，并节省大量的 Firebase 账单。

2019 年 3 月 5 日编辑：

添加图片以提高问题的清晰度：

Answer 1

1. 那么 Firestore 客户端（发布此数据的）将不会通过侦听器从服务器获取此数据？

当您在本地写入一些数据时，将立即调用快照侦听器。这意味着您的听众将立即收到通知，因为您添加了一些新数据。但请记住，此操作是在数据发送到 Firebase 服务器之前发生的。

2. 这是否仍会作为读取操作收费（如果未从服务器获取数据）？

不会。只要您缓存了数据并且未将数据与 Firebase 服务器同步，您就不需要为 Firestore 中的任何“读取操作”付费。

3. 这个概念对于实时数据库也适用吗？

不，这不对。Firebase 实时数据库有不同的定价概念。

我想构建我的聊天应用程序的数据库，这样我就可以减少此处给出的聊天数据库结构和此处由 Firebase 的 @FrankVanPuffelen 推荐的不必要的读取（如果有的话）的成本。

这两个示例均适用于 Firebase 实时数据库，并且都解释了创建聊天应用程序的一种非常好的方法。如果您考虑在某个时候尝试使用 Cloud Firestore 作为聊天应用程序，您可以在此处找到有关如何创建完整且功能齐全的Firestore 聊天应用程序的教程。

我还认为您可能对以下文章感兴趣：

• https://medium.com/firebase-tips-tricks/how-to-drastically-reduce-the-number-of-reads-when-no-documents-are-changed-in-firestore-8760e2f25e9e