Максимальное хранение документов в Firestore

Question

Я работаю над публикацией проектов на форумах и пытаюсь определить идеальную структуру базы данных Firestore.Я прочитал, что максимальный размер документов составляет 1 мг, но каковы плюсы и минусы в том, чтобы максимально увеличить пространство для хранения каждого документа, поскольку в нем хранится несколько постов, а не используется один документ для каждого поста?

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

Будет ли это также быстрее?

Answer 1

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

• Firestore всегда читает полные документы. Таким образом, если вы храните 100 сообщений в одном документе размером 1 МБ, чтобы отобразить только 10 таких сообщений, вы, возможно, сократили операции чтения в 10 раз, но увеличили потребление полосы пропускания в 10 раз. И ваши мобильные пользователи, вероятно, также будут платить за эту пропускную способность.
• Реализация собственной стратегии шардинга не всегда сложна, но редко связана с функциональностью приложения.

Мои рекомендации при моделировании данных в любой базе данных NoSQL:

• экраны приложений модели в вашей базе данных

  Я склонен моделировать данные в моей базе данных после экранов, которые есть в моем приложении. Поэтому, если вы обычно отображаете список заголовков последних статей, когда пользователь запускает приложение, я мог бы фактически создать документ, который содержит только заголовки последних статей. Таким образом, приложение должно читать только один документ с заголовками, а не читать каждый отдельный пост. Это сокращает не только количество документов, которые приложение должно прочитать, но и полосу пропускания, которую оно потребляет.

• не бойтесь дублировать данные

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

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

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

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

Чтобы узнать больше о моделировании данных NoSQL:

• Моделирование данных NoSQL
• Знакомство с Cloud Firestore , в котором содержится много других примеров этих предварительно обработанных экранов приложений.