Créer des applications évolutives avec Firestore

Ce document explique quand utiliser Firestore pour concevoir des applications volumineuses. Il fournit des solutions aux administrateurs d'infrastructure qui gèrent des systèmes de base de données pour des applications volumineuses. L'utilisation de Firestore avec d'autres produits dans Google Cloud simplifie le provisionnement et la maintenance d'une base de données, ce qui vous permet de vous concentrer sur le développement de votre application plutôt que sur la planification des capacités.

Fonctionnalités et limites de Firestore

Firestore est conçu pour les applications mobiles et Web, et pour stocker des données transactionnelles hiérarchiques avec un schéma flexible et non relationnel. Lorsque vous évaluez Firestore en tant que solution de base de données potentielle, assurez-vous que ses quotas et limites sont adaptés à vos cas d'utilisation. Firestore est polyvalent et applicable dans de nombreuses cas, mais d'autres produits de base de données Google Cloud peuvent mieux convenir à certains scénarios. Lorsque vous décidez d'utiliser Firestore ou une autre solution, tenez compte des facteurs suivants.

Stockage

Firestore peut héberger n'importe quelle quantité de stockage de données. Il traite les quantités de données allant du kilo-octet au pétaoctet de la même manière, sans incidence sur les performances.

Mises à jour en temps réel

Firestore fournit des mises à jour en temps réel en permettant aux clients d'écouter un document et d'utiliser des requêtes pour obtenir des mises à jour en temps réel. Vous fournissez un mécanisme de rappel (callback) qui crée immédiatement un instantané du document avec son contenu actuel. Chaque fois que le contenu du document change, un autre appel met à jour l'instantané.

Persistance des données hors connexion

Firestore assure la persistance des données hors connexion grâce à un fonctionnement hors connexion total pour les clients mobiles et Web. Vous pouvez accéder à vos données et les mettre à jour lorsque vous êtes hors connexion, puis synchroniser automatiquement les modifications dans le cloud lorsque vous êtes de nouveau en ligne. La compatibilité intégrée avec le fonctionnement hors connexion utilise un cache local qui sert à diffuser et stocker les données. Votre application reste donc réactive, indépendamment de la latence du réseau ou de la connectivité Internet.

Transactions

Firestore accepte les transactions multidocuments conformes à la norme ACID. Le terme ACID est l'acronyme de atomicité, cohérence, isolation et durabilité.

Requêtes

Firestore propose des requêtes fortement cohérentes sur l'ensemble de la base de données. Outre les index principaux, Firestore accepte les index secondaires et composites pour rechercher rapidement les emplacements des éléments que vous demandez dans une requête.

Les requêtes Firestore sont limitées comme suit :

  • Firestore est une base de données non relationnelle. Elle ne prend donc pas en charge les schémas relationnels ni les requêtes utilisant la sémantique SQL. En particulier, Firestore n'accepte pas les opérations de jointure, le filtrage des inégalités sur plusieurs propriétés ou le filtrage des données issues des résultats d'une sous-requête.
    • Si votre application nécessite la compatibilité avec SQL pour les échelles non horizontales, utilisez Cloud SQL.
    • Si votre application nécessite la compatibilité avec SQL pour les échelles horizontales et globales plus grandes, utilisez Cloud Spanner.
  • Firestore est optimisé pour le traitement transactionnel en ligne (OLTP, Online Transaction Processing).

Sécurité

Firestore chiffre automatiquement toutes les données avant leur écriture sur le disque. Firestore offre une gestion des accès et une authentification robustes via les méthodes suivantes, en fonction des bibliothèques clientes que vous utilisez :

Autoscaling

Firestore effectue automatiquement un scaling à la hausse, sans temps d'arrêt. Ce mécanisme de scaling permet à Firestore de traiter des milliers de requêtes par seconde et des millions de connexions simultanées. Vous ne payez que pour votre utilisation réelle en fonction de la taille de stockage et du nombre d'opérations. Pour en savoir plus, consultez les tarifs de Firestore.

La fonctionnalité d'autoscaling de Firestore présente les limites suivantes :

  • Firestore en mode natif peut étendre les opérations de mise à jour de document jusqu'à 10 000 écritures par seconde et plus d'un million de connexions. Si votre application dépasse ces limites de vitesse d'écriture, nous vous recommandons d'utiliser le mode Datastore, qui effectue un scaling jusqu'à plusieurs millions d'écritures par seconde. Pour en savoir plus sur les différences entre ces modes, consultez la page Choisir entre le mode natif et le mode Datastore.
  • Firestore peut gérer des opérations à très grande échelle. Toutefois, pour prendre en charge des fonctionnalités complexes telles que la réplication et les transactions, Firestore applique certains compromis susceptibles de ralentir les performances des applications censées supporter des charges extrêmes.
    • Si votre application est extrêmement lourde en écriture, envisagez d'utiliser Cloud Bigtable pour améliorer les capacités d'ingestion de données au détriment des transactions et des index secondaires.
    • Si votre application affiche souvent les mêmes informations aux utilisateurs, comme le classement des joueurs dans les jeux vidéo, envisagez la mise en cache côté client pour réduire la charge en évitant l'envoi de requêtes inutiles au serveur.

Latence

Firestore donne la priorité à la durabilité et à la disponibilité plutôt qu'à la latence en effectuant des écritures synchrones entre régions ou entre zones. Si votre application requiert une latence cohérente inférieure à 10 millisecondes lors de la lecture ou de l'écriture de données, envisagez d'utiliser une base de données en mémoire telle que Memorystore pour Redis.

Redondance et disponibilité

Firestore offre les niveaux de redondance multi-emplacement suivants, basés sur différents mécanismes de réplication :

  • La réplication régionale est préférable si votre priorité est d'atteindre une faible latence en écriture. Lorsque vous utilisez la réplication régionale, les données sont dupliquées dans la même région. Pour garantir une latence minimale, vous pouvez cohéberger votre application dans la même région.
  • La réplication multirégionale est préférable si votre priorité est de garantir la disponibilité. Lorsque vous utilisez la réplication multirégionale, les données sont répliquées dans plusieurs zones d'au moins deux régions différentes, ce qui rend la base de données résiliente aux pannes régionales. La réplication multirégionale offre une disponibilité et une redondance accrues, mais elle entraîne également une latence en écriture plus élevée. Un nœud témoin est déployé dans une troisième région pour départager les deux régions répliquées, comme l'illustre la figure 1.

Schéma de réplication d'une base de données multirégionale.

Figure 1 : Schéma d'une base de données multirégionale dans Firestore.

Bibliothèques clientes

Les clients Web et mobiles peuvent accéder directement à Firestore à l'aide des bibliothèques clientes Android, iOS ou Web. Firestore s'intègre également parfaitement à la plate-forme Firebase, qui fournit des fonctionnalités telles que la création de rapports d'erreur, l'authentification des utilisateurs, la distribution des messages et l'analyse des événements utilisateur.

Quand utiliser Firestore ?

Les fonctionnalités de Firestore conviennent à un large éventail de cas d'utilisation, y compris :

  • Profils utilisateur : gérez des profils utilisateur pour personnaliser l'expérience d'un utilisateur en fonction de ses activités et préférences. Le schéma flexible de Firestore vous permet de faire évoluer la structure des profils utilisateur. Par exemple, vous pouvez ajouter de nouvelles propriétés pour permettre l'installation de nouvelles fonctionnalités dans votre application. Les modifications de schéma se produisent sans temps d'arrêt et les performances ne se dégradent pas, même si le nombre d'utilisateurs augmente.
  • Inventaires en temps réel : grâce aux objets riches et imbriqués de Firestore, stockez de grandes quantités de données creuses et non homogènes pour divers produits sans trop spécialiser la structure. Par exemple, vous pouvez créer un catalogue de produits pour un revendeur.
  • Gestion des sessions utilisateur : la compatibilité de Firestore avec les transactions ACID permet de garantir que les utilisateurs peuvent verrouiller un ou plusieurs documents jusqu'à la fin de leur transaction. Par exemple, vous pouvez créer des paniers d'achat pour les transactions de commerce, ou un formulaire de réservation d'événements comportant plusieurs parties.
  • Mutations d'état : utilisez les transactions ACID de Firestore pour propager des mutations entre un grand nombre d'utilisateurs simultanés. Par exemple, vous pouvez maintenir un état cohérent pour tous les joueurs d'une application de jeu vidéo.
  • Cache d'écriture persistant : la haute disponibilité et la durabilité de Firestore fournissent un état persistant et empêchent les pertes de données potentielles causées par un plantage de l'application. Firestore propose des fonctionnalités telles qu'un magasin de clés-valeurs simple à utiliser. Toutefois, Firestore ne dispose pas d'un mécanisme intégré d'expiration du cache ou de valeur TTL (Time to Live).
  • Synchronisation de données multi-appareils : les mises à jour en temps réel de Firestore garantissent que tous les appareils connectés affichent toujours le dernier état. Par exemple, Firestore fournit un état cohérent pour les applications mobiles collaboratives multi-utilisateurs et les applications auxquelles vous vous connectez depuis plusieurs appareils.
  • Gestion IoT et suivi des ressources : la persistance des données hors connexion de Firestore vous permet d'enregistrer des points de données même lorsque les appareils perdent la connectivité réseau. Par exemple, vous pouvez configurer un suivi GPS en temps réel des appareils mobiles et des véhicules.
  • Fonctionnalités en temps réel : les mises à jour en temps réel de Firestore vous permettent de configurer une messagerie et une analyse en temps réel. Vous pouvez tenir à jour les graphiques visuels, tels que les tableaux de bord visuels interactifs, et configurer des forums et salons de discussion en direct.
  • Compteurs distribués : configurez des compteurs distribués pour afficher les interactions avec les documents, comme le nombre de mentions "J'aime" pour un post ou l'ajout d'un élément spécifique aux favoris.

Architectures de référence

Cette section fournit des architectures de référence pour la création d'applications Web volumineuses combinant Firestore et d'autres produits Google Cloud, par exemple :

  • Exportations quotidiennes
  • Cache
  • Traitement des données
  • Modèles d'entraînement pour le machine learning

Ces architectures ne sont pas normatives. Au lieu de cela, elles mettent en évidence l'étendue des utilisations possibles de Firestore pour la création d'applications Web évolutives. Vous pouvez réorganiser et adapter les architectures pour créer votre propre application Web répondant à vos besoins.

Jeux

Une plate-forme de jeux vidéo permet l'accès simultané par des dizaines de milliers de joueurs. Les services frontend du jeu utilisent Firestore pour stocker des milliards de documents avec des données hiérarchiques sur l'état du monde du jeu. Firestore contient également des données utilisateur telles que la configuration des utilisateurs, les membres de groupes, les guildes, les listes d'amis et les données de présence. Ce cas d'utilisation intègre d'autres produits Google Cloud comme suit :

  • Spanner fournit une base de données cohérente à l'échelle mondiale qui peut conserver l'inventaire ou l'historique des matchs pour des populations massives de joueurs n'importe où dans le monde.
  • Un cache en mémoire régional est déployé sur Memorystore pour Redis afin d'accélérer l'accès aux données fréquemment utilisées.
  • Les événements sont consignés dans Cloud Bigtable, où les développeurs ou l'équipe d'assistance peuvent y accéder à des fins de dépannage.
  • Les données des bases de données frontend et backend sont régulièrement importées dans BigQuery pour exécuter des pipelines d'analyse de données. Ces pipelines permettent de découvrir certaines failles ou mécanismes de jeu qui nécessitent une mise à jour avant que leur effet sur la communauté du jeu ne provoque le départ des joueurs.

La figure 2 illustre l'architecture du cas d'utilisation dans le domaine des jeux vidéo :

Architecture du cas d'utilisation dans le domaine des jeux vidéo.

Figure 2. Exemple d'architecture d'une plate-forme de jeux vidéo.

Internet des objets

Une application Web interactive affiche des informations de télémétrie en temps réel générées par des appareils IoT (Internet des objets). Ces appareils mesurent et collectent régulièrement la température et la fréquence cardiaque de l'utilisateur, puis traitent les données comme suit :

  1. Chaque mesure est envoyée instantanément à IoT Core via des ponts MQTT et HTTP.
  2. IoT Core publie chaque mesure en tant que message individuel dans Pub/Sub.
  3. Le message Pub/Sub déclenche des fonctions Cloud Functions qui extraient les informations pertinentes des messages bruts et enregistrent les résultats dans Firestore pour un stockage à long terme.
  4. Une interface utilisateur Web interactive hébergée sur Firebase Hosting et fournie par Angular écoute les mises à jour directement depuis Firestore. Chaque mise à jour est automatiquement transférée à l'interface utilisateur Web pour visualiser les informations les plus récentes en temps réel.

La figure 3 illustre le pipeline de données utilisé pour les informations de télémétrie dans ce scénario :

Architecture du cas d'utilisation d'une application IoT.

Figure 3. Exemple d'architecture d'une application IoT.

Commerce

Une plate-forme de commerce propose des recommandations de produits aux nouveaux acheteurs via différents supports. Une application Web enregistre des points de données en direct sur les utilisateurs en ligne, tels que l'URL de provenance, la région géographique et le type d'appareil, puis écrit les données collectées dans Firestore comme suit :

  1. Chaque création d'un enregistrement déclenche un pipeline de données dans Cloud Functions qui copie les données utilisateur vers BigQuery.
  2. Un moteur de recommandations, mis en œuvre avec Spark MLlib et déployé sur Dataproc, est entraîné avec les données utilisateur en direct stockées dans BigQuery ainsi qu'avec les métadonnées de produits stockées dans Cloud SQL.
  3. Le moteur de recommandations fournit les prédictions suivantes pour les produits recommandés :
    • Prédictions en temps réel écrites dans Firestore et transférées automatiquement aux appareils des utilisateurs en ligne.
    • Prédictions par lots envoyées à des utilisateurs hors connexion par un service de messagerie.

La figure 4 illustre le flux de données pour le scénario d'une plate-forme de commerce :

Architecture du cas d'utilisation d'une plate-forme de commerce.

Figure 4. Exemple d'architecture d'une plate-forme de commerce.

Capture en temps réel des modifications des données

Une application reçoit une entrée utilisateur en temps réel qui modifie l'état global. Un tableau de bord dans Data Studio suit les événements en temps réel afin de mieux comprendre le comportement et les interactions des utilisateurs. Lorsque l'action d'un utilisateur met à jour une valeur d'état, les événements suivants se produisent :

  1. Firestore déclenche une fonction Cloud qui écrit la modification dans BigQuery, y compris les ancienne et nouvelle valeurs d'état.
  2. Le tableau de bord Data Studio exécute des requêtes d'agrégation en temps réel sur les données d'événements dans BigQuery.
  3. Les requêtes génèrent des métriques telles que le taux de modifications d'événements agrégées aux différents buckets, le type unique d'événements par bucket temporel et la latence d'ingestion des événements.

Pour obtenir une présentation détaillée et une démonstration de cette architecture, regardez la vidéo Cloud Next 2019 intitulée Building amazing apps With Firestore (Créer des applications exceptionnelles avec Firestore).

La figure 5 illustre l'architecture pour la capture des modifications de données en temps réel :

Architecture du cas d'utilisation de capture de données.

Figure 5. Exemple d'architecture simple de capture de données.

Édition collaborative de contenu

Un système de gestion de contenu (CMS, Content Management System) collaboratif permet à plusieurs éditeurs de travailler simultanément sur le même article. Chaque fois qu'un éditeur effectue une modification, par exemple pour ajouter ou supprimer un caractère, le client de l'éditeur envoie la modification directement à Firestore.

Si plusieurs éditeurs envoient des modifications en même temps, le processus de résolution suivant se produit :

  1. Les transactions de Firestore garantissent que seule la première modification reçue est écrite dans la base de données. Les autres modifications sont rejetées.
  2. Firestore envoie automatiquement le contenu mis à jour à tous les éditeurs.
  3. Les éditeurs dont l'envoi a été initialement rejeté réappliquent leurs modifications sur le contenu mis à jour, puis les renvoient à Firestore.
  4. Le même processus de résolution des conflits se répète jusqu'à ce que toutes les modifications apportées par l'ensemble des clients soient acceptées et écrites dans la base de données.

Un pipeline de préproduction permet aux éditeurs de prévisualiser le contenu comme suit :

  1. Une tâche Cron hébergée sur Cloud Scheduler déclenche une fonction Cloud toutes les secondes.
  2. La fonction copie le contenu le plus récent depuis Firestore vers la base de données de préproduction hébergée sur Cloud SQL.
  3. Les éditeurs prévisualisent le contenu en préproduction sur le serveur de préproduction hébergé sur App Engine.

Une fois que le contenu est prêt, un éditeur clique sur le bouton "Publier" dans le CMS. Cette action déclenche une fonction Cloud qui copie le contenu le plus récent depuis Firestore vers la base de données de production hébergée sur Cloud SQL. Les lecteurs peuvent ensuite consulter le contenu nouvellement publié sur le site Web de production. Pour obtenir un exemple concret de cette architecture, consultez l'article du New York Times intitulé We Built Collaborative Editing for Our Newsroom's CMS (Nous avons créé une édition collaborative pour le système de gestion de contenu de notre rédaction).

La figure 6 illustre le pipeline pour l'édition, la préproduction et la publication de contenu dans le cas d'utilisation de l'édition collaborative de contenu :

Architecture du cas d'utilisation de l'édition de contenu.

Figure 6. Exemple d'architecture d'une plate-forme d'édition collaborative de contenu.

Étapes suivantes