Вы можете использовать в своем приложении как Firebase Realtime Database, так и Cloud Firestore, и пользоваться преимуществами каждого решения в зависимости от своих потребностей. Например, вы можете использовать поддержку статуса присутствия в Realtime Database, как описано в статье Как создать статус присутствия в Cloud Firestore.
Подробнее о различиях между базами данных…
Перенос данных в сервис "Cloud Firestore"
Если вы решили перенести часть данных из Realtime Database в Cloud Firestore, рекомендуем выполнить следующие действия: Поскольку у каждой базы данных есть уникальные потребности и структурные особенности, автоматизированного пути миграции не существует. Вместо этого вы можете следовать следующей общей последовательности:
Сопоставьте структуру данных и правила безопасности из Realtime Database с Cloud Firestore. И Realtime Database, и Cloud Firestore используют Firebase Authentication, поэтому вам не нужно менять аутентификацию пользователей в приложении. Однако правила безопасности и модель данных различаются, и важно тщательно учесть эти различия, прежде чем начинать перенос данных в 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 или веб-клиентов или Identity Access Management (IAM) для серверов, убедитесь, что вы защищаете свои данные как в Cloud Firestore, так и в Realtime Database. Аутентификация пользователей в обеих базах данных выполняется с помощью Authentication, поэтому вам не нужно менять реализацию Authentication, когда вы начнете использовать Cloud Firestore.
Основные различия
- SDK для мобильных устройств и веб-приложений используют Cloud Firestore Security Rules, а SDK для серверов – Identity Access Management (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 или используйте недавнюю резервную копию.
- В консоли Firebase выберите Databases & Storage (Базы данных и хранилище) > Realtime Database (База данных в реальном времени).
- На вкладке Данные выберите узел корневого уровня базы данных и в меню нажмите Экспортировать 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.