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 des centaines de milliers d'utilisateurs simultanés. Ce document aborde des sujets avancés à comprendre en profondeur le système. Si vous débutez avec Firestore, consultez plutôt le guide de démarrage rapide.

Firestore et les SDK mobiles/Web Firebase constituent un modèle puissant pour développer des applications sans serveur où le code côté client accède directement base de données. Les SDK permettent aux clients d'écouter les mises à jour des données en temps réel. Toi peuvent utiliser des mises à jour en temps réel pour créer des applications réactives qui ne nécessitent pas de serveurs de l'infrastructure. Bien qu'il soit très facile de mettre en œuvre quelque chose, cela aide pour comprendre les contraintes des systèmes qui composent 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.

Choisissez un emplacement de base de données à proximité de vos utilisateurs

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

Exemple d'architecture d'application en temps réel

Lorsqu'une application exécutée sur l'appareil d'un utilisateur (mobile ou Web) établit une connexion à Firestore, la connexion est acheminée vers serveur frontend Firestore dans le même région 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 Interface Firestore, également dans us-east1. Ces connexions sont et restent ouverts jusqu'à ce qu'ils soient explicitement fermés par l'application. La lit les données des systèmes de stockage Firestore sous-jacents.

La distance entre l'emplacement physique d'un utilisateur et Firestore l'emplacement de la base de données a une incidence sur la latence observée 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 trouver l'expérience plus lente et l'application moins rapide que si la base de données était plus proche, comme 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 le l'application sur l'appareil de l'utilisateur ne peut pas se connecter à Firestore, l'application reste utilisable en travaillant avec des données mises en cache localement. Cela garantit que les données même lorsque les utilisateurs ont des connexions Internet instables ou l’accès pendant plusieurs heures ou jours. Pour en savoir plus sur mode hors connexion, consultez la section Activer les données hors connexion.

Comprendre les nouvelles tentatives automatiques

Les SDK Firebase se chargent de relancer les opérations et de rétablir les connexions interrompues. Cela permet de contourner les erreurs temporaires en redémarrant les serveurs ou en rencontrant des problèmes de réseau entre le client base de données.

Choisir un emplacement régional ou multirégional

Il y a plusieurs compromis au moment de choisir entre une région et multirégionaux. La principale différence réside dans la façon dont les données sont répliquées. Ce garantit les garanties de disponibilité de votre application. Une instance multirégionale permet une diffusion plus fiable 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 modifications de la base de données et vous recevez des notifications à faible latence dès que les données des modifications. Une application peut obtenir le même résultat en interrogeant régulièrement la base de données pour déterminer mises à jour, mais il est souvent plus lent, plus cher et nécessite plus de code. Pour des exemples de configuration et d'utilisation de requêtes en temps réel, consultez Obtenez des informations en temps réel. Les sections suivantes le fonctionnement des écouteurs d'instantanés, pour faire évoluer les requêtes en temps réel tout en préservant les performances.

Imaginez que deux utilisateurs se connectent à Firestore via un réseau conçue 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é chatroom:

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

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

Le client B écoute les mises à jour de la même collection à l'aide d'un écouteur d'instantanés. Le client B reçoit une notification immédiate chaque fois qu'un nouveau message est créé. Le schéma suivant illustre l'architecture derrière un écouteur d'instantanés:

Architecture d'une connexion d'écouteur d'instantanés

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

  1. Le client B ouvre une connexion à Firestore et enregistre un l'écouteur en appelant onSnapshot(collection("chatroom")) via le SDK Firebase. Cet écouteur peut rester actif pendant des heures.
  2. L'interface Firestore interroge le système de stockage sous-jacent pour amorcer l'ensemble de données. Elle charge l'ensemble des résultats documents. C'est ce que nous appelons une requête d'interrogation. Le système qui évalue la capacité de la base de données Règles de sécurité Firebase pour vérifier que l'utilisateur peut accéder à ces données. Si l'utilisateur est autorisé, renvoie les données à l'utilisateur.
  3. La requête du client B passe alors en mode écoute. L'écouteur s'enregistre avec un gestionnaire d'abonnement et attend les mises à jour des données.
  4. Le client A envoie désormais une opération d'écriture pour modifier un document.
  5. La base de données valide la modification du document système de stockage.
  6. Sur le plan transactionnel, le système valide la même mise à jour le journal des modifications. Le journal de modifications établit un ordre strict des modifications quand elles se produisent.
  7. Le journal des modifications distribue ensuite les données mises à jour à un pool d'abonnements. gestionnaires.
  8. Un outil de mise en correspondance des requêtes inverse s'exécute pour voir si le document mis à jour correspond les é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 penser à l'outil de mise en correspondance des requêtes inverse comme une requête de base de données normale, mais dans l'inverse. Au lieu de parcourir les documents pour trouver ceux qui correspondent à une requête, il effectue une recherche efficace pour trouver celles qui correspondent à un document entrant. Après avoir trouvé une correspondance, le système transmet 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 vous 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. 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 l'évolutivité de Firestore dépend de la distribution ramifiée le journal des modifications vers les gestionnaires d'abonnement et les serveurs frontend. La la distribution ramifiée permet de propager efficacement une seule modification de données afin de desservir des millions de des requêtes en temps réel et des utilisateurs connectés. En exécutant de nombreuses instances répliquées dans plusieurs zones (ou plusieurs régions dans le cas d'un emplacement déploiement), Firestore offre une haute disponibilité et une évolutivité.

Notez que toutes les opérations de lecture provenant des SDK mobiles et Web suivez le modèle ci-dessus. Ils effectuent une requête d'interrogation suivie du mode écoute. pour maintenir les garanties de cohérence. Cela s'applique également aux écouteurs en temps réel, pour récupérer un document requêtes ponctuelles. Vous pouvez penser à les récupérations de documents et les requêtes one-shot en tant qu'écouteurs d'instantanés à courte durée de vie s'accompagnent de contraintes similaires en termes de performances.

Appliquer les bonnes pratiques pour le scaling des 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éagit à une augmentation le nombre de requêtes d'écriture.

Les journaux de modifications Firestore qui pilotent les requêtes en temps réel automatiquement à mesure que le trafic d'écriture augmente. Comme 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 réparti sur plusieurs serveurs, et le traitement de la requête commence consommer les données de plusieurs gestionnaires d'abonnement au lieu d'un seul. Depuis l' du point de vue du client et du SDK, tout est transparent, et aucune action n'est requise. de l'application en cas de fractionnement. Le schéma suivant montre comment des requêtes en temps réel:

Architecture de la distribution ramifiée des journaux de modifications

Le scaling automatique vous permet d'augmenter votre trafic en écriture sans limite, mais au fur et à mesure que le trafic augmente, le système peut mettre un certain temps à répondre. Suivez les recommandations de la règle 5-5-5 pour éviter de créer une zone cliquable d'écriture. Key Visualizer est utile pour analyser les zones cliquables d'écriture.

De nombreuses applications ont une croissance organique prévisible, ce que Firestore peut sans précautions. Les charges de travail par lot, comme l'importation de votre ensemble de données, peut augmenter trop rapidement les écritures. Lorsque vous concevez votre application, de l'origine de votre trafic d'écriture.

Comprendre comment les écritures et les lectures interagissent

Le système de requête en temps réel est un peu comme un pipeline avec les lecteurs. Chaque fois qu'un document est créé, mis à jour ou supprimé, la modification est propagée du système de stockage vers l'emplacement actuellement enregistré pour les auditeurs. La structure du journal de modifications de Firestore garantit la cohérence, ce qui signifie que votre application ne reçoit jamais de notifications mises à jour dans le désordre par rapport au moment où la base de données a validé les données des modifications. Cela simplifie le développement d'applications en supprimant concernant la cohérence des données.

Ce pipeline connecté signifie qu'une opération d'écriture entraîne des hotspots ou un conflit de verrouillage peuvent affecter négativement les opérations de lecture. Lorsque les opérations d'écriture échouent ou subissent une limitation, une opération de lecture peut qui attend des données cohérentes du journal de modifications. Si cela se produit dans votre application, vous pouvez voir à la fois des opérations d'écriture lentes et des réponses lentes corrélées. pour les requêtes. Il est essentiel d'éviter les hotspots pour éviter cela. problème.

Limitez 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 rapidement des changements de données. Pour ce faire, essayez de garder les choses petites. La peut transmettre à travers le système de petits documents contenant des dizaines de champs rapidement. Les documents volumineux comportant des centaines de champs et des données volumineuses prennent plus de temps à traiter.

De même, privilégiez les opérations de validation et d'écriture courtes et rapides pour maintenir une latence faible. Les lots volumineux peuvent vous donner un débit plus élevé du point de vue du rédacteur. mais peut augmenter le délai de notification pour les écouteurs d'instantanés. Cela est souvent paradoxal par rapport à l'utilisation d'autres systèmes de base de données où vous pouvez utiliser le traitement par lot pour améliorer les performances.

Utiliser des écouteurs efficaces

À mesure que les taux d'écriture de votre base de données augmentent, Firestore répartit le traitement des données sur plusieurs serveurs. L'algorithme de segmentation de Firestore tente de colocaliser les données même collection ou groupe de collections sur le même serveur de journaux de modifications. La le système tente de maximiser le débit d'écriture possible tout en conservant le nombre de serveurs impliqués dans le traitement d'une requête aussi faible que possible.

Toutefois, certains schémas peuvent encore entraîner un comportement non optimal pour l'instantané pour les auditeurs. Par exemple, si votre application stocke la plupart de ses données dans un grand l'écouteur peut avoir besoin de se connecter à plusieurs serveurs pour recevoir dont elle a besoin. Cela reste vrai même si vous appliquez un filtre de requête. Connexion... sur de nombreux serveurs augmente le risque de réponses plus lentes.

Pour éviter ces réponses plus lentes, concevez votre schéma et votre application de sorte que le système peuvent servir des écouteurs sans passer sur de nombreux serveurs différents. Cela pourrait fonctionner mieux de diviser vos données en plus petites collections avec des taux d'écriture plus faibles.

Cela s'apparente à une réflexion sur les requêtes axées sur les performances dans une base de données relationnelle nécessitant des analyses complètes de table. Dans une relation base de données, une requête nécessitant une analyse complète de la table équivaut à écouteur d'instantanés qui surveille une collection dont la perte d'utilisateurs est élevée. Son fonctionnement peut être lent par rapport à une requête que la base de données peut servir à l'aide d'un index plus spécifique. Une requête avec un index plus spécifique s'apparente à un écouteur d'instantanés qui surveille une document unique ou une collection qui change moins souvent. Vous devez charger tester votre application pour mieux comprendre le comportement et les besoins de votre cas d'utilisation.

Accélérez les requêtes de sondage

Un autre élément clé des requêtes réactives en temps réel consiste à s'assurer que d'interrogation pour amorcer les données est rapide et efficace. La première fois qu'un nouvel écouteur d'instantanés se connecte, il doit charger la classe l'ensemble complet de résultats et l'envoyer à l'appareil de l'utilisateur. Des requêtes lentes rendent votre application moins réactives. Cela inclut, par exemple, les requêtes essayez de lire de nombreux documents ou requêtes qui n’utilisent pas les index appropriés.

Un écouteur peut également passer d'un état d'écoute à un état d'interrogation dans certaines circonstances. Cela se fait automatiquement et est transparent pour SDK et votre application. Les conditions suivantes peuvent déclencher un état d'interrogation:

  • Le système rééquilibre un journal de modifications en fonction des variations de la charge.
  • Les points d'accès entraînent des échecs ou des retards d'écriture dans la base de données.
  • Les redémarrages temporaires du serveur affectent temporairement les écouteurs.

Si vos requêtes d'interrogation sont suffisamment rapides, l'état d'interrogation devient transparent. aux utilisateurs de votre application.

Privilégier les auditeurs de longue durée

Ouvrir et maintenir les auditeurs en vie le plus longtemps possible est souvent le plus économique de créer une application qui utilise Firestore. Lorsque vous utilisez Firestore, les documents renvoyés à votre application vous sont facturés et non pour maintenir une connexion ouverte. Un écouteur d'instantanés de longue durée lit uniquement les données dont il a besoin pour traiter la requête tout au long de sa durée de vie. Ce comprend une opération d'interrogation initiale, suivie de notifications lorsque les données change réellement. Les requêtes ponctuelles, quant à elles, relisez les données qui peuvent n'ont pas changé depuis la dernière exécution de la requête par l'application.

Si votre application doit consommer un taux élevé de données, les écouteurs d'instantanés pourrait ne pas être approprié. Par exemple, si votre cas d'utilisation transmet de nombreux documents par seconde via une connexion pendant une longue période, il peut il est préférable d'opter pour des requêtes ponctuelles qui s'exécutent à une fréquence plus faible.

Étape suivante