Troppe letture su Firestore? Come scoprire cosa sta leggendo

Apri la pagina Utilizzo del tuo database, nella console Firebase (Firestore > Utilizzo) o nella console Google Cloud. Mostra letture, scritture ed eliminazioni nel tempo. Trova il giorno, e se puoi l'ora, in cui la curva è cambiata, e confrontalo con i tuoi deploy: la maggior parte dei picchi di letture inizia con un rilascio.

Due cose da sapere su questa dashboard. È una stima: Google scrive "the dashboard is not an exact view of billed operations. Billed usage is likely higher." (la dashboard non è una vista esatta delle operazioni fatturate; l'uso fatturato è probabilmente più alto) (Monitorare l'utilizzo di Firestore). E arriva con un po' di ritardo: "updates may take up to 4 minutes to show up in your dashboards." (gli aggiornamenti possono impiegare fino a 4 minuti per comparire nelle dashboard).

In Cloud Monitoring, apri Metrics Explorer e traccia la metrica di Firestore Document Reads. Puoi suddividerla per tipo: LOOKUP per i documenti letti singolarmente dal loro percorso, QUERY per i documenti restituiti da query e listener. Altre due metriche aiutano: Snapshot Listeners e Active Connections.

• Soprattutto QUERY: una query legge troppi documenti, o un listener rilegge i suoi risultati di continuo.
• Soprattutto LOOKUP: qualcosa recupera documenti uno alla volta, spesso in un ciclo o dentro le tue Security Rules.
• Listener che crescono più degli utenti: la tua app apre listener e non li chiude mai, o ne apre uno nuovo a ogni render.

• Query senza limite. Una pagina che carica un'intera collezione per mostrare i primi 20 legge ogni suo documento, a ogni visita. Aggiungi limit() e pagina con i cursori. È così che sono nati 30.356 $ in 72 ore.
• Listener che si riabbonano. In React, un onSnapshot dentro un useEffect le cui dipendenze cambiano a ogni render apre un nuovo listener ogni volta, e ogni nuovo listener rilegge tutto il suo risultato. Sul web la persistenza offline è disattivata di default, e la pagina dei prezzi di Firestore è chiara su quanto costa: "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." (senza persistenza offline, documenti e voci di indice letti ti vengono addebitati come per una query nuova ogni volta che il listener si disconnette e si riconnette).
• Letture dentro le Security Rules. Ogni get() o exists() nelle tue regole legge un documento. "You are charged for reads that are necessary to evaluate your Cloud Firestore Security Rules" (ti vengono addebitate le letture necessarie a valutare le tue Security Rules di Cloud Firestore) (prezzi di Firestore). Una regola che consulta il profilo dell'utente a ogni richiesta raddoppia le letture di una schermata molto usata.
• Contare leggendo. Caricare una collezione per mostrare quanti elementi ha legge ogni documento. Un'aggregazione count() è invece addebitata per voci di indice: "count() operations that read between 0 and 1000 index entries are billed for one document read." (le operazioni count() che leggono tra 0 e 1000 voci di indice sono addebitate come una lettura di documento).
• Polling. Un timer che esegue una query ogni pochi secondi la paga ogni volta, con o senza risultati, perché Firestore addebita "a minimum charge of one document read for each query that you perform, even if the query returns no results" (almeno una lettura di documento per ogni query, anche senza risultati). Usa un listener, o interroga molto meno spesso.
• Funzioni che leggono a ogni scrittura. Una Cloud Function attivata da ogni scrittura che poi legge una collezione moltiplica il tuo traffico. Se scrive anche nei documenti che la attivano, può andare in loop.
• Qualcun altro. Se le tue regole permettono a chiunque, o a qualsiasi utente autenticato, di leggere una collezione, uno script con la tua configurazione pubblica può leggerla tutto il giorno. La console Firebase mostra quante richieste valutano le tue regole, Cloud Monitoring può avvisarti quando quelle negate esplodono e App Check blocca le richieste che non arrivano dalla tua app.

Il primo effect si riabbona ogni volta che filters è un oggetto nuovo, cosa che in molti componenti succede a ogni render. Il secondo dipende da un valore semplice e limita il risultato:

// 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]);

Quando sospetti di una query, eseguila con Query Explain. Riporta le operazioni di lettura addebitate e l'indice usato, così puoi verificare una correzione prima del deploy (Query Explain).

Un avviso di budget ti arriva ore dopo le letture, quindi controlla le letture stesse. In Cloud Monitoring, crea un criterio di avviso su Document Reads con una soglia appena sopra il tuo picco normale.

Oppure lascia fare a FireShield. Su Pro legge l'uso di ogni servizio ogni pochi minuti, confronta l'ultima ora con l'ora normale di quel servizio nell'ultima settimana e ti avvisa, o spegne la parte costosa, quando le letture di Firestore schizzano.