Utiliser Cloud Firestore avec Firebase Realtime Database

Vous pouvez utiliser à la fois Firebase Realtime Database et Cloud Firestore dans votre application, et exploiter les avantages de chaque solution de base de données pour répondre à vos besoins. Par exemple : vous pourriez avoir besoin de l'assistance de Realtime Database pour la présence, comme indiqué dans Renforcez votre présence dans les Cloud Firestore.

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

Transfert des données vers Cloud Firestore...

Si vous avez décidé de migrer certaines de vos données depuis Realtime Database vers Cloud Firestore, considérez le flux suivant. Comme chaque base de données a besoins uniques et considérations structurelles, il n'existe pas de migration automatisé. À la place, vous pouvez suivre cette progression générale:

  1. Mappez la structure des données et les règles de sécurité de Realtime Database avec Cloud Firestore. Realtime Database et Cloud Firestore s'appuient tous deux 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. tenir compte de ces divergences avant de commencer à migrer des données vers et Firestore.

  2. Transférez les données historiques. Lorsque vous configurez votre nouvelle structure de données dans Cloud Firestore, vous pouvez Mapper et déplacer les données existantes de Realtime Database vers votre nouveau Cloud Firestore Compute Engine. 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 de Realtime Database.

  3. Mettez en miroir de nouvelles données dans Firestore en temps réel. Utilisez Cloud Functions pour écrire de nouvelles données dans votre nouveau Cloud Firestore à la base de données à mesure qu'elle est ajoutée à 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 données. Tenez compte des versions de votre application qui sont toujours liées à Realtime Database pour ces données et la manière dont vous prévoyez de continuer à les utiliser.

Assurez-vous de comptabiliser les frais de facturation. pour Realtime Database et Cloud Firestore.

Mapper vos données

Les données dans Realtime Database sont structurées comme une arborescence unique, tandis que Cloud Firestore prend en charge des hiérarchies de données plus explicites à travers des documents, des collections et sous-collections. Si vous déplacez certaines de vos données depuis Realtime Database vers Cloud Firestore, vous pouvez envisager d'utiliser une autre architecture pour vos données.

Différences majeures à 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 peu profondes 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êtes offrent une pagination plus robuste.
  • Les transactions n'ont plus besoin d'une racine commune pour toutes vos données et sont plus efficace.
  • Les frais de facturation diffèrent entre le Realtime Database et le Cloud Firestore. Dans de nombreuses cas, Cloud Firestore peut être plus cher que Realtime Database, surtout si vous dépendez de nombreuses opérations mineures. Envisagez d'utiliser en réduisant le nombre d'opérations sur votre base de données et en évitant des écritures inutiles. En savoir plus sur les différences entre billing entre Realtime Database et Cloud Firestore.

Les bonnes pratiques en action

L'exemple suivant reflète certaines des considérations que vous pouvez prendre en compte lorsque vous déplacer vos données entre les bases de données. Profitez de lectures superficielles et d'améliorations des capacités d'interrogation pour des structures de données plus naturelles que celles que vous avez pu utiliser. avec Realtime Database.

Prenons l'exemple d'une application de guide de ville qui aide les utilisateurs à trouver des points de repère importants dans une ville. dans le monde entier. Comme Realtime Database n'a pas de lectures superficielles, vous avez peut-être dû structurer les données dans deux nœuds de niveau supérieur, 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 présente des lectures superficielles, donc l'interrogation des documents d'une collection n'extrait pas les données des sous-collections. Vous pouvez donc stocker des éléments d'informations 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, ce qui est une autre raison de stocker les repères en tant que sous-collection, en réduisant la taille de chaque document de ville plutôt que d'alourdir les documents avec des listes imbriquées.

Les fonctionnalités avancées d'interrogation de Cloud Firestore réduisent le besoin de dupliquer les données pour les modèles d'accès courants. Par exemple, considérons un écran dans L'application City Guide qui montre toutes les capitales classées par population. Dans Realtime Database, le moyen le plus efficace de procéder consiste à conserver liste des capitales qui dupliquent 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 en tant que requête unique:

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

Apprenez-en plus sur le modèle de données Cloud Firestore et effectuez une consultez nos solutions pour découvrir d'autres idées sur la façon de structurer votre Cloud Firestore.

Sécurisez vos données

Que vous utilisiez Cloud Firestore Security Rules pour Clients Android, Apple ou Web, ou Identity Access Management (IAM) pour les serveurs, veillez également à sécuriser vos données dans Cloud Firestore en tant que 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.

Différences majeures à prendre en compte

  • Les SDK pour mobile et pour le Web utilisent Cloud Firestore Security Rules, tandis que les SDK Les SDK utilisent Identity Access Management (IAM) pour sécuriser les données.
  • Les Cloud Firestore Security Rules ne sont pas en cascade, sauf si vous utilisez un caractère générique. 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 l'avez fait dans Realtime Database).
  • Cloud Firestore vérifie les règles avant d'exécuter une requête pour s'assurer que l'utilisateur dispose des droits d'accès appropriés pour 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é aux 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 les données historiques après avoir déplacé votre application depuis Realtime Database à Cloud Firestore, ajoutez une exportation de vos anciennes données vers votre 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 de nouvelles données avec d'anciennes, vous pouvez ajouter votre les données historiques. Si vous ajoutez de nouvelles données aux deux bases de données en même temps, abordés à 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. Exporter vos données depuis Realtime Database ou utilisez une sauvegarde récente.
    1. Accédez au 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 cliquez sur Export JSON (Exporter au format JSON) dans le menu.

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

    Tenez compte des stratégies suivantes lorsque vous transférez certaines de vos données vers Cloud Firestore :

    • Écrivez un script personnalisé qui transfère vos données à votre place. Bien que nous ne puissions pas offrir un modèle pour ce script, car chaque base de données aura des besoins uniques, Experts Cloud Firestore sur notre chaîne Slack ou sur Stack Overflow peut revoir votre script ou vous donner des conseils pour votre situation spécifique.
    • Utilisez les SDK du serveur (Node.js, Java, Python ou Go) pour écrire directement les données. à Cloud Firestore. Pour obtenir des instructions sur la configuration des SDK du serveur, consultez Premiers pas
    • Pour accélérer les migrations de données volumineuses, utilisez écritures par lot et envoyer jusqu'à 500 opérations dans une seule requête réseau.
    • Pour rester en dessous des limites de débit de Cloud Firestore, Limitez les opérations à 500 écritures par seconde pour chaque collection.

Ajouter de nouvelles 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 dans 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 sur toutes les écritures que vous effectuez lors de la migration des données historiques.

Créer 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 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 certains de vos données, assurez-vous de tenir compte des fonctions de mise en miroir de données que vous avez configurez et validez votre Cloud Firestore Security Rules.

  1. Si vous avez utilisé Cloud Functions pour maintenir la parité entre vos bases de données, veillez à ne pas dupliquer les opérations d'écriture sur les deux bases de données en boucle. Changez votre fonction pour écrire dans une seule base de données, ou supprimez le et commencer à abandonner progressivement la fonctionnalité d'écriture données migrées dans les applications toujours associées à Realtime Database. Comment 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. Valider votre Cloud Firestore Security Rules ou la configuration IAM.