Comprendre les requêtes en temps réel à grande échelle

Lisez ce document pour obtenir des conseils sur le scaling de votre application sans serveur au-delà de milliers d'opérations par seconde ou de centaines de milliers d'utilisateurs simultanés. Ce document aborde des sujets avancés pour vous aider à comprendre le système en profondeur. Si vous débutez avec Cloud Firestore, consultez plutôt le guide de démarrage rapide.

Cloud Firestore et les SDK Firebase pour mobile/Web fournissent un modèle puissant pour développer des applications sans serveur dans lesquelles le code côté client accède directement à la base de données. Les SDK permettent aux clients d'écouter les mises à jour des données en temps réel. Vous pouvez utiliser des mises à jour en temps réel pour créer des applications réactives qui ne nécessitent pas d'infrastructure de serveur. Bien qu'il soit très facile de mettre en place une application, il est utile de comprendre les contraintes des systèmes qui composent Cloud Firestore afin que votre application sans serveur évolue et fonctionne correctement lorsque le trafic augmente.

Consultez les sections suivantes pour obtenir des conseils sur le scaling de votre application.

Choisir un emplacement de base de données proche de vos utilisateurs

Le schéma suivant illustre l'architecture d'une application en temps réel :

Lorsqu'une application exécutée sur l'appareil d'un utilisateur (mobile ou Web) établit une connexion à Cloud Firestore, la connexion est acheminée vers un Cloud Firestore serveur frontend dans la même région que celle où se trouve votre base de données. Par exemple, si votre base de données se trouve dans us-east1, la connexion est également acheminée vers un Cloud Firestore frontend dans us-east1. Ces connexions sont durables et restent ouvertes jusqu'à ce qu'elles soient explicitement fermées par l'application. Le frontend lit les données des systèmes de stockage Cloud Firestore sous-jacents.

La distance entre l'emplacement physique d'un utilisateur et l'emplacement de la Cloud Firestore base de données affecte la latence perçue par l'utilisateur. Par exemple, un utilisateur en Inde dont l'application communique avec une base de données dans une région Google Cloud en Amérique du Nord peut constater que l'expérience est plus lente et que l'application est moins réactive que si la base de données était située plus près, par exemple en Inde ou dans une autre partie de l'Asie.

Concevoir des solutions fiables

Les sujets suivants améliorent ou affectent la fiabilité de votre application :

Activer le mode hors connexion

Les SDK Firebase assurent la persistance des données hors connexion. Si l' application sur l'appareil de l'utilisateur ne peut pas se connecter à Cloud Firestore, elle reste utilisable en fonctionnant avec les données mises en cache localement. Cela garantit l'accès aux données même lorsque les utilisateurs rencontrent des problèmes de connexion Internet ou perdent complètement l'accès pendant plusieurs heures ou jours. Pour en savoir plus sur le mode hors connexion, consultez Activer les données hors connexion.

Comprendre les nouvelles tentatives automatiques

Les SDK Firebase se chargent de réessayer les opérations et de rétablir les connexions interrompues. Cela permet de contourner les erreurs temporaires causées par le redémarrage des serveurs ou les problèmes de réseau entre le client et la base de données.

Choisir entre des emplacements régionaux et multirégionaux

Le choix entre des emplacements régionaux et multirégionaux présente plusieurs compromis. La principale différence réside dans la façon dont les données sont répliquées. Cela détermine les garanties de disponibilité de votre application. Une instance multirégionale offre une fiabilité de diffusion plus élevée et augmente la durabilité de vos données, mais le compromis est le coût.

Comprendre le système de requêtes en temps réel

Les requêtes en temps réel, également appelées écouteurs d'instantanés, permettent à l'application d'écouter les modifications apportées à la base de données et de recevoir des notifications à faible latence dès que les données changent. Une application peut obtenir le même résultat en interrogeant périodiquement la base de données pour obtenir des mises à jour, mais cette méthode est souvent plus lente, plus coûteuse et nécessite plus de code. Pour obtenir des exemples de configuration et d'utilisation des requêtes en temps réel, consultez Obtenir des mises à jour en temps réel. Les sections suivantes expliquent en détail le fonctionnement des écouteurs d'instantanés et décrivent certaines des bonnes pratiques pour mettre à l'échelle les requêtes en temps réel tout en conservant les performances.

Imaginez deux utilisateurs qui se connectent à Cloud Firestore via une application de messagerie créée avec l'un des SDK pour mobile.

Le client A écrit dans la base de données pour ajouter et mettre à jour des documents dans une collection appelée chatroom :

collection chatroom:
    document message1:
      from: 'Sparky'
      message: 'Welcome to Cloud Firestore!'

    document message2:
      from: 'Santa'
      message: 'Presents are coming'

Le client B écoute les mises à jour dans la même collection à l'aide d'un écouteur d'instantanés. Le client B reçoit une notification immédiate chaque fois que quelqu'un crée un message. Le diagramme suivant illustre l'architecture d'un écouteur d'instantanés :

La séquence d'événements suivante se produit lorsque le client B connecte un écouteur d'instantanés à la base de données :

1. Le client B ouvre une connexion à Cloud Firestore et enregistre un écouteur en appelant onSnapshot(collection("chatroom")) via le SDK Firebase. Cet écouteur peut rester actif pendant des heures.
2. Le Cloud Firestore frontend interroge le système de stockage sous-jacent pour amorcer l'ensemble de données. Il charge l'ensemble des résultats des documents correspondants. Nous appelons cela une requête d'interrogation. Le système évalue ensuite les règles de sécurité Firebase de la base de données pour vérifier que l'utilisateur peut accéder à ces données. Si l'utilisateur est autorisé, la base de données lui renvoie les données.
3. La requête du client B passe ensuite en mode écoute. L'écouteur s'enregistre auprès d'un gestionnaire d'abonnements et attend les mises à jour des données.
4. Le client A envoie maintenant une opération d'écriture pour modifier un document.
5. La base de données valide la modification du document dans son système de stockage.
6. De manière transactionnelle, le système valide la même mise à jour dans un journal des modifications interne. Le journal des modifications établit un ordre strict des modifications au fur et à mesure qu'elles se produisent.
7. Le journal des modifications distribue à son tour les données mises à jour à un pool de gestionnaires d'abonnements.
8. Un moteur de correspondance de requêtes inversées s'exécute pour vérifier si le document mis à jour correspond à des écouteurs d'instantanés actuellement enregistrés. Dans cet exemple, le document correspond à l'écouteur d'instantanés du client B. Comme son nom l'indique, vous pouvez considérer le moteur de correspondance de requêtes inversées comme une requête de base de données normale, mais effectuée en sens inverse. Au lieu de rechercher des documents correspondant à une requête, il recherche efficacement des requêtes correspondant à un document entrant. Lorsqu'il trouve une correspondance, le système transfère le document en question aux écouteurs d'instantanés. Le système évalue ensuite les règles de sécurité Firebase de la base de données pour s'assurer que seuls les utilisateurs autorisés reçoivent les données.
9. Le système transfère la mise à jour du document au SDK sur l'appareil du client B, et le rappel onSnapshot se déclenche. Si la persistance locale est activée, le SDK applique également la mise à jour au cache local.

Un élément clé de Cloud Firestore's évolutivité dépend de la distribution ramifiée de le journal des modifications aux gestionnaires d'abonnements et aux serveurs frontend. La distribution ramifiée permet à une seule modification de données de se propager efficacement pour traiter des millions de requêtes en temps réel et d'utilisateurs connectés. En exécutant de nombreuses instances dupliquées de tous ces composants sur plusieurs zones (ou plusieurs régions dans le cas d'un déploiement multirégional ), Cloud Firestore atteint une haute disponibilité et une évolutivité élevée.

Il est important de noter que toutes les opérations de lecture émises à partir des SDK pour mobile et Web suivent le modèle ci-dessus. Elles effectuent une requête d'interrogation suivie d'un mode écoute pour maintenir les garanties de cohérence. Cela s'applique également aux écouteurs en temps réel, aux appels permettant de récupérer un document et aux requêtes uniques. Vous pouvez considérer les récupérations de documents uniques et les requêtes uniques comme des écouteurs d'instantanés de courte durée qui présentent des contraintes similaires en termes de performances.

Appliquer les bonnes pratiques pour mettre à l'échelle les requêtes en temps réel

Appliquez les bonnes pratiques suivantes pour concevoir des requêtes en temps réel évolutives.

Comprendre le trafic d'écriture élevé dans le système

Cette section vous aide à comprendre comment le système répond à un nombre croissant de requêtes d'écriture.

Les journaux des modifications Cloud Firestore qui gèrent les requêtes en temps réel évoluent automatiquement à l'horizontale à mesure que le trafic d'écriture augmente. Lorsque le taux d'écriture d'une base de données dépasse ce qu'un seul serveur peut gérer, le journal des modifications est divisé sur plusieurs serveurs, et le traitement des requêtes commence à consommer des données provenant de plusieurs gestionnaires d'abonnements au lieu d'un seul. Du point de vue du client et du SDK, tout cela est transparent et aucune action n'est requise de la part de l'application lorsque des divisions se produisent. Le diagramme suivant illustre la mise à l'échelle des requêtes en temps réel :

Le scaling automatique vous permet d'augmenter votre trafic d'écriture sans limite, mais à mesure que le trafic augmente, le système peut mettre un certain temps à répondre. Suivez les recommandations de la règle des 5-5-5 pour éviter de créer un hotspot d'écriture. Key Visualizer est un outil utile pour analyser les hotspots d'écriture.

De nombreuses applications connaissent une croissance organique prévisible, que Cloud Firestore peut gérer sans précautions. Toutefois, les charges de travail par lot, comme l'importation d'un grand ensemble de données, peuvent augmenter trop rapidement les écritures. Lorsque vous concevez votre application, soyez attentif à la provenance de votre trafic d'écriture.

Comprendre l'interaction entre les écritures et les lectures

Vous pouvez considérer le système de requêtes en temps réel comme un pipeline connectant les opérations d'écriture aux lecteurs. Chaque fois qu'un document est créé, mis à jour ou supprimé, la modification se propage du système de stockage aux écouteurs actuellement enregistrés. La structure du journal des modifications de Cloud Firestore's garantit une cohérence forte, ce qui signifie que votre application ne reçoit jamais de notifications de mises à jour qui ne sont pas dans l'ordre par rapport au moment où la base de données a validé les modifications de données. Cela simplifie le développement d'applications en supprimant les cas extrêmes liés à la cohérence des données.

Ce pipeline connecté signifie qu'une opération d'écriture entraînant des hotspots ou une contention de verrouillage peut avoir un impact négatif sur les opérations de lecture. Lorsque les opérations d'écriture échouent ou sont limitées, une lecture peut être bloquée en attendant des données cohérentes du journal des modifications. Si cela se produit dans votre application, vous pouvez constater à la fois des opérations d'écriture lentes et des temps de réponse lents corrélés pour les requêtes. Éviter les hotspots est essentiel pour éviter ce problème.

Réduire la taille des documents et des opérations d'écriture

Lorsque vous créez des applications avec des écouteurs d'instantanés, vous souhaitez généralement que les utilisateurs soient informés rapidement des modifications de données. Pour ce faire, essayez de réduire la taille des éléments. Le système peut transmettre très rapidement de petits documents contenant des dizaines de champs. Le traitement des documents plus volumineux contenant des centaines de champs et de grandes quantités de données prend plus de temps.

De même, privilégiez les opérations de validation et d'écriture courtes et rapides pour maintenir une faible latence. Les grands lots peuvent vous offrir un débit plus élevé du point de vue de l'auteur, mais peuvent en fait augmenter le temps de notification des écouteurs d'instantanés. Cela est souvent contre-intuitif par rapport à l'utilisation d'autres systèmes de base de données dans lesquels vous pouvez utiliser le traitement par lot pour améliorer les performances.