Trop de lectures Firestore ? Comment trouver ce qui lit

Ouvrez la page Utilisation de votre base de données, dans la console Firebase (Firestore > Utilisation) ou dans la console Google Cloud. Elle montre les lectures, écritures et suppressions dans le temps. Repérez le jour, et si possible l'heure, où la courbe a changé, et comparez avec vos déploiements : la plupart des pics de lectures commencent avec une nouvelle version.

Deux choses à savoir sur ce tableau de bord. C'est une estimation : Google écrit "the dashboard is not an exact view of billed operations. Billed usage is likely higher." (le tableau de bord n'est pas une vue exacte des opérations facturées ; l'usage facturé est probablement plus élevé) (Surveiller l'utilisation de Firestore). Et il a un léger retard : "updates may take up to 4 minutes to show up in your dashboards." (les mises à jour peuvent mettre jusqu'à 4 minutes à apparaître dans les tableaux de bord).

Dans Cloud Monitoring, ouvrez l'Explorateur de métriques et tracez la métrique Firestore Document Reads. Vous pouvez la ventiler par type : LOOKUP pour les documents lus un par un via leur chemin, QUERY pour les documents renvoyés par des requêtes et des listeners. Deux autres métriques aident : Snapshot Listeners et Active Connections.

• Surtout QUERY : une requête lit trop de documents, ou un listener relit ses résultats encore et encore.
• Surtout LOOKUP : quelque chose récupère des documents un par un, souvent dans une boucle ou dans vos Security Rules.
• Des listeners qui augmentent plus vite que les utilisateurs : votre app ouvre des listeners sans jamais les fermer, ou en ouvre un nouveau à chaque rendu.

• Des requêtes sans limite. Une page qui charge une collection entière pour afficher les 20 premiers éléments lit tous ses documents, à chaque visite. Ajoutez limit() et paginez avec des curseurs. C'est ainsi que sont arrivés 30 356 $ en 72 heures.
• Des listeners qui se réabonnent. En React, un onSnapshot dans un useEffect dont les dépendances changent à chaque rendu ouvre un nouveau listener à chaque fois, et chaque nouveau listener relit tout son résultat. Sur le web, la persistance hors ligne est désactivée par défaut, et la page de tarifs de Firestore est claire sur ce que cela coûte : "If offline persistence is disabled, you will be charged for documents and index entries read as if you had issued a brand-new query whenever the listener disconnects and reconnects." (sans persistance hors ligne, les documents et entrées d'index lus vous sont facturés comme pour une toute nouvelle requête chaque fois que le listener se déconnecte et se reconnecte).
• Des lectures dans les Security Rules. Chaque get() ou exists() de vos règles lit un document. "You are charged for reads that are necessary to evaluate your Cloud Firestore Security Rules" (les lectures nécessaires pour évaluer vos Security Rules Cloud Firestore vous sont facturées) (tarifs de Firestore). Une règle qui consulte le profil de l'utilisateur à chaque requête double les lectures d'un écran très fréquenté.
• Compter en lisant. Charger une collection pour afficher son nombre d'éléments lit tous ses documents. Une agrégation count() est facturée par entrées d'index : "count() operations that read between 0 and 1000 index entries are billed for one document read." (les opérations count() qui lisent entre 0 et 1000 entrées d'index sont facturées comme une lecture de document).
• Le polling. Un minuteur qui relance une requête toutes les quelques secondes la paie à chaque fois, résultats ou non, car Firestore facture "a minimum charge of one document read for each query that you perform, even if the query returns no results" (au minimum une lecture de document par requête, même sans résultat). Utilisez un listener, ou interrogez beaucoup moins souvent.
• Des fonctions qui lisent à chaque écriture. Une Cloud Function déclenchée à chaque écriture et qui lit ensuite une collection multiplie votre trafic. Si elle écrit aussi dans les documents qui la déclenchent, elle peut tourner en boucle.
• Quelqu'un d'autre. Si vos règles laissent n'importe qui, ou n'importe quel utilisateur connecté, lire une collection, un script muni de votre configuration publique peut la lire toute la journée. La console Firebase montre combien de requêtes vos règles évaluent, Cloud Monitoring peut vous alerter quand les refus explosent, et App Check bloque les requêtes qui ne viennent pas de votre app.

Le premier effet se réabonne chaque fois que filters est un nouvel objet, ce qui dans beaucoup de composants arrive à chaque rendu. Le second dépend d'une valeur simple et limite le résultat :

// Subscribes again every time `filters` is a new object
useEffect(() => {
  const q = query(collection(db, "orders"), where("status", "==", filters.status));
  return onSnapshot(q, (snap) => setOrders(snap.docs));
}, [filters]);

// Subscribes once per status, and reads at most 50 documents
const status = filters.status;
useEffect(() => {
  const q = query(collection(db, "orders"), where("status", "==", status), limit(50));
  return onSnapshot(q, (snap) => setOrders(snap.docs));
}, [status]);

Quand vous soupçonnez une requête, exécutez-la avec Query Explain. Il indique les opérations de lecture facturées et l'index utilisé, ce qui permet de vérifier un correctif avant de le déployer (Query Explain).

Une alerte budgétaire vous arrive des heures après les lectures : surveillez donc les lectures elles-mêmes. Dans Cloud Monitoring, créez une règle d'alerte sur Document Reads avec un seuil un peu au-dessus de votre pic habituel.

Ou laissez faire FireShield. Sur Pro, il lit l'usage de chaque service toutes les quelques minutes, compare la dernière heure à l'heure normale de ce service sur la semaine écoulée, et vous alerte, ou coupe la partie coûteuse, quand les lectures Firestore s'envolent.