Zu viele Firestore-Lesevorgänge? So finden Sie heraus, was liest

Öffnen Sie die Nutzungsseite Ihrer Datenbank, in der Firebase Console (Firestore > Nutzung) oder in der Google Cloud Console. Sie zeigt Lese-, Schreib- und Löschvorgänge über die Zeit. Suchen Sie den Tag, und wenn möglich die Stunde, an dem sich die Kurve geändert hat, und vergleichen Sie ihn mit Ihren Deployments: Die meisten Lese-Spitzen beginnen mit einem Release.

Zwei Dinge zu diesem Dashboard. Es ist eine Schätzung: Google schreibt "the dashboard is not an exact view of billed operations. Billed usage is likely higher." (das Dashboard zeigt die abgerechneten Vorgänge nicht exakt; die abgerechnete Nutzung ist wahrscheinlich höher) (Firestore-Nutzung überwachen). Und es hinkt etwas hinterher: "updates may take up to 4 minutes to show up in your dashboards." (Aktualisierungen können bis zu 4 Minuten brauchen, bis sie in den Dashboards erscheinen).

Öffnen Sie in Cloud Monitoring den Metrics Explorer und zeichnen Sie die Firestore-Messwerte Document Reads. Sie lassen sich nach Typ aufschlüsseln: LOOKUP für einzelne Dokumente, die über ihren Pfad gelesen werden, QUERY für Dokumente aus Abfragen und Listenern. Zwei weitere Messwerte helfen: Snapshot Listeners und Active Connections.

• Vor allem QUERY: Eine Abfrage liest zu viele Dokumente, oder ein Listener liest seine Ergebnisse immer wieder neu.
• Vor allem LOOKUP: Etwas holt Dokumente einzeln, oft in einer Schleife oder in Ihren Security Rules.
• Listener wachsen schneller als die Nutzer: Ihre App öffnet Listener und schließt sie nie, oder öffnet bei jedem Render einen neuen.

• Abfragen ohne Limit. Eine Seite, die eine ganze Collection lädt, um die ersten 20 anzuzeigen, liest bei jedem Besuch jedes Dokument darin. Fügen Sie limit() hinzu und paginieren Sie mit Cursorn. So entstanden 30.356 $ in 72 Stunden.
• Listener, die sich neu abonnieren. In React öffnet ein onSnapshot in einem useEffect, dessen Abhängigkeiten sich bei jedem Render ändern, jedes Mal einen neuen Listener, und jeder neue Listener liest sein ganzes Ergebnis erneut. Im Web ist die Offline-Persistenz standardmäßig aus, und die Firestore-Preisseite sagt klar, was das kostet: "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." (ohne Offline-Persistenz werden gelesene Dokumente und Indexeinträge jedes Mal wie bei einer ganz neuen Abfrage berechnet, wenn der Listener die Verbindung trennt und neu aufbaut).
• Lesevorgänge in Security Rules. Jedes get() oder exists() in Ihren Regeln liest ein Dokument. "You are charged for reads that are necessary to evaluate your Cloud Firestore Security Rules" (Lesevorgänge, die zur Auswertung Ihrer Cloud Firestore Security Rules nötig sind, werden berechnet) (Firestore-Preise). Eine Regel, die bei jeder Anfrage das Profil des Nutzers nachschlägt, verdoppelt die Lesevorgänge eines stark genutzten Bildschirms.
• Zählen durch Lesen. Eine Collection zu laden, um die Anzahl ihrer Einträge anzuzeigen, liest jedes Dokument. Eine count()-Aggregation wird stattdessen nach Indexeinträgen berechnet: "count() operations that read between 0 and 1000 index entries are billed for one document read." (count()-Vorgänge, die zwischen 0 und 1000 Indexeinträge lesen, werden als ein Dokument-Lesevorgang berechnet).
• Polling. Ein Timer, der alle paar Sekunden eine Abfrage ausführt, zahlt jedes Mal, mit oder ohne Ergebnis, denn Firestore berechnet "a minimum charge of one document read for each query that you perform, even if the query returns no results" (mindestens einen Dokument-Lesevorgang pro Abfrage, auch ohne Ergebnis). Nutzen Sie einen Listener, oder fragen Sie viel seltener ab.
• Funktionen, die bei jedem Schreibvorgang lesen. Eine Cloud Function, die bei jedem Schreibvorgang auslöst und dann eine Collection liest, vervielfacht Ihren Traffic. Schreibt sie zusätzlich in die Dokumente, die sie auslösen, kann sie in eine Schleife geraten.
• Jemand anderes. Erlauben Ihre Regeln jedem, oder jedem angemeldeten Nutzer, eine Collection zu lesen, kann ein Skript mit Ihrer öffentlichen Konfiguration sie den ganzen Tag lesen. Die Firebase Console zeigt, wie viele Anfragen Ihre Regeln auswerten, Cloud Monitoring kann Sie warnen, wenn abgelehnte Anfragen sprunghaft steigen, und App Check stoppt Anfragen, die nicht von Ihrer App kommen.

Der erste Effect abonniert jedes Mal neu, wenn filters ein neues Objekt ist, was in vielen Komponenten bei jedem Render passiert. Der zweite hängt von einem einfachen Wert ab und begrenzt das Ergebnis:

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

Haben Sie eine Abfrage im Verdacht, führen Sie sie mit Query Explain aus. Es zeigt die berechneten Lesevorgänge und den verwendeten Index, sodass Sie einen Fix vor dem Deployment prüfen können (Query Explain).

Eine Budgetwarnung erreicht Sie Stunden nach den Lesevorgängen, also überwachen Sie die Lesevorgänge selbst. Legen Sie in Cloud Monitoring eine Benachrichtigungsrichtlinie für Document Reads an, mit einem Schwellenwert etwas über Ihrer normalen Spitze.

Oder überlassen Sie es FireShield. Bei Pro liest es alle paar Minuten die Nutzung jedes Dienstes, vergleicht die letzte Stunde mit der normalen Stunde dieses Dienstes in der vergangenen Woche und warnt Sie, oder schaltet den teuren Teil ab, wenn die Firestore-Lesevorgänge sprunghaft steigen.