Каковы компромиссы производительности / выставления счетов для коллекций firebase root против вложенных коллекций в коллекции - PullRequest
0 голосов
/ 18 января 2020

Мне известно, что коллекции Firebase уровня root являются наиболее гибкими и масштабируемыми и что подколлекции не могут быть легко удалены. И что с точки зрения выставления счетов, я знаю, что с firestore, это об общем объеме хранимых данных, операциях дБ и количестве данных, возвращаемых набором результатов. Но скажем, я спорю о различных подходах к архитектуре базы данных для приложения, которое включает в себя сообщения и разговоры:

с использованием Root только для коллекций уровня:

  • Поля сбора бесед
    • членов (массив пользовательских ссылок)
    • lastReceivedTime
  • Поля сбора сообщений
    • разговорный идентификатор (разговор делает c ссылка)
    • до (ссылка пользователя)
    • от (ссылка пользователя)
    • содержимое
    • datetime

с использованием Подборка root для разговоров и сообщений

  • Поля сбора бесед
    • члены (массив пользовательских ссылок)
    • lastReceivedTime
    • Сообщения Подколлекция
      • содержание
      • dateTime
      • от (пользовательский реф)

Коллекция Маршрут вспомогательного сбора кажется более простым, но каковы плюсы / минусы производительности / выставления счетов / операций в Firebase? каждого подхода?

1 Ответ

2 голосов
/ 18 января 2020

В соответствии с документацией для Firestore Billing :

При использовании Cloud Firestore взимается плата за следующее:

  • Номер операций чтения, записи и удаления, которые вы выполняете.
  • Объем хранилища, используемый вашей базой данных, включая накладные расходы для метаданных и индексов.
  • Объем используемой пропускной способности сети.

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

Если все ваши запросы по-прежнему читают, пишут и удаляют одинаковое количество документов, тогда фактура по пункту 1. останется неизменной.

Если все ваши документы по-прежнему содержат одинаковые данные, то фактура по пункту 2 останется без изменений.

Если предыдущие два предположения остаются в силе, то пропускная способность сети для передачи всего по существу одинакова, что означает выставление счетов точка 2 останется неизменной.

Здесь и там может быть несколько байтов разницы из-за того, как пути к документам могут быть сохранены и переданы. Если предположить, что более длинные пути к документам потребуют еще несколько байтов памяти и пропускной способности, то более глубокие коллекции могут быть немного дороже. Но, по моему мнению, если вы пытаетесь оптимизировать несколько байтов данных на документы, вы должны показать, что разница в стоимости действительно стоит вашего времени. Если вы еще не рассчитали, какой будет экономия, тогда это преждевременная оптимизация, и, вероятно, она не стоит времени. Делайте все, что сэкономит вам больше времени, чтобы вы могли сделать больше.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...