Использование поля вместо документа в Firebase, плохая практика?

Question

На самом деле я пытаюсь найти наиболее эффективный способ уменьшить количество операций чтения в моем приложении Firebase.

Вместо создания нового документа для каждого объекта я думал о вставке каждого объекта в новое поле того же документа.

Вот типичный объект, который я использую в своем приложении:

{
 "restaurantName" : "The Love story",
 "openingTimes" : {"opening" : "9AM", "closing" : "11pm"},
 "numberOfReviews" : 2340
}

Согласно Firebase ограничение размера документа составляет 1 МБ, что достаточно для размещения около 2000 объектов в моем случае.

Сделав снимок одного документа, я могу прочитать все поля документа по следующему пути: payload['_document']['proto']['fields']

this.afs.collection('MyCollection').doc('restaurantName').snapshotChanges().subscribe(data => {
  console.log('All the fields of my doc = ', payload['_document']['proto']['fields'])
});

Кажется, это работает нормально и считается только 1 документ, прочитанный каждый раз, когда в документе происходят изменения, верно?

Этот подход намного дешевле, чем загрузка документов X, но что-то подсказывает мне, что это не очень хорошая практика.

Есть ли причины, по которым я не должен go при таком подходе?

Спасибо

Answer 1

Я думаю, это a плохая практика :

Cloud Firestore всегда загружает full документы

Представьте себе, что в документе есть несколько тысяч полей, и несколько пользователей вносят свой вклад в этот документ и меняют его там каждую секунду. Всего за минуту у вас будет 60 MB (!) Использования данных для этого одного документа на пользователя .

Если бы вы разбили это на несколько документов, у вас было бы только 1 MB на пользователя при макс. . Большую часть времени у пользователей уже будет кэшироваться хотя бы часть документов, что означает, что это снова уменьшит использование.

Firestore не оптимизирован для этого

Как я уже коснулся , кеш не будет работать вообще . Даже если 99% полей остаются неизменными, все эти значения будут обновляться при каждом изменении другого поля.

Это также отрицательно повлияет на запросы, поскольку они построены для нескольких документов.

Вы будете платить больше

Cloud Firestore оптимизирован для чтения документов - они не очень дороги. Пропускная способность , однако, стоит дорого:

См. Расценки по Расценки Firebase и по сетевым расходам (которые вы также должны платить и иметь бесплатную квоту) Цены в Google Cloud :

• Вы платите $0.06/100K документ читает .

• Сеть цены немного варьируются ; скажем, 0.05$/GB сетевой выход .

Таким образом, в случае выше, мы можем ясно видеть, что разница может легко составлять два порядка (выходной сигнал в МБ к K читает) больше, однако, только для цены , равной , допускается только один порядок. Я мог бы легко представить, что вы платите в 10 раз больше, используя свой метод, и это может стоить в зависимости от региона.

Кстати, возможно, я неправильно понял точную цену. Вы можете обнаружить, что запросы Cloud Firestore также оплачиваются на основе пропускной способности здесь и, очевидно, на странице Квоты App Engine для вашего проекта.

Answer 2

Как только вы не go превысите ограничение в 1 МБ для документа, технически ничто не помешает вам принять этот подход.

Однако с этим вы можете столкнуться с некоторыми другими ограничениями / сложностями. модель данных:

• Что если вы хотите сделать запрос только для одного ресторана? Собираетесь ли вы загружать данные 2000 ресторанов только для получения значений одного из них?
• В зависимости от того, как вы храните коллекцию объектов ресторана (массив или карту), вам может потребоваться загрузить всю коллекцию если вы хотите обновить только один элемент одного ресторана.