В своем приложении вы можете использовать как 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.
Move historical data. As you're setting up your new data structure in Cloud Firestore , you can map and move existing data from Realtime Database to your new Cloud Firestore instance. However, if you're using both databases in your app, you don't need to move historical data out of 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.