Bonnes pratiques

Référez-vous à ces bonnes pratiques lorsque vous créez une application utilisant Cloud Firestore.

Zone de la base de données

Lorsque vous créez votre instance de base de données, sélectionnez la zone de base de données la plus proche de vos utilisateurs et des ressources de calcul. Les sauts de réseau importants sont plus sujets aux erreurs et augmentent la latence des requêtes.

Pour optimiser la disponibilité et la durabilité de votre application, sélectionnez une zone multirégionale et placez les ressources de calcul critiques dans au moins deux régions.

Sélectionnez une zone régionale si vous souhaitez réduire vos coûts, réduire la latence d'écriture si votre application est sensible à la latence, ou co-localiser votre application avec d'autres ressources GCP.

ID de document

  • Évitez les ID de document . et ...
  • Évitez d'utiliser des barres obliques / dans les ID de document.
  • N'utilisez pas des ID de document monotones croissants, tels que :

    • Customer1, Customer2, Customer3, ...
    • Product 1, Product 2, Product 3, ...

    Ces ID séquentiels peuvent générer des hotspots qui ont un impact sur la latence.

Noms des champs

  • Évitez les caractères suivants dans les noms de champs, car ils nécessitent un échappement supplémentaire :

    • . point
    • [ crochet ouvrant
    • ] crochet fermant
    • * astérisque
    • ` accent grave

Index

  • Évitez d'utiliser trop d'index. Un nombre excessif d'index peut augmenter la latence d'écriture et augmenter les coûts de stockage pour les entrées d'index.

  • Sachez que l'indexation des champs avec des valeurs monotones croissantes, telles que les horodatages, peut générer des hotspots qui ont un impact sur la latence des applications avec des taux de lecture et d'écriture élevés.

Exclusions d'index

Pour la plupart des applications, vous pouvez utiliser l'indexation automatique et les liens des messages d'erreur pour gérer vos index. Toutefois, vous pouvez ajouter des exclusions de champs uniques dans les cas suivants :

Cas Description
Champs de chaîne volumineux

S'il existe un champ de chaîne contenant souvent des chaînes longues que vous n'utilisez pas pour les requêtes, vous pouvez réduire les coûts de stockage en excluant le champ de l'indexation.

Taux d'écriture élevés dans une collection contenant des documents avec des valeurs séquentielles

Si vous indexez un champ qui augmente ou diminue séquentiellement entre les documents d'une collection, comme un horodatage, le taux d'écriture maximal pour la collection est de 500 écritures par seconde. Si vous ne faites pas de requête en fonction du champ avec des valeurs séquentielles, vous pouvez exclure le champ de l'indexation pour contourner cette limite.

Par exemple, dans le cas d'un IoT avec un taux d'écriture élevé, une collection contenant des documents avec un champ d'horodatage peut approcher la limite des 500 écritures par seconde.

Champs de tableau ou de mappage volumineux

Les champs de tableau ou de mappage volumineux peuvent approcher la limite de 40 000 entrées d'index par document. Si vous ne faites pas de requête en fonction d'un champ de tableau ou de mappage volumineux, vous devez exclure ce champ de l'indexation.

Opérations de lecture et d'écriture

  • Évitez d'écrire dans un document plus d'une fois par seconde. Pour plus d'informations, consultez la section Mises à jour d'un seul document.

  • Utilisez des appels asynchrones, le cas échéant, au lieu d'appels synchrones. Les appels asynchrones minimisent l'impact de la latence. Par exemple, prenons une application qui a besoin du résultat d'une recherche de document et des résultats d'une requête pour pouvoir afficher une réponse. Si la recherche et la requête ne dépendent pas des données, il n'est pas nécessaire d'attendre de manière synchrone que la recherche se termine avant de lancer la requête.

  • N'utilisez pas de décalages. Utilisez plutôt des curseurs. L'utilisation d'un décalage permet uniquement d'éviter de renvoyer les documents ignorés à l'application, mais ces derniers sont tout de même récupérés en interne. Les documents ignorés ont une incidence sur la latence de la requête, et l'application est facturée pour les opérations de lecture nécessaires à leur récupération.

Nouvelles tentatives de transactions

Les SDK et bibliothèques clientes de Cloud Firestore retentent automatiquement les transactions ayant échoué pour gérer les erreurs temporaires. Si votre application accède à Cloud Firestore via les API REST ou RPC directement au lieu d'utiliser un SDK, elle doit mettre en œuvre les nouvelles tentatives de transactions pour améliorer la fiabilité.

Mises à jour en temps réel

Pour optimiser les performances de l'écouteur d'instantanés, réduisez la taille de vos documents et contrôlez le taux de lecture de vos clients. Les recommandations suivantes fournissent des consignes pour optimiser les performances. Si vous dépassez ces recommandations, il se peut que la latence des notifications augmente.

Recommandation Détails
Réduire le taux de dissociation des écouteurs d'instantanés

Évitez de dissocier fréquemment des écouteurs, en particulier lorsque votre base de données est soumise à une charge d'écriture élevée.

Idéalement, votre application doit configurer tous les écouteurs d'instantanés nécessaires peu après l'ouverture d'une connexion à Cloud Firestore. Une fois que vous avez configuré les écouteurs d'instantanés initiaux, vous devez éviter d'ajouter ou de supprimer rapidement des écouteurs d'instantanés dans la même connexion.

Pour garantir la cohérence des données, Cloud Firestore doit amorcer chaque nouvel écouteur d'instantanés à partir de ses données sources, puis rattraper les nouvelles modifications. En fonction du taux d'écriture de votre base de données, cette opération peut s'avérer coûteuse.

Vos écouteurs d'instantanés peuvent enregistrer une latence accrue si vous ajoutez ou retirez fréquemment des écouteurs d'instantanés dans les références. En général, un écouteur associé en permanence est plus performant qu'un écouteur associé puis dissocié à cet emplacement pour le même volume de données. Pour de meilleures performances, les écouteurs d'instantanés doivent durer au moins 30 secondes. Si un écouteur rencontre des problèmes de performances dans votre application, essayez de suivre les écoutes et non-écoutes de votre application pour déterminer si elles se produisent trop fréquemment.

Limiter les écouteurs d'instantanés par client

100

Le nombre d'écouteurs d'instantanés par client doit être inférieur à 100.

Limiter le taux d'écriture dans la collection

1 000 opérations par seconde

Le taux d'opérations d'écriture pour une collection individuelle doit être inférieur à 1 000 opérations par seconde.

Limiter le taux d'envoi par client

1 document par seconde

Le taux de documents que la base de données envoie à un client spécifique doit être inférieur à 1 document par seconde.

Limiter le taux d'envoi à tous les clients

1 000 000 de documents par seconde

Le taux de documents que la base de données envoie à tous les clients doit être inférieur à 1 000 000 de documents par seconde.

Limiter la charge utile du document par client

10 Kio par seconde

La taille maximale du document téléchargé par un client spécifique doit être inférieure à 10 Kio par seconde.

Limiter la charge utile du document pour tous les clients

1 Gio par seconde

La taille maximale du document téléchargé par tous les clients doit être inférieure à 1 Gio par seconde.

Limiter le nombre de champs par document

100

Vos documents doivent contenir moins de 100 champs.

Comprendre les limites standards de Cloud Firestore

Gardez à l'esprit les limites standards de Cloud Firestore, en particulier la limite de 1 écriture par seconde pour les documents et la limite de 1 000 000 de connexions simultanées par base de données.

Concevoir des solutions évolutives

Les bonnes pratiques suivantes décrivent comment éviter les situations qui créent des conflits.

Mises à jour d'un seul document

Vous ne devez pas mettre à jour un seul document plus d'une fois par seconde. Si vous mettez à jour un document trop rapidement, votre application risque de rencontrer des conflits, y compris une latence plus élevée, des problèmes d'expiration des délais et d'autres erreurs.

Taux de lecture, d'écriture et de suppression élevés pour une plage de documents restreinte

Évitez les taux de lecture ou d'écriture élevés sur les documents qui sont proches d'un point de vue lexicographique, ou votre application rencontrera des erreurs liées à un conflit. Ce problème, appelé "hotspotting", peut se produire si votre application effectue l'une des opérations suivantes :

  • Elle crée des documents à un taux très élevé et attribue ses propres ID monotones croissants.

    Cloud Firestore attribue les ID de document à l'aide d'un algorithme de diffusion. Vous ne devriez pas rencontrer de problème de hotspotting sur les opérations d'écriture si vous créez vos documents à l'aide d'ID de document automatiques.

  • Elle crée des documents à un taux élevé dans une collection contenant peu de documents.

  • Elle crée des documents avec un champ monotone croissant, comme un horodatage, à un taux très élevé.

  • Elle supprime les documents d'une collection à un taux élevé.

  • Elle effectue des opérations d'écriture dans la base de données à un taux très élevé sans augmenter progressivement le trafic.

Augmenter le trafic

Vous devez augmenter progressivement le trafic vers les nouvelles collections ou les documents qui sont proches d'un point de vue lexicographique afin de donner à Cloud Firestore le temps nécessaire pour préparer les documents à l'augmentation du trafic. Nous recommandons de commencer par un maximum de 500 opérations par seconde dans une nouvelle collection, puis d'augmenter le trafic de 50 % toutes les 5 minutes. Par exemple, vous pouvez utiliser ce programme de montée en puissance pour que votre trafic en lecture atteigne 740 000 opérations par seconde après 90 minutes. Vous pouvez faire de même pour votre trafic en écriture, mais gardez à l'esprit les limites standards de Cloud Firestore. Assurez-vous que les opérations sont réparties de manière relativement uniforme sur la plage de clés. Il s'agit de la règle "500/50/5".

Migrer le trafic vers une nouvelle collection

La montée en puissance progressive est particulièrement importante si vous migrez le trafic de votre application d'une collection vers une autre. Une façon simple de gérer cette migration consiste à lire l'ancienne collection et, si le document n'existe pas, à lire la nouvelle collection. Toutefois, cela peut entraîner une augmentation soudaine du trafic vers les documents qui sont proches d'un point de vue lexicographique dans la nouvelle collection. Il est possible que Cloud Firestore ne puisse pas préparer efficacement la nouvelle collection à l'augmentation du trafic, en particulier si elle contient peu de documents.

Un problème similaire peut se produire si vous modifiez les ID de nombreux documents dans la même collection.

La stratégie à adopter pour migrer le trafic vers une nouvelle collection dépend de votre modèle de données. Vous trouverez ci-dessous un exemple de stratégie connue sous le nom de lectures parallèles. Vous devrez déterminer si cette stratégie est efficace pour vos données. L'impact financier des opérations parallèles pendant la migration sera un aspect important à prendre en compte.

Lectures parallèles

Pour mettre en œuvre des lectures parallèles lors de la migration du trafic vers une nouvelle collection, commencez par lire l'ancienne collection. Si le document est manquant, lisez la nouvelle collection. Un taux élevé de lectures de documents inexistants peut entraîner un problème de hotspotting. Vous devez faire en sorte d'augmenter progressivement la charge vers la nouvelle collection. Une meilleure stratégie consiste à copier l'ancien document dans la nouvelle collection, puis à supprimer l'ancien document. Augmentez progressivement le taux de lectures parallèles afin que Cloud Firestore puisse gérer le trafic vers la nouvelle collection.

Une stratégie possible pour l'augmentation progressive des opérations de lecture ou d'écriture vers une nouvelle collection consiste à utiliser un hachage déterministe de l'ID utilisateur afin de sélectionner un pourcentage aléatoire d'utilisateurs qui tentent d'écrire de nouveaux documents. Assurez-vous que le résultat du hachage de l'ID utilisateur n'est pas faussé par votre fonction ou par le comportement des utilisateurs.

Pendant ce temps, exécutez une tâche par lot qui copie toutes les données des anciens documents dans la nouvelle collection. Votre tâche par lot doit éviter les opérations d'écriture sur des ID de document séquentiels afin d'empêcher les hotspots. Lorsque la tâche par lot est terminée, vous ne pouvez effectuer des opérations de lecture qu'à partir de la nouvelle collection.

Vous pouvez peaufiner cette stratégie en faisant migrer simultanément des petits lots d'utilisateurs. Ajoutez un champ au document de l'utilisateur, qui suit l'état de la migration de cet utilisateur. Sélectionnez un lot d'utilisateurs à migrer en fonction du hachage de l'ID utilisateur. Utilisez une tâche par lot pour migrer les documents pour ce lot d'utilisateurs, et utilisez des lectures parallèles pour les utilisateurs en cours de migration.

Veuillez noter qu'il n'est pas facile de revenir à la configuration précédente sans effectuer d'opérations d'écriture en double des anciennes et des nouvelles entités pendant la phase de migration. Ceci aurait pour effet d'augmenter les coûts de Cloud Firestore.