Utiliser Cloud Firestore avec Firebase Realtime Database

Vous pouvez utiliser Firebase Realtime Database et Cloud Firestore dans votre application, et profiter des avantages de chaque solution de base de données pour répondre à vos besoins. Par exemple, vous pouvez tirer parti de la prise en charge de la présence par Realtime Database, comme indiqué dans Créer une présence dans Cloud Firestore.

En savoir plus sur les différences entre les bases de données

Déplacement des données vers Cloud Firestore

Si vous avez décidé de migrer certaines de vos données de Realtime Database vers Cloud Firestore, suivez le processus ci-dessous. Comme chaque base de données a des besoins et des considérations structurelles uniques, il n'existe pas de chemin de migration automatisé. Vous pouvez plutôt suivre cette progression générale :

  1. Mappez la structure des données et les règles de sécurité de Realtime Database à Cloud Firestore. Realtime Database et Cloud Firestore s'appuient sur Firebase Authentication. Vous n'avez donc pas besoin de modifier l'authentification des utilisateurs pour votre application. Toutefois, les règles de sécurité et le modèle de données sont différents. Il est important de tenir compte de ces différences avant de commencer à transférer des données vers Cloud Firestore.

  2. Déplacez les données historiques. Lorsque vous configurez votre nouvelle structure de données dans Cloud Firestore, vous pouvez mapper et transférer les données existantes de Realtime Database vers votre nouvelle instance Cloud Firestore. Toutefois, si vous utilisez les deux bases de données dans votre application, vous n'avez pas besoin de déplacer les données historiques hors de Realtime Database.

  3. Miroitez les nouvelles données dans Firestore en temps réel. Utilisez Cloud Functions pour écrire de nouvelles données dans votre nouvelle base de données Cloud Firestore à mesure qu'elles sont ajoutées à Realtime Database.

  4. Définissez Cloud Firestore comme base de données principale pour les données migrées. Une fois que vous avez migré certaines de vos données, utilisez Cloud Firestore comme base de données principale et réduisez votre utilisation de Realtime Database pour les données migrées. Réfléchissez aux versions de votre application qui sont encore liées à Realtime Database pour ces données et à la façon dont vous prévoyez de continuer à les prendre en charge.

Assurez-vous de tenir compte des coûts de facturation pour Realtime Database et Cloud Firestore.

Mapper vos données

Les données de Realtime Database sont structurées sous forme d'arborescence unique, tandis que Cloud Firestore accepte des hiérarchies de données plus explicites via des documents, des collections et des sous-collections. Si vous déplacez certaines de vos données de Realtime Database vers Cloud Firestore, vous pouvez envisager une autre architecture pour vos données.

Principales différences à prendre en compte

Si vous déplacez des données de votre arborescence Realtime Database existante vers des documents et des collections Cloud Firestore, gardez à l'esprit les principales différences entre les bases de données qui peuvent avoir un impact sur la façon dont vous structurez les données dans Cloud Firestore :

  • Les requêtes superficielles offrent plus de flexibilité dans les structures de données hiérarchiques.
  • Les requêtes complexes offrent plus de précision et réduisent le besoin de données en double.
  • Les curseurs de requête offrent une pagination plus robuste.
  • Les transactions ne nécessitent plus de racine commune pour toutes vos données et sont plus efficaces.
  • Les coûts de facturation diffèrent entre Realtime Database et Cloud Firestore. Dans de nombreux cas, Cloud Firestore peut être plus coûteux que Realtime Database, en particulier si vous vous appuyez sur de nombreuses petites opérations. Envisagez de réduire le nombre d'opérations sur votre base de données et d'éviter les écritures inutiles. En savoir plus sur les différences de facturation entre Realtime Database et Cloud Firestore

Bonnes pratiques en action

L'exemple suivant reflète certaines des considérations que vous pourriez prendre en compte lorsque vous transférez vos données entre des bases de données. Vous pouvez tirer parti des lectures superficielles et des capacités de requête améliorées pour des structures de données plus naturelles que celles que vous avez peut-être utilisées avec Realtime Database.

Prenons l'exemple d'une application de guide de ville qui aide les utilisateurs à trouver des monuments célèbres dans des villes du monde entier. Étant donné que Realtime Database ne comporte pas de lecture superficielle, vous avez peut-être dû structurer les données dans deux nœuds de premier niveau, comme suit :

// /cities/$CITY_KEY
{
  name: "New York",
  population: 8000000,
  capital: False
}

// /city-landmark/$CITY_KEY/$LANDMARK_KEY
{
  name: "Empire State Building",
  category: "Architecture"
}

Cloud Firestore effectue des lectures superficielles. Par conséquent, lorsque vous interrogez des documents dans une collection, les données des sous-collections ne sont pas extraites. Par conséquent, vous pouvez stocker des informations sur les points de repère dans une sous-collection :

// /cities/$CITY_ID
{
  name: "New York",
  population: 8000000,
  capital: False,
  landmarks: [... subcollection ...]
}

La taille maximale des documents est de 1 Mo. C'est une autre raison de stocker les points de repère en tant que sous-collection, en gardant chaque document de ville petit, plutôt que de gonfler les documents avec des listes imbriquées.

Les fonctionnalités de requête avancées de Cloud Firestore réduisent la nécessité de dupliquer les données pour les modèles d'accès courants. Prenons l'exemple d'un écran de l'application de guide de ville qui affiche toutes les capitales classées par population. Dans Realtime Database, le moyen le plus efficace d'y parvenir est de tenir à jour une liste distincte des capitales qui duplique les données de la liste cities, comme suit :

{
   cities: {
    // ...
   },

   capital-cities: {
     // ...
   }
}

Dans Cloud Firestore, vous pouvez exprimer une liste de capitales par ordre de population sous la forme d'une seule requête :

db.collection('cities')
    .where('capital', '==', true)
    .orderBy('population')

En savoir plus sur le modèle de données Cloud Firestore et consultez nos solutions pour obtenir d'autres idées sur la façon de structurer votre base de données Cloud Firestore.

Sécurisez vos données

Que vous utilisiez Cloud Firestore Security Rules pour les clients Android, Apple ou Web, ou Identity Access Management (IAM) pour les serveurs, assurez-vous de sécuriser vos données dans Cloud Firestore et Realtime Database. L'authentification des utilisateurs est gérée par Authentication pour les deux bases de données. Vous n'avez donc pas besoin de modifier votre implémentation d'Authentication lorsque vous commencez à utiliser Cloud Firestore.

Principales différences à prendre en compte

  • Les SDK pour mobile et Web utilisent Cloud Firestore Security Rules, tandis que les SDK serveur utilisent Identity and Access Management (IAM) pour sécuriser les données.
  • Cloud Firestore Security Rules ne sont pas mis en cascade, sauf si vous utilisez un caractère générique. Les documents et les collections n'héritent pas des règles.
  • Vous n'avez plus besoin de valider les données séparément (comme vous le faisiez dans Realtime Database).
  • Cloud Firestore vérifie les règles avant d'exécuter une requête pour s'assurer que l'utilisateur dispose de l'accès approprié à toutes les données renvoyées par la requête.

Déplacer les données historiques vers Cloud Firestore

Une fois que vous avez mappé vos structures de données et de sécurité sur les modèles de données et de sécurité de Cloud Firestore, vous pouvez commencer à ajouter vos données. Si vous prévoyez d'interroger des données historiques après avoir migré votre application de Realtime Database vers Cloud Firestore, ajoutez une exportation de vos anciennes données à votre nouvelle base de données Cloud Firestore. Si vous prévoyez d'utiliser à la fois Realtime Database et Cloud Firestore dans votre application, vous pouvez ignorer cette étape.

Pour éviter d'écraser les nouvelles données avec les anciennes, vous pouvez ajouter vos données historiques en premier. Si vous ajoutez de nouvelles données aux deux bases de données simultanément, comme indiqué à l'étape suivante, assurez-vous de donner la priorité aux nouvelles données ajoutées à Cloud Firestore par Cloud Functions.

Pour migrer les données historiques vers Cloud Firestore, procédez comme suit :

  1. Exportez vos données depuis Realtime Database ou utilisez une sauvegarde récente.
    1. Accédez à la section Realtime Database dans la console Firebase.
    2. Dans l'onglet Données, sélectionnez le nœud racine de votre base de données, puis Exporter au format JSON dans le menu.

  2. Créez votre base de données dans Cloud Firestore et ajoutez vos données.

    Lorsque vous transférez une partie de vos données vers Cloud Firestore, tenez compte des stratégies suivantes :

    • Rédigez un script personnalisé qui transfère vos données pour vous. Nous ne pouvons pas vous fournir de modèle pour ce script, car chaque base de données a des besoins uniques. Toutefois, les experts de notre chaîne Slack ou de Stack Overflow peuvent examiner votre script ou vous conseiller en fonction de votre situation spécifique.Cloud Firestore
    • Utilisez les SDK serveur (Node.js, Java, Python ou Go) pour écrire des données directement dans Cloud Firestore. Pour obtenir des instructions sur la configuration des SDK serveur, consultez Premiers pas.
    • Pour accélérer les migrations de grandes quantités de données, utilisez les écritures par lot et envoyez jusqu'à 500 opérations dans une seule requête réseau.
    • Pour ne pas dépasser les limites de fréquence Cloud Firestore, limitez les opérations à 500 écritures par seconde pour chaque collection.

Ajouter des données à Cloud Firestore

Pour maintenir la parité entre vos bases de données, ajoutez de nouvelles données aux deux bases de données en temps réel. Utilisez Cloud Functions pour déclencher une écriture dans Cloud Firestore chaque fois qu'un client écrit dans Realtime Database. Assurez-vous que Cloud Firestore donne la priorité aux nouvelles données provenant de Cloud Functions par rapport aux écritures que vous effectuez lors de la migration de vos données historiques.

Créez une fonction pour écrire des données nouvelles ou modifiées dans Cloud Firestore chaque fois qu'un client écrit des données dans Realtime Database. En savoir plus sur les déclencheurs Realtime Database pour Cloud Functions

Définissez Cloud Firestore comme base de données principale pour les données migrées.

Si vous avez décidé d'utiliser Cloud Firestore comme base de données principale pour certaines de vos données, assurez-vous de tenir compte de toutes les fonctions de mise en miroir des données que vous avez configurées et validez votre Cloud Firestore Security Rules.

  1. Si vous avez utilisé Cloud Functions pour maintenir la parité entre vos bases de données, assurez-vous de ne pas dupliquer les opérations d'écriture dans les deux bases de données dans une boucle. Passez à une fonction d'écriture dans une seule base de données ou supprimez complètement la fonction et commencez à supprimer progressivement la fonctionnalité d'écriture pour les données migrées dans les applications toujours liées à Realtime Database. La façon dont vous gérez cela pour votre application dépend de vos besoins spécifiques et de vos utilisateurs.

  2. Vérifiez que vos données sont correctement sécurisées. Validez votre configuration Cloud Firestore Security Rules ou IAM.