Используйте Cloud Firestore с базой данных Firebase Realtime

You can use both Firebase Realtime Database and Cloud Firestore in your app, and leverage each database solution's benefits to fit your needs. Например, вы можете захотеть использовать поддержку присутствия Realtime Database , как описано в разделе «Создание присутствия в Cloud Firestore .

Узнайте больше о различиях между базами данных .

Перенос данных в Cloud Firestore

Если вы решили перенести часть своих данных из Realtime Database в Cloud Firestore , рассмотрите следующий порядок действий. Поскольку каждая база данных имеет уникальные потребности и особенности структуры, автоматического пути миграции не существует. Вместо этого вы можете следовать следующему общему прогрессу:

  1. Сопоставьте структуру данных и правила безопасности из Realtime Database с Cloud Firestore . И Realtime Database , и Cloud Firestore используют аутентификацию Firebase, поэтому вам не нужно менять аутентификацию пользователя для вашего приложения. Однако правила безопасности и модель данных различаются, и важно тщательно учитывать эти различия, прежде чем начинать перемещать данные в Cloud Firestore.

  2. Переместить исторические данные. Настраивая новую структуру данных в Cloud Firestore , вы можете сопоставить и переместить существующие данные из Realtime Database в новый экземпляр Cloud Firestore . Однако если вы используете в своем приложении обе базы данных, вам не нужно перемещать исторические данные из Realtime Database .

  3. Зеркально отображайте новые данные в Firestore в режиме реального времени. Используйте облачные функции для записи новых данных в новую базу данных Cloud Firestore по мере их добавления в Realtime Database .

  4. Сделайте 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 используют 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 , выполните следующие действия:

  1. Экспортируйте данные из Realtime Database или используйте недавнюю резервную копию .
    1. Перейдите в раздел Realtime Database в консоли Firebase .
    2. На вкладке «Данные » выберите узел корневого уровня вашей базы данных и выберите «Экспорт JSON» в меню.

  2. Создайте новую базу данных в 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 .

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

  2. Убедитесь, что ваши данные надежно защищены. Проверьте Cloud Firestore Security Rules или настройку IAM.