Локальная запись в Firebase RTDB или Firestore с подключенными слушателями стоит Read Op?

Question

В этом официальном руководстве Firestore говорится, что

Локальные записи в вашем приложении немедленно вызовут слушателей снимков.Это связано с важной функцией, называемой «компенсацией задержки».Когда вы выполняете запись, ваши слушатели будут уведомлены с новыми данными, прежде чем данные будут отправлены на сервер

1. Таким образом, клиент Firestore (который разместил эти данные) не будет получать эти данные черезпрослушиватели с сервера?
2. Будет ли взиматься плата за чтение (если данные не извлекаются с сервера)?
3. Верна ли эта концепция и для базы данных реального времени?

Я протестировал его с клиентом, записывающим новый объект в /chats/chatRoomId/, и тем же клиентом, у которого есть прослушиватели для child_added на /chats/chatRoomId/.Я выключил Интернет, но все еще сообщалось о получении новых данных (из-за возможности автономной работы, я думаю), и слушатели также сообщали о получении новых данных (даже без доступа к серверу)

Я хочу структурировать базу данных моего приложения чата, так что я могу сократить расходы на ненужные операции чтения (если они есть) в структуре БД чата, заданные здесь и здесь , рекомендованные @ FrankVanPuffelen из Firebase.

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

Пример :

Рассмотрим чат 1: 1, где userA и userB (на разных клиентах) находятся в чате,и оба добавили слушателя к /chats/chatRoomId/.Теперь, если пользователь A отправляет новое сообщение в chatRoomId, оба пользователя A и B получат это новое сообщение через своих слушателей.Не является ли это пустой тратой пропускной способности и / или расходов на чтение операций для пользователя А, поскольку он сам выдвинул его и, вероятно, не потребует извлечения его с сервера.

Если локальные записи НЕ СТОИТ мне прочитать чтение с серверадля подключенного прослушивателя я буду хранить сообщения от userA и userB по тому же пути /chats/chatRoomId/, как рекомендовано

В противном случае, я хочу иметь структуру БД, так что userA будет прослушивать только сообщения отUSERB.например, userA отправит новое сообщение для userB на /chats/uid_A/uid_B/, а userA будет прослушивать /chats/uid_B/uid_A/, когда userB отправляет новые сообщения для userA.И клиент локально объединит два пути, отсортированные по времени, чтобы получить один поток чата.

Это потенциально сэкономит мне 50% чтений и огромную экономию на счетах Firebase.

РЕДАКТИРОВАТЬ 03/05/2019:

Добавление изображения для ясности вопроса:

Answer 1

1. То есть клиент Firestore (который разместил эти данные) не будет получать эти данные через прослушиватели с сервера?

Когда вы записываете некоторые данные локально, прослушиватель снимков будетбыть вызван немедленно.Это означает, что ваши слушатели будут уведомлены сразу, потому что вы добавили некоторые новые данные.Но помните, эта операция происходит перед отправкой данных на серверы Firebase.

Будет ли взиматься плата за чтение (если данные не извлекаются с сервера)?

Нет.Пока вы кэшируете данные и на сервере нет измененных документов, вы не будете платить за «Read Op» в Firestore.

Верна ли эта концепция и для базы данных реального времени?

Нет, это не так.База данных Firebase reltime имеет другую концепцию для цен .

Я хочу структурировать базу данных моего приложения чата, чтобы сократить расходы на ненужные чтения (если они есть) в чатеСтруктура БД дана здесь и здесь , рекомендованная @FrankVanPuffelen из Firebase.

Оба примера предназначены для базы данных реального времени Firebase, и оба объясняют очень хороший способ созданияприложение чата.Если вы когда-нибудь решите попробовать использовать Cloud Firestore для приложения чата, здесь вы можете найти учебное пособие о том, как создать законченное и функциональное Firestore Chat App .