В своем приложении вы можете использовать как Firebase Realtime Database , так и Cloud Firestore , и применять преимущества каждого решения для работы с базами данных в соответствии со своими потребностями. Например, вы можете использовать поддержку определения присутствия в Realtime Database , как описано в разделе «Создание функции определения присутствия в Cloud Firestore .
Узнайте больше о различиях между этими базами данных .
Перемещение данных в Cloud Firestore
Если вы решили перенести часть своих данных из Realtime Database в Cloud Firestore , рассмотрите следующий алгоритм действий. Поскольку каждая база данных имеет уникальные потребности и структурные особенности, автоматизированного пути миграции не существует. Вместо этого вы можете следовать этой общей последовательности:
Сопоставьте структуру данных и правила безопасности из Realtime Database с Cloud Firestore . И Realtime Database , и Cloud Firestore используют аутентификацию Firebase, поэтому вам не нужно менять аутентификацию пользователей для вашего приложения. Однако правила безопасности и модель данных различаются, и важно тщательно учесть эти различия, прежде чем начать переносить данные в Cloud Firestore.
Перемещение исторических данных. При настройке новой структуры данных в Cloud Firestore вы можете сопоставить и переместить существующие данные из Realtime Database в новый экземпляр Cloud Firestore . Однако, если вы используете обе базы данных в своем приложении, вам не нужно перемещать исторические данные из Realtime Database .
Передавайте новые данные в Firestore в режиме реального времени. Используйте Cloud Functions для записи новых данных в вашу новую базу данных Cloud Firestore по мере их добавления в Realtime Database .
Сделайте Cloud Firestore основной базой данных для перенесенных данных. После переноса части данных используйте Cloud Firestore в качестве основной базы данных и сократите использование Realtime Database для перенесенных данных. Продумайте версии вашего приложения, которые по-прежнему привязаны к Realtime Database для этих данных, и как вы планируете продолжать их поддержку.
Обязательно учтите расходы на выставление счетов как для Realtime Database , так и Cloud Firestore .
Составьте карту ваших данных
В Realtime Database данные структурированы в виде единого дерева, в то время как Cloud Firestore поддерживает более явные иерархии данных через документы, коллекции и подколлекции. Если вы переносите часть своих данных из Realtime Database в Cloud Firestore , вам, возможно, стоит рассмотреть другую архитектуру для ваших данных.
Основные различия, которые следует учитывать.
При переносе данных из существующего дерева Realtime Database в документы и коллекции Cloud Firestore следует учитывать следующие основные различия между базами данных, которые могут повлиять на структуру данных в Cloud Firestore :
- Поверхностные запросы обеспечивают большую гибкость в иерархических структурах данных.
- Сложные запросы обеспечивают большую детализацию и уменьшают необходимость в дублировании данных.
- Курсоры запросов обеспечивают более надежную постраничную навигацию.
- Транзакции больше не требуют общего корневого каталога для всех ваших данных и стали более эффективными.
- Стоимость услуг Realtime Database и Cloud Firestore различается. Во многих случаях Cloud Firestore может оказаться дороже, чем Realtime Database , особенно если вы используете множество небольших операций. Рассмотрите возможность сокращения количества операций с базой данных и избегания ненужных операций записи. Узнайте больше о различиях в оплате между Realtime Database и Cloud Firestore .
Передовые методы на практике
Следующий пример отражает некоторые соображения, которые вы можете учесть при переносе данных между базами данных. Вы можете использовать поверхностное чтение и улучшенные возможности запросов для создания более естественных структур данных, чем те, которые вы могли использовать с Realtime Database .
Рассмотрим приложение-путеводитель по городам, которое помогает пользователям находить известные достопримечательности в городах по всему миру. Поскольку Realtime Database не поддерживает поверхностное чтение, вам, возможно, пришлось бы структурировать данные в двух узлах верхнего уровня следующим образом:
// /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 уменьшают необходимость дублирования данных для распространенных шаблонов доступа. Например, рассмотрим экран в приложении «Путеводитель по городам», на котором отображаются все столицы, отсортированные по численности населения. В Realtime Database наиболее эффективный способ сделать это — поддерживать отдельный список столиц, дублирующий данные из списка cities , следующим образом:
{
cities: {
// ...
},
capital-cities: {
// ...
}
}
В Cloud Firestore вы можете представить список столиц городов, отсортированных по численности населения, в виде одного запроса:
db.collection('cities')
.where('capital', '==', true)
.orderBy('population')
Узнайте больше о модели данных Cloud Firestore и ознакомьтесь с нашими решениями , чтобы получить больше идей о том, как структурировать вашу базу данных Cloud Firestore .
Защитите свои данные
Независимо от того, используете ли вы Cloud Firestore Security Rules для клиентов Android, Apple или веб-клиентов, или систему управления идентификацией и доступом (IAM) для серверов, убедитесь, что вы защищаете свои данные как в Cloud Firestore , так и в Realtime Database . Аутентификация пользователей обрабатывается системой аутентификации для обеих баз данных, поэтому вам не нужно менять свою реализацию аутентификации при начале использования Cloud Firestore .
Основные различия, которые следует учитывать.
- В мобильных и веб-SDK используются Cloud Firestore Security Rules , а в серверных SDK — управление идентификацией и доступом (IAM) для защиты данных.
- Cloud Firestore Security Rules не применяются последовательно, если не используется подстановочный знак. Документы и коллекции в противном случае не наследуют правила.
- Вам больше не нужно проверять данные отдельно (как это было в Realtime Database ).
- Перед выполнением запроса Cloud Firestore проверяет правила, чтобы убедиться, что у пользователя есть соответствующий доступ ко всем данным, возвращаемым запросом.
Перенесите исторические данные в Cloud Firestore
После того, как вы сопоставите свои структуры данных и безопасности с моделями данных и безопасности Cloud Firestore , вы можете начать добавлять свои данные. Если вы планируете запрашивать исторические данные после переноса вашего приложения из Realtime Database в Cloud Firestore , добавьте экспорт старых данных в вашу новую базу данных Cloud Firestore . Если вы планируете использовать в своем приложении как Realtime Database , так и Cloud Firestore , вы можете пропустить этот шаг.
Чтобы избежать перезаписи новых данных старыми, возможно, вам следует сначала добавить исторические данные. Если вы добавляете новые данные в обе базы данных одновременно, как обсуждается на следующем шаге, убедитесь, что вы отдаете приоритет новым данным, добавленным в Cloud Firestore с помощью Cloud Functions .
Для переноса исторических данных в Cloud Firestore выполните следующие действия:
- Экспортируйте данные из Realtime Database или используйте актуальную резервную копию .
- Перейдите в раздел Realtime Database в консоли Firebase .
- На вкладке «Данные» выберите корневой узел вашей базы данных и в меню выберите «Экспорт JSON» .
Создайте новую базу данных в Cloud Firestore и добавьте в нее свои данные .
При переносе части данных в Cloud Firestore рассмотрите следующие стратегии:
- Напишите собственный скрипт, который перенесет ваши данные. Хотя мы не можем предложить шаблон для этого скрипта, поскольку у каждой базы данных свои уникальные потребности, эксперты Cloud Firestore в нашем канале Slack или на Stack Overflow могут проверить ваш скрипт или дать рекомендации, соответствующие вашей конкретной ситуации.
- Используйте SDK сервера (Node.js, Java, Python или Go) для прямой записи данных в Cloud Firestore . Инструкции по настройке SDK сервера см. в разделе «Начало работы» .
- Для ускорения миграции больших объемов данных используйте пакетную запись и отправляйте до 500 операций в одном сетевом запросе.
- Чтобы не превышать лимиты скорости Cloud Firestore , ограничьте количество операций записи до 500 в секунду для каждой коллекции.
Добавьте новые данные в Cloud Firestore
Для обеспечения согласованности между базами данных добавляйте новые данные в обе базы данных в режиме реального времени. Используйте Cloud Functions для запуска записи в Cloud Firestore всякий раз, когда клиент записывает данные в Realtime Database . Убедитесь, что Cloud Firestore отдает приоритет новым данным, поступающим из Cloud Functions перед любыми записями, которые вы выполняете при миграции исторических данных.
Создайте функцию для записи новых или изменяющихся данных в Cloud Firestore каждый раз, когда клиент записывает данные в Realtime Database . Узнайте больше о триггерах Realtime Database для Cloud Functions .
Сделайте Cloud Firestore основной базой данных для перенесенных данных.
Если вы решили использовать Cloud Firestore в качестве основной базы данных для части ваших данных, убедитесь, что вы учли все настроенные функции зеркалирования данных и проверили Cloud Firestore Security Rules .
Если вы использовали Cloud Functions для обеспечения согласованности между базами данных, убедитесь, что операции записи не дублируются в обеих базах данных в цикле. Переключите свою функцию на запись в одну базу данных или полностью удалите функцию и начните постепенно отказываться от функциональности записи мигрированных данных в приложениях, все еще привязанных к Realtime Database . Способ решения этой проблемы для вашего приложения зависит от ваших конкретных потребностей и ваших пользователей.
Убедитесь, что ваши данные должным образом защищены. Проверьте Cloud Firestore Security Rules или настройки IAM.