Вы можете использовать в своем приложении как базу данных Firebase Realtime, так и Cloud Firestore, а также использовать преимущества каждого решения для баз данных в соответствии со своими потребностями. Например, вы можете захотеть использовать поддержку присутствия в базе данных реального времени, как описано в разделе «Создание присутствия в Cloud Firestore» .
Узнайте больше о различиях между базами данных .
Перенос данных в Cloud Firestore
Если вы решили, что хотите перенести некоторые свои данные из базы данных Realtime в Cloud Firestore, рассмотрите следующий порядок действий. Поскольку каждая база данных имеет уникальные потребности и особенности структуры, автоматического пути миграции не существует. Вместо этого вы можете следовать следующему общему прогрессу:
Сопоставьте структуру данных и правила безопасности из базы данных реального времени с Cloud Firestore. И база данных Realtime, и Cloud Firestore используют аутентификацию Firebase, поэтому вам не нужно менять аутентификацию пользователя для вашего приложения. Однако правила безопасности и модель данных различаются, и важно тщательно учитывать эти различия, прежде чем начинать перемещать данные в Cloud Firestore.
Переместить исторические данные. Настраивая новую структуру данных в Cloud Firestore, вы можете сопоставить и переместить существующие данные из базы данных реального времени в новый экземпляр Cloud Firestore. Однако если вы используете в своем приложении обе базы данных, вам не нужно перемещать исторические данные из базы данных реального времени.
Зеркально отображайте новые данные в Firestore в режиме реального времени. Используйте облачные функции для записи новых данных в новую базу данных Cloud Firestore по мере их добавления в базу данных реального времени.
Сделайте Cloud Firestore своей основной базой данных для переносимых данных. После переноса некоторых данных используйте Cloud Firestore в качестве основной базы данных и сократите использование базы данных реального времени для перенесенных данных. Рассмотрите версии вашего приложения, которые все еще привязаны к базе данных реального времени для этих данных, и то, как вы планируете продолжать их поддерживать.
Убедитесь, что вы учитываете расходы на выставление счетов как за базу данных Realtime , так и за Cloud Firestore .
Сопоставьте свои данные
Данные в базе данных реального времени структурированы в виде единого дерева, а Cloud Firestore поддерживает более явную иерархию данных через документы, коллекции и подколлекции. Если вы переместите некоторые свои данные из базы данных реального времени в Cloud Firestore, возможно, вы захотите рассмотреть другую архитектуру для своих данных.
Основные различия, которые следует учитывать
Если вы перемещаете данные из существующего дерева базы данных реального времени в документы и коллекции Cloud Firestore, имейте в виду следующие основные различия между базами данных, которые могут повлиять на то, как вы структурируете данные в Cloud Firestore:
- Мелкие запросы обеспечивают большую гибкость в иерархических структурах данных.
- Сложные запросы обеспечивают большую степень детализации и уменьшают потребность в дублирующихся данных.
- Курсоры запросов обеспечивают более надежную нумерацию страниц.
- Транзакции больше не требуют общего корня для всех ваших данных и являются более эффективными.
- Стоимость выставления счетов различается в базе данных Realtime и Cloud Firestore. Во многих случаях Cloud Firestore может оказаться дороже, чем база данных Realtime, особенно если вы полагаетесь на множество небольших операций. Рассмотрите возможность сокращения количества операций с базой данных и предотвращения ненужных операций записи. Узнайте больше о различиях в выставлении счетов между базой данных Realtime и Cloud Firestore.
Лучшие практики в действии
Следующий пример отражает некоторые соображения, которые вы можете принять во внимание при перемещении данных между базами данных. Вы можете использовать поверхностное чтение и улучшенные возможности запросов для более естественных структур данных, чем вы могли использовать с базой данных реального времени.
Рассмотрим приложение-путеводитель по городу, которое помогает пользователям находить примечательные достопримечательности в городах по всему миру. Поскольку в базе данных в реальном времени не хватает мелких чтений, вам, возможно, пришлось структурировать данные в двух узлах верхнего уровня, следующим образом:
// /cities/$CITY_KEY
{
name: "New York",
population: 8000000,
capital: False
}
// /city-landmark/$CITY_KEY/$LANDMARK_KEY
{
name: "Empire State Building",
category: "Architecture"
}
У Cloud Firestore есть мелкие чтения, поэтому запрос на документы в сборе не получает данные из субболнений. Следовательно, вы можете хранить знаковую информацию в подколке:
// /cities/$CITY_ID
{
name: "New York",
population: 8000000,
capital: False,
landmarks: [... subcollection ...]
}
Документы имеют максимальный размер 1 МБ, что является еще одной причиной для хранения достопримечательностей в качестве суббочки, сохраняя каждый городской документ небольшим, а не вздутие живота с вложенными списками.
Усовершенствованные возможности запроса Cloud Firestore уменьшают необходимость дублирования данных для общих шаблонов доступа. Например, рассмотрим экран в приложении «Городской гид», которое показывает все столицы, заказанные населением. В базе данных в реальном времени наиболее эффективным способом сделать это является сохранение отдельного списка городов, которые дублируют данные из списка cities
, следующим образом:
{
cities: {
// ...
},
capital-cities: {
// ...
}
}
В Cloud Firestore вы можете выразить список столичных городов в порядке населения в качестве единого запроса:
db.collection('cities')
.where('capital', '==', true)
.orderBy('population')
Узнайте больше о модели данных Cloud Firestore и посмотрите на наши решения для получения дополнительной информации о том, как структурировать базу данных Cloud Firestore.
Защитите свои данные
Независимо от того, используете ли вы правила безопасности Cloud Firestore для Android, Apple или веб -клиентов, или управление доступом к личности (IAM) для серверов, убедитесь, что вы защищаете свои данные в Cloud Firestore, а также в базе данных в реальном времени. Аутентификация пользователя осуществляется с помощью аутентификации для обеих баз данных, поэтому вам не нужно менять реализацию аутентификации, когда вы начинаете использовать Cloud Firestore.
Основные различия, чтобы рассмотреть
- Мобильные и веб-SDK используют правила безопасности Cloud Firestore, а серверные SDK используют Identity Access Management (IAM) для защиты данных.
- Правила безопасности Cloud Firestore не применяются каскадно, если вы не используете подстановочный знак. В противном случае документы и коллекции не наследуют правила.
- Вам больше не нужно проверять данные отдельно (как это было в базе данных реального времени ).
- Cloud Firestore проверяет правила перед выполнением запроса, чтобы убедиться, что у пользователя есть соответствующий доступ ко всем данным, возвращаемым запросом.
Переместите исторические данные в Cloud Firestore.
После того как вы сопоставили свои данные и структуры безопасности с моделями данных и безопасности Cloud Firestore, вы можете начать добавлять свои данные. Если вы планируете запрашивать исторические данные после перемещения приложения из базы данных реального времени в Cloud Firestore, добавьте экспорт старых данных в новую базу данных Cloud Firestore. Если вы планируете использовать в своем приложении и базу данных реального времени, и Cloud Firestore, вы можете пропустить этот шаг.
Чтобы избежать перезаписи новых данных старыми, вы можете сначала добавить исторические данные. Если вы добавляете новые данные в обе базы данных одновременно, как описано на следующем шаге, убедитесь, что вы отдаете приоритет новым данным, добавленным в Cloud Firestore с помощью Cloud Functions.
Чтобы перенести исторические данные в Cloud Firestore, выполните следующие действия:
- Экспортируйте данные из базы данных реального времени или используйте недавнюю резервную копию .
- Перейдите в раздел «База данных реального времени» в консоли Firebase.
- На вкладке «Данные» выберите узел корневого уровня вашей базы данных и выберите «Экспорт JSON» в меню.
Создайте новую базу данных в Cloud Firestore и добавьте свои данные .
Рассмотрите следующие стратегии при перемещении некоторых ваших данных в Cloud Firestore:
- Напишите пользовательский скрипт, который портит ваши данные для вас. Несмотря на то, что мы не можем предложить шаблон для этого сценария, поскольку у каждой базы данных будет уникальные потребности, эксперты Cloud Firestore на нашем канале Slack или на переполнении стека могут просмотреть ваш сценарий или предложить советы для вашей конкретной ситуации.
- Используйте сервер SDK (Node.js, Java, Python или Go), чтобы записать данные непосредственно в Cloud Firestore. Инструкции по настройке сервера SDK см. Начало работы .
- Чтобы ускорить крупные миграции данных, используйте пакетные записи и отправьте до 500 операций в одном сетевом запросе.
- Чтобы оставаться в рамках облачных ограничений по ставке Firestore , ограниченные операции до 500 записей/секунд для каждой коллекции.
Добавить новые данные в Cloud Firestore
Чтобы поддерживать паритет между вашими базами данных, добавляйте новые данные в обе базы данных в режиме реального времени. Используйте облачные функции, чтобы запустить запись в Cloud Firestore всякий раз, когда клиент пишет в базу данных в реальном времени. Убедитесь, что Cloud Firestore дает приоритет новым данным, поступающим из облачных функций, по сравнению с любыми записями, которые вы делаете из своей исторической миграции данных.
Создайте функцию для записи новых или изменяющихся данных в Cloud Firestore каждый раз, когда клиент записывает данные в базу данных реального времени. Узнайте больше о триггерах базы данных реального времени для облачных функций.
Сделайте Cloud Firestore своей основной базой данных для переносимых данных.
Если вы решили использовать Cloud Firestore в качестве основной базы данных для некоторых ваших данных, убедитесь, что вы учитываете все настроенные вами функции зеркального отображения данных и проверяете свои правила безопасности Cloud Firestore.
Если вы использовали облачные функции для поддержания четности между вашими базами данных, убедитесь, что вы не дублируете операции записи в обеих базах данных в цикле. Переключите свою функцию на запись в одну базу данных или полностью удалите эту функцию и начните поэтапный отказ от функции записи для перенесенных данных в приложениях, которые все еще привязаны к базе данных реального времени. То, как вы справитесь с этим для своего приложения, зависит от ваших конкретных потребностей и ваших пользователей.
Убедитесь, что ваши данные надежно защищены. Проверьте правила безопасности Cloud Firestore или настройку IAM.