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

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

Firestore et les SDK Firebase pour le Web et les mobiles 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 les 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 Firestore afin que votre application sans serveur évolue et fonctionne bien lorsque le trafic augmente.

Consultez les sections suivantes pour obtenir des conseils sur la mise à l'échelle 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 à Firestore, celle-ci est acheminée vers un serveur frontend Firestore dans la même région que celle où se trouve votre base de données. Par exemple, si votre base de données est en us-east1, la connexion se fait également à un frontend Firestore en us-east1. Ces connexions sont durables et restent ouvertes jusqu'à ce qu'elles soient explicitement fermées par l'application. L'interface lit les données des systèmes de stockage Firestore sous-jacents.

La distance entre la position physique d'un utilisateur et l'emplacement de la base de données Firestore affecte la latence qu'il rencontre. 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 l'application 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 rubriques suivantes améliorent ou affectent la fiabilité de votre application :

Activer le mode hors connexion

Les SDK Firebase permettent la persistance des données hors connexion. Si l'application sur l'appareil de l'utilisateur ne peut pas se connecter à Firestore, elle reste utilisable en travaillant 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 intermittents 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 relancer 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

Il existe plusieurs compromis à faire lorsque vous choisissez entre des emplacements régionaux et multirégionaux. 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 au détriment du 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 régulièrement 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.

Imaginons deux utilisateurs qui se connectent à Firestore via une application de messagerie conçue avec l'un des SDK mobiles.

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 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 nouvel utilisateur crée un message. Le schéma 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é à la base de données :

1. Le client B ouvre une connexion à Firestore et enregistre un écouteur en appelant onSnapshot(collection("chatroom")) via le SDK Firebase. Ce détecteur 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. 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'abonnement 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. Au niveau transactionnel, le système enregistre 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 ensuite les données mises à jour à un pool de gestionnaires d'abonnements.
8. Un outil de correspondance des 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 de snapshot du client B. Comme son nom l'indique, vous pouvez considérer le moteur de correspondance des requêtes inversées comme une requête de base de données normale, mais inversée. Au lieu de rechercher des documents correspondant à une requête, il recherche efficacement les requêtes correspondant à un document entrant. Lorsqu'une correspondance est trouvée, 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 s'assurer que seuls les utilisateurs autorisés reçoivent les données.
9. Le système transmet 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.

La scalabilité de Firestore dépend en grande partie de la distribution du journal des modifications aux gestionnaires d'abonnements et aux serveurs frontend. La diffusion permet à une seule modification de données de se propager efficacement pour répondre à des millions de requêtes en temps réel et d'utilisateurs connectés. En exécutant de nombreux réplicas de tous ces composants dans plusieurs zones (ou plusieurs régions dans le cas d'un déploiement multirégional), Firestore atteint une haute disponibilité et une grande évolutivité.

Il est important de noter que toutes les opérations de lecture émises à partir des SDK Web et mobiles suivent 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, aux appels pour récupérer un document et aux requêtes ponctuelles. Vous pouvez considérer les récupérations de documents uniques et les requêtes ponctuelles comme des écouteurs d'instantanés de courte durée qui présentent des contraintes de performances similaires.

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 évolutives en temps réel.

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 Firestore qui alimentent les requêtes en temps réel sont automatiquement mis à l'échelle horizontalement à mesure que le trafic d'écriture augmente. À mesure que le taux d'écriture d'une base de données augmente au-delà de ce qu'un seul serveur peut gérer, le journal des modifications est réparti 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 fractionnements se produisent. Le schéma suivant montre comment les requêtes en temps réel sont mises à l'échelle :

La mise à l'échelle 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 point chaud d'écriture. Key Visualizer est un outil utile pour analyser les hotspots d'écriture.

De nombreuses applications connaissent une croissance naturelle prévisible, que 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 les écritures trop rapidement. Lorsque vous concevez votre application, gardez à l'esprit d'où provient votre trafic d'écriture.

Comprendre comment les écritures et les lectures interagissent

Vous pouvez considérer le système de requêtes en temps réel comme un pipeline qui relie les opérations d'écriture aux lecteurs. Chaque fois qu'un document est créé, mis à jour ou supprimé, la modification est propagée du système de stockage aux écouteurs actuellement enregistrés. La structure du journal des modifications de Firestore 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 des 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 des opérations d'écriture lentes et des temps de réponse lents corrélés pour les requêtes. Pour éviter ce problème, il est essentiel d'éviter les points chauds.

Limiter 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 rapidement informés des modifications apportées aux données. Pour ce faire, essayez de limiter la taille des éléments. Le système peut traiter très rapidement de petits documents comportant des dizaines de champs. Le traitement des documents 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 du rédacteur, mais peuvent en fait augmenter le temps de notification pour les écouteurs d'instantanés. Cela peut sembler contre-intuitif par rapport à l'utilisation d'autres systèmes de base de données, où vous pouvez utiliser le traitement par lots 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 partitionnement de Firestore tente de colocaliser les données d'une même collection ou d'un même groupe de collections sur le même serveur de journal des modifications. Le système tente de maximiser le débit d'écriture possible tout en maintenant le nombre de serveurs impliqués dans le traitement d'une requête aussi bas que possible.

Toutefois, certains schémas peuvent toujours entraîner un comportement non optimal pour les écouteurs d'instantanés. Par exemple, si votre application stocke la plupart de ses données dans une grande collection, l'écouteur peut avoir besoin de se connecter à plusieurs serveurs pour recevoir toutes les données dont il a besoin. Cela reste vrai même si vous appliquez un filtre de requête. Se connecter à 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 puisse diffuser des écouteurs sans passer par de nombreux serveurs différents. Il peut être préférable de diviser vos données en collections plus petites avec des taux d'écriture plus faibles.

Cela revient à considérer les requêtes de performances dans une base de données relationnelle qui nécessitent des analyses complètes des tables. Dans une base de données relationnelle, une requête qui nécessite une analyse complète de la table équivaut à un écouteur d'instantané qui surveille une collection à fort taux de rotation. Elle peut être lente par rapport à une requête que la base de données peut traiter à l'aide d'un index plus spécifique. Une requête avec un index plus spécifique est semblable à un écouteur d'instantanés qui surveille un seul document ou une collection qui change moins souvent. Vous devez tester la charge de votre application pour bien comprendre le comportement et les besoins de votre cas d'utilisation.

Faites en sorte que les requêtes d'interrogation soient rapides

Un autre élément clé des requêtes réactives en temps réel consiste à s'assurer que la requête d'interrogation pour amorcer les données est rapide et efficace. La première fois qu'un nouvel écouteur d'instantané se connecte, il doit charger l'ensemble des résultats et l'envoyer à l'appareil de l'utilisateur. Les requêtes lentes rendent votre application moins réactive. Cela inclut, par exemple, les requêtes qui tentent de lire de nombreux documents ou celles 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 produit automatiquement et de manière transparente pour les SDK et votre application. Les conditions suivantes peuvent déclencher un état d'interrogation :

• Le système rééquilibre un journal des modifications en raison des variations de la charge.
• Les hotspots 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, un état d'interrogation devient transparent pour les utilisateurs de votre application.

Privilégier les écouteurs de longue durée

Ouvrir et maintenir les écouteurs actifs le plus longtemps possible est souvent le moyen le plus économique de créer une application qui utilise Firestore. Lorsque vous utilisez Firestore, vous êtes facturé pour les documents renvoyés à votre application, et non pour le maintien d'une connexion ouverte. Un écouteur d'instantané de longue durée ne lit que les données dont il a besoin pour répondre à la requête tout au long de sa durée de vie. Cela inclut une opération d'interrogation initiale, suivie de notifications lorsque les données changent réellement. Les requêtes ponctuelles, en revanche, relisent les données qui n'ont peut-être pas changé depuis la dernière exécution de la requête par l'application.

Dans les cas où votre application doit consommer un grand volume de données, les écouteurs d'instantanés peuvent ne pas être appropriés. Par exemple, si votre cas d'utilisation envoie de nombreux documents par seconde via une connexion pendant une période prolongée, il peut être préférable d'opter pour des requêtes ponctuelles qui s'exécutent à une fréquence plus faible.

Étape suivante

• Découvrez comment utiliser les écouteurs d'instantanés.
• Découvrez d'autres bonnes pratiques.