Firebase is back at Google I/O on May 10! Register now

Best Practices für Cloud Firestore

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Verwenden Sie die hier aufgeführten Best Practices als Kurzreferenz beim Erstellen einer Anwendung, die Cloud Firestore verwendet.

Speicherort der Datenbank

Wählen Sie beim Erstellen Ihrer Datenbankinstanz den Datenbankspeicherort aus, der Ihren Benutzern und Rechenressourcen am nächsten liegt. Weitreichende Netzwerksprünge sind fehleranfälliger und erhöhen die Abfragelatenz.

Um die Verfügbarkeit und Dauerhaftigkeit Ihrer Anwendung zu maximieren, wählen Sie einen Standort mit mehreren Regionen aus und platzieren Sie kritische Rechenressourcen in mindestens zwei Regionen.

Wählen Sie einen regionalen Standort aus, um die Kosten zu senken, die Schreiblatenz zu verringern, wenn Ihre Anwendung latenzempfindlich ist, oder für die gemeinsame Nutzung mit anderen GCP-Ressourcen .

Dokument-IDs

  • Vermeiden Sie die Dokument-IDs . und .. .
  • Vermeiden Sie die Verwendung von / -Schrägstrichen in Dokument-IDs.
  • Verwenden Sie keine monoton ansteigenden Dokument-IDs wie:

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

    Solche sequenziellen IDs können zu Hotspots führen, die sich auf die Latenz auswirken.

Feldnamen

  • Vermeiden Sie die folgenden Zeichen in Feldnamen, da sie zusätzliche Escapezeichen erfordern:

    • . Zeitraum
    • [ linke Klammer
    • ] rechte Klammer
    • * Sternchen
    • ` Backtick

Indizes

  • Vermeiden Sie die Verwendung zu vieler Indizes. Eine übermäßige Anzahl von Indizes kann die Schreiblatenz erhöhen und die Speicherkosten für Indexeinträge erhöhen.

  • Beachten Sie, dass das Indizieren von Feldern mit monoton ansteigenden Werten, z. B. Zeitstempeln, zu Hotspots führen kann, die sich auf die Latenz für Anwendungen mit hohen Lese- und Schreibraten auswirken.

Index-Ausnahmen

Bei den meisten Apps können Sie sich bei der Verwaltung Ihrer Indizes auf die automatische Indizierung sowie Links zu Fehlermeldungen verlassen. In den folgenden Fällen möchten Sie jedoch möglicherweise Einzelfeldausnahmen hinzufügen:

Fall Beschreibung
Große Zeichenfolgenfelder

Wenn Sie ein Zeichenfolgenfeld haben, das häufig lange Zeichenfolgenwerte enthält, die Sie nicht für Abfragen verwenden, können Sie die Speicherkosten senken, indem Sie das Feld von der Indizierung ausnehmen.

Hohe Schreibraten in eine Sammlung, die Dokumente mit sequenziellen Werten enthält

Wenn Sie ein Feld indizieren, das zwischen Dokumenten in einer Sammlung sequenziell zunimmt oder abnimmt, wie z. B. ein Zeitstempel, beträgt die maximale Schreibrate in die Sammlung 500 Schreibvorgänge pro Sekunde. Wenn Sie keine Abfrage basierend auf dem Feld mit sequenziellen Werten durchführen, können Sie das Feld von der Indizierung ausnehmen, um dieses Limit zu umgehen.

In einem IoT-Anwendungsfall mit einer hohen Schreibrate könnte beispielsweise eine Sammlung, die Dokumente mit einem Zeitstempelfeld enthält, die Grenze von 500 Schreibvorgängen pro Sekunde erreichen.

TTL-Felder

Wenn Sie TTL-Richtlinien (Time-to-Live) verwenden, beachten Sie, dass das TTL-Feld ein Zeitstempel sein muss. Die Indizierung von TTL-Feldern ist standardmäßig aktiviert und kann die Leistung bei höheren Datenverkehrsraten beeinträchtigen. Fügen Sie als Best Practice Einzelfeldausnahmen für Ihre TTL-Felder hinzu.

Große Array- oder Kartenfelder

Große Array- oder Zuordnungsfelder können die Grenze von 40.000 Indexeinträgen pro Dokument erreichen. Wenn Sie nicht auf der Grundlage eines großen Arrays oder Zuordnungsfelds abfragen, sollten Sie es von der Indizierung ausnehmen.

Lese- und Schreiboperationen

  • Die genaue maximale Rate, mit der eine App ein einzelnes Dokument aktualisieren kann, hängt stark von der Arbeitslast ab. Weitere Informationen finden Sie unter Aktualisierungen eines einzelnen Dokuments .

  • Verwenden Sie asynchrone Aufrufe, sofern verfügbar, anstelle von synchronen Aufrufen. Asynchrone Aufrufe minimieren die Auswirkungen der Latenz. Stellen Sie sich beispielsweise eine Anwendung vor, die das Ergebnis einer Dokumentsuche und die Ergebnisse einer Abfrage benötigt, bevor eine Antwort ausgegeben wird. Wenn die Suche und die Abfrage keine Datenabhängigkeit aufweisen, muss nicht synchron gewartet werden, bis die Suche abgeschlossen ist, bevor die Abfrage initiiert wird.

  • Verwenden Sie keine Offsets. Verwenden Sie stattdessen Cursors . Wenn Sie nur einen Offset verwenden, wird vermieden, dass die übersprungenen Dokumente an Ihre Anwendung zurückgegeben werden, diese Dokumente werden jedoch weiterhin intern abgerufen. Die übersprungenen Dokumente wirken sich auf die Latenz der Abfrage aus, und Ihrer Anwendung werden die zum Abrufen erforderlichen Lesevorgänge in Rechnung gestellt.

Wiederholungen von Transaktionen

Die Cloud Firestore SDKs und Clientbibliotheken wiederholen automatisch fehlgeschlagene Transaktionen, um vorübergehende Fehler zu beheben. Wenn Ihre Anwendung direkt über die REST- oder RPC- APIs statt über ein SDK auf Cloud Firestore zugreift, sollte Ihre Anwendung Transaktionswiederholungen implementieren, um die Zuverlässigkeit zu erhöhen.

Echtzeit-Updates

Für die beste Snapshot-Listener- Leistung sollten Sie Ihre Dokumente klein halten und die Leserate Ihrer Clients kontrollieren. Die folgenden Empfehlungen enthalten Richtlinien zur Maximierung der Leistung. Das Überschreiten dieser Empfehlungen kann zu einer erhöhten Benachrichtigungslatenz führen.

Empfehlung Einzelheiten
Reduzieren Sie die Abwanderungsrate von Snapshot-Listenern

Vermeiden Sie häufig wechselnde Listener, insbesondere wenn Ihre Datenbank unter erheblicher Schreiblast steht

Idealerweise sollte Ihre Anwendung kurz nach dem Öffnen einer Verbindung zu Cloud Firestore alle erforderlichen Snapshot-Listener einrichten. Nachdem Sie Ihre anfänglichen Snapshot-Listener eingerichtet haben, sollten Sie es vermeiden, Snapshot-Listener in derselben Verbindung schnell hinzuzufügen oder zu entfernen.

Um die Datenkonsistenz zu gewährleisten, muss Cloud Firestore jeden neuen Snapshot-Listener aus seinen Quelldaten vorbereiten und dann neue Änderungen nachholen. Abhängig von der Schreibrate Ihrer Datenbank kann dies ein teurer Vorgang sein.

Ihre Snapshot-Listener können eine erhöhte Latenz erfahren, wenn Sie häufig Snapshot-Listener zu Referenzen hinzufügen oder daraus entfernen. Im Allgemeinen schneidet ein ständig verbundener Zuhörer für die gleiche Datenmenge besser ab als das Anschließen und Trennen eines Zuhörers an diesem Ort. Für eine optimale Leistung sollten Snapshot-Listener eine Lebensdauer von 30 Sekunden oder länger haben. Wenn in Ihrer App Probleme mit der Listenerleistung auftreten, versuchen Sie, die Listenings und Delistings Ihrer App zu verfolgen, um festzustellen, ob sie möglicherweise zu häufig auftreten.

Snapshot-Listener pro Client begrenzen

100

Halten Sie die Anzahl der Snapshot-Listener pro Client unter 100.

Begrenzen Sie die Schreibrate der Sammlung

1.000 Operationen/Sekunde

Halten Sie die Rate der Schreibvorgänge für eine einzelne Sammlung unter 1.000 Vorgängen/Sekunde.

Begrenzen Sie die individuelle Client-Push-Rate

1 Dokument/Sekunde

Halten Sie die Rate der Dokumente, die die Datenbank an einen einzelnen Client sendet, unter 1 Dokument/Sekunde.

Begrenzen Sie die globale Client-Push-Rate

1.000.000 Dokumente/Sekunde

Halten Sie die Rate der Dokumente, die die Datenbank an alle Clients sendet, unter 1.000.000 Dokumenten/Sekunde.

Dies ist eine weiche Grenze. Cloud Firestore hindert Sie nicht daran, diesen Schwellenwert zu überschreiten, wirkt sich jedoch stark auf die Leistung aus.

Begrenzen Sie die Nutzlast einzelner Dokumente

10 KiB/Sekunde

Halten Sie die maximale Dokumentgröße, die von einem einzelnen Client heruntergeladen wird, unter 10 KiB/Sekunde.

Begrenzen Sie die globale Dokumentnutzlast

1 GiB/Sekunde

Halten Sie die maximale Dokumentgröße, die von allen Clients heruntergeladen wird, unter 1 GiB/Sekunde.

Begrenzen Sie die Anzahl der Felder pro Dokument

100

Ihre Dokumente sollten weniger als 100 Felder haben.

Machen Sie sich mit den Standardlimits von Cloud Firestore vertraut

Beachten Sie die Standardlimits für Cloud Firestore .

Achten Sie besonders auf das Limit von 1 Schreibvorgang pro Sekunde für Dokumente und das Limit von 1.000.000 gleichzeitigen Verbindungen pro Datenbank. Dies sind weiche Limits, die Cloud Firestore Sie nicht davon abhält, sie zu überschreiten. Das Überschreiten dieser Grenzwerte kann jedoch die Leistung beeinträchtigen, abhängig von Ihren gesamten Lese- und Schreibraten.

Maßstäblich gestalten

Die folgenden Best Practices beschreiben, wie Situationen vermieden werden können, die zu Konfliktproblemen führen.

Updates für ein einzelnes Dokument

Berücksichtigen Sie beim Entwerfen Ihrer App, wie schnell Ihre App einzelne Dokumente aktualisiert. Die beste Möglichkeit, die Leistung Ihrer Workload zu charakterisieren, ist die Durchführung von Lasttests. Die genaue maximale Rate, mit der eine App ein einzelnes Dokument aktualisieren kann, hängt stark von der Arbeitslast ab. Zu den Faktoren gehören die Schreibrate, Konflikte zwischen Anforderungen und die Anzahl der betroffenen Indizes.

Ein Dokumentschreibvorgang aktualisiert das Dokument und alle zugehörigen Indizes, und Cloud Firestore wendet den Schreibvorgang synchron auf ein Quorum von Replikaten an. Bei ausreichend hohen Schreibraten treten in der Datenbank Konflikte, höhere Latenzen oder andere Fehler auf.

Hohe Lese-, Schreib- und Löschraten für einen engen Dokumentenbereich

Vermeiden Sie hohe Lese- oder Schreibraten, um Dokumente lexikografisch zu schließen, da es sonst zu Konfliktfehlern in Ihrer Anwendung kommt. Dieses Problem wird als Hotspotting bezeichnet, und bei Ihrer Anwendung kann Hotspotting auftreten, wenn eine der folgenden Aktionen ausgeführt wird:

  • Erstellt neue Dokumente mit einer sehr hohen Rate und weist seine eigenen monoton ansteigenden IDs zu.

    Cloud Firestore weist Dokument-IDs mithilfe eines Scatter-Algorithmus zu. Hotspotting bei Schreibvorgängen sollte nicht auftreten, wenn Sie neue Dokumente mit automatischen Dokument-IDs erstellen.

  • Erstellt schnell neue Dokumente in einer Sammlung mit wenigen Dokumenten.

  • Erstellt neue Dokumente mit einem monoton ansteigenden Feld, wie z. B. einem Zeitstempel, mit einer sehr hohen Rate.

  • Löscht Dokumente in einer Sammlung mit hoher Rate.

  • Schreibt mit einer sehr hohen Rate in die Datenbank, ohne den Datenverkehr allmählich zu erhöhen.

Vermeiden Sie es, gelöschte Daten zu überspringen

Vermeiden Sie Abfragen, die kürzlich gelöschte Daten überspringen. Eine Abfrage muss möglicherweise eine große Anzahl von Indexeinträgen überspringen, wenn die frühen Abfrageergebnisse kürzlich gelöscht wurden.

Ein Beispiel für eine Workload, die möglicherweise viele gelöschte Daten überspringen muss, ist eine, die versucht, die ältesten Arbeitsaufgaben in der Warteschlange zu finden. Die Abfrage könnte wie folgt aussehen:

docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
delete_batch.commit()

Jedes Mal, wenn diese Abfrage ausgeführt wird, scannt sie die Indexeinträge für das created Feld in allen kürzlich gelöschten Dokumenten. Dies verlangsamt Abfragen.

Um die Leistung zu verbessern, verwenden Sie die start_at Methode, um den besten Startpunkt zu finden. Zum Beispiel:

completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
    {'created': completed_items.get('last_completed')}).order_by(
        'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
  last_completed = doc.get('created')

if last_completed:
  delete_batch.update(completed_items.reference,
                      {'last_completed': last_completed})
  delete_batch.commit()

HINWEIS: Das obige Beispiel verwendet ein monoton ansteigendes Feld, das ein Antimuster für hohe Schreibraten ist.

Verkehr hochfahren

Sie sollten den Datenverkehr zu neuen Sammlungen schrittweise erhöhen oder Dokumente lexikografisch schließen, um Cloud Firestore genügend Zeit zu geben, Dokumente für den erhöhten Datenverkehr vorzubereiten. Wir empfehlen, mit maximal 500 Vorgängen pro Sekunde zu einer neuen Sammlung zu beginnen und dann den Traffic alle 5 Minuten um 50 % zu erhöhen. Sie können Ihren Schreibdatenverkehr auf ähnliche Weise erhöhen, aber denken Sie an die Cloud Firestore-Standardlimits . Achten Sie darauf, dass die Operationen relativ gleichmäßig über den Tastenbereich verteilt sind. Dies wird als „500/50/5“-Regel bezeichnet.

Datenverkehr in eine neue Sammlung migrieren

Ein schrittweises Hochfahren ist besonders wichtig, wenn Sie App-Traffic von einer Sammlung zu einer anderen migrieren. Eine einfache Möglichkeit, diese Migration zu handhaben, besteht darin, aus der alten Sammlung zu lesen und, wenn das Dokument nicht vorhanden ist, aus der neuen Sammlung zu lesen. Dies könnte jedoch zu einem plötzlichen Anstieg des Datenverkehrs führen, um Dokumente in der neuen Sammlung lexikografisch zu schließen. Cloud Firestore ist möglicherweise nicht in der Lage, die neue Sammlung effizient auf erhöhten Datenverkehr vorzubereiten, insbesondere wenn sie nur wenige Dokumente enthält.

Ein ähnliches Problem kann auftreten, wenn Sie die Dokument-IDs vieler Dokumente innerhalb derselben Sammlung ändern.

Die beste Strategie zum Migrieren von Datenverkehr zu einer neuen Sammlung hängt von Ihrem Datenmodell ab. Nachfolgend finden Sie eine Beispielstrategie, die als parallele Lesevorgänge bekannt ist. Sie müssen bestimmen, ob diese Strategie für Ihre Daten effektiv ist, und eine wichtige Überlegung sind die Kostenauswirkungen paralleler Vorgänge während der Migration.

Parallel liest

Um parallele Lesevorgänge zu implementieren, während Sie Datenverkehr zu einer neuen Sammlung migrieren, lesen Sie zuerst aus der alten Sammlung. Wenn das Dokument fehlt, dann lesen Sie aus der neuen Sammlung. Eine hohe Rate an Lesevorgängen nicht vorhandener Dokumente kann zu Hotspotting führen. Erhöhen Sie daher die Auslastung der neuen Sammlung schrittweise. Eine bessere Strategie besteht darin, das alte Dokument in die neue Sammlung zu kopieren und dann das alte Dokument zu löschen. Parallele Lesevorgänge schrittweise hochfahren, um sicherzustellen, dass Cloud Firestore den Datenverkehr zur neuen Sammlung verarbeiten kann.

Eine mögliche Strategie zum schrittweisen Hochfahren von Lese- oder Schreibvorgängen in eine neue Sammlung besteht darin, einen deterministischen Hash der Benutzer-ID zu verwenden, um einen zufälligen Prozentsatz von Benutzern auszuwählen, die versuchen, neue Dokumente zu schreiben. Stellen Sie sicher, dass das Ergebnis des Benutzer-ID-Hashes weder durch Ihre Funktion noch durch das Benutzerverhalten verzerrt wird.

Führen Sie in der Zwischenzeit einen Batch-Job aus, der alle Ihre Daten aus den alten Dokumenten in die neue Sammlung kopiert. Ihr Batch-Job sollte Schreibvorgänge in sequenzielle Dokument-IDs vermeiden, um Hotspots zu vermeiden. Wenn der Batch-Job abgeschlossen ist, können Sie nur aus der neuen Sammlung lesen.

Eine Verfeinerung dieser Strategie besteht darin, kleine Batches von Benutzern gleichzeitig zu migrieren. Fügen Sie dem Benutzerdokument ein Feld hinzu, das den Migrationsstatus dieses Benutzers verfolgt. Wählen Sie basierend auf einem Hash der Benutzer-ID einen Stapel von Benutzern aus, die migriert werden sollen. Verwenden Sie einen Batch-Job, um Dokumente für diesen Batch von Benutzern zu migrieren, und verwenden Sie parallele Lesevorgänge für Benutzer, die sich mitten in der Migration befinden.

Beachten Sie, dass Sie kein einfaches Rollback durchführen können, es sei denn, Sie führen während der Migrationsphase doppelte Schreibvorgänge sowohl für die alten als auch für die neuen Entitäten durch. Dies würde die anfallenden Cloud Firestore-Kosten erhöhen.

Unbefugten Zugriff verhindern

Verhindern Sie unbefugte Vorgänge in Ihrer Datenbank mit Cloud Firestore-Sicherheitsregeln. Durch die Verwendung von Regeln könnte beispielsweise ein Szenario vermieden werden, in dem ein böswilliger Benutzer wiederholt Ihre gesamte Datenbank herunterlädt.

Erfahren Sie mehr über die Verwendung von Cloud Firestore-Sicherheitsregeln .

,

Verwenden Sie die hier aufgeführten Best Practices als Kurzreferenz beim Erstellen einer Anwendung, die Cloud Firestore verwendet.

Speicherort der Datenbank

Wählen Sie beim Erstellen Ihrer Datenbankinstanz den Datenbankspeicherort aus, der Ihren Benutzern und Rechenressourcen am nächsten liegt. Weitreichende Netzwerksprünge sind fehleranfälliger und erhöhen die Abfragelatenz.

Um die Verfügbarkeit und Dauerhaftigkeit Ihrer Anwendung zu maximieren, wählen Sie einen Standort mit mehreren Regionen aus und platzieren Sie kritische Rechenressourcen in mindestens zwei Regionen.

Wählen Sie einen regionalen Standort aus, um die Kosten zu senken, die Schreiblatenz zu verringern, wenn Ihre Anwendung latenzempfindlich ist, oder für die gemeinsame Nutzung mit anderen GCP-Ressourcen .

Dokument-IDs

  • Vermeiden Sie die Dokument-IDs . und .. .
  • Vermeiden Sie die Verwendung von / -Schrägstrichen in Dokument-IDs.
  • Verwenden Sie keine monoton ansteigenden Dokument-IDs wie:

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

    Solche sequenziellen IDs können zu Hotspots führen, die sich auf die Latenz auswirken.

Feldnamen

  • Vermeiden Sie die folgenden Zeichen in Feldnamen, da sie zusätzliche Escapezeichen erfordern:

    • . Zeitraum
    • [ linke Klammer
    • ] rechte Klammer
    • * Sternchen
    • ` Backtick

Indizes

  • Vermeiden Sie die Verwendung zu vieler Indizes. Eine übermäßige Anzahl von Indizes kann die Schreiblatenz erhöhen und die Speicherkosten für Indexeinträge erhöhen.

  • Beachten Sie, dass das Indizieren von Feldern mit monoton ansteigenden Werten, z. B. Zeitstempeln, zu Hotspots führen kann, die sich auf die Latenz für Anwendungen mit hohen Lese- und Schreibraten auswirken.

Index-Ausnahmen

Bei den meisten Apps können Sie sich bei der Verwaltung Ihrer Indizes auf die automatische Indizierung sowie Links zu Fehlermeldungen verlassen. In den folgenden Fällen möchten Sie jedoch möglicherweise Einzelfeldausnahmen hinzufügen:

Fall Beschreibung
Große Zeichenfolgenfelder

Wenn Sie ein Zeichenfolgenfeld haben, das häufig lange Zeichenfolgenwerte enthält, die Sie nicht für Abfragen verwenden, können Sie die Speicherkosten senken, indem Sie das Feld von der Indizierung ausnehmen.

Hohe Schreibraten in eine Sammlung, die Dokumente mit sequenziellen Werten enthält

Wenn Sie ein Feld indizieren, das zwischen Dokumenten in einer Sammlung sequenziell zunimmt oder abnimmt, wie z. B. ein Zeitstempel, beträgt die maximale Schreibrate in die Sammlung 500 Schreibvorgänge pro Sekunde. Wenn Sie keine Abfrage basierend auf dem Feld mit sequenziellen Werten durchführen, können Sie das Feld von der Indizierung ausnehmen, um dieses Limit zu umgehen.

In einem IoT-Anwendungsfall mit einer hohen Schreibrate könnte beispielsweise eine Sammlung, die Dokumente mit einem Zeitstempelfeld enthält, die Grenze von 500 Schreibvorgängen pro Sekunde erreichen.

TTL-Felder

Wenn Sie TTL-Richtlinien (Time-to-Live) verwenden, beachten Sie, dass das TTL-Feld ein Zeitstempel sein muss. Die Indizierung von TTL-Feldern ist standardmäßig aktiviert und kann die Leistung bei höheren Datenverkehrsraten beeinträchtigen. Fügen Sie als Best Practice Einzelfeldausnahmen für Ihre TTL-Felder hinzu.

Große Array- oder Kartenfelder

Große Array- oder Zuordnungsfelder können die Grenze von 40.000 Indexeinträgen pro Dokument erreichen. Wenn Sie nicht auf der Grundlage eines großen Arrays oder Zuordnungsfelds abfragen, sollten Sie es von der Indizierung ausnehmen.

Lese- und Schreiboperationen

  • Die genaue maximale Rate, mit der eine App ein einzelnes Dokument aktualisieren kann, hängt stark von der Arbeitslast ab. Weitere Informationen finden Sie unter Aktualisierungen eines einzelnen Dokuments .

  • Verwenden Sie asynchrone Aufrufe, sofern verfügbar, anstelle von synchronen Aufrufen. Asynchrone Aufrufe minimieren die Auswirkungen der Latenz. Stellen Sie sich beispielsweise eine Anwendung vor, die das Ergebnis einer Dokumentsuche und die Ergebnisse einer Abfrage benötigt, bevor eine Antwort ausgegeben wird. Wenn die Suche und die Abfrage keine Datenabhängigkeit aufweisen, muss nicht synchron gewartet werden, bis die Suche abgeschlossen ist, bevor die Abfrage initiiert wird.

  • Verwenden Sie keine Offsets. Verwenden Sie stattdessen Cursors . Wenn Sie nur einen Offset verwenden, wird vermieden, dass die übersprungenen Dokumente an Ihre Anwendung zurückgegeben werden, diese Dokumente werden jedoch weiterhin intern abgerufen. Die übersprungenen Dokumente wirken sich auf die Latenz der Abfrage aus, und Ihrer Anwendung werden die zum Abrufen erforderlichen Lesevorgänge in Rechnung gestellt.

Wiederholungen von Transaktionen

Die Cloud Firestore SDKs und Clientbibliotheken wiederholen automatisch fehlgeschlagene Transaktionen, um vorübergehende Fehler zu beheben. Wenn Ihre Anwendung direkt über die REST- oder RPC- APIs statt über ein SDK auf Cloud Firestore zugreift, sollte Ihre Anwendung Transaktionswiederholungen implementieren, um die Zuverlässigkeit zu erhöhen.

Echtzeit-Updates

Für die beste Snapshot-Listener- Leistung sollten Sie Ihre Dokumente klein halten und die Leserate Ihrer Clients kontrollieren. Die folgenden Empfehlungen enthalten Richtlinien zur Maximierung der Leistung. Das Überschreiten dieser Empfehlungen kann zu einer erhöhten Benachrichtigungslatenz führen.

Empfehlung Einzelheiten
Reduzieren Sie die Abwanderungsrate von Snapshot-Listenern

Vermeiden Sie häufig wechselnde Listener, insbesondere wenn Ihre Datenbank unter erheblicher Schreiblast steht

Idealerweise sollte Ihre Anwendung kurz nach dem Öffnen einer Verbindung zu Cloud Firestore alle erforderlichen Snapshot-Listener einrichten. Nachdem Sie Ihre anfänglichen Snapshot-Listener eingerichtet haben, sollten Sie es vermeiden, Snapshot-Listener in derselben Verbindung schnell hinzuzufügen oder zu entfernen.

Um die Datenkonsistenz zu gewährleisten, muss Cloud Firestore jeden neuen Snapshot-Listener aus seinen Quelldaten vorbereiten und dann neue Änderungen nachholen. Abhängig von der Schreibrate Ihrer Datenbank kann dies ein teurer Vorgang sein.

Ihre Snapshot-Listener können eine erhöhte Latenz erfahren, wenn Sie häufig Snapshot-Listener zu Referenzen hinzufügen oder daraus entfernen. Im Allgemeinen schneidet ein ständig verbundener Zuhörer für die gleiche Datenmenge besser ab als das Anschließen und Trennen eines Zuhörers an diesem Ort. Für eine optimale Leistung sollten Snapshot-Listener eine Lebensdauer von 30 Sekunden oder länger haben. Wenn in Ihrer App Probleme mit der Listenerleistung auftreten, versuchen Sie, die Listenings und Delistings Ihrer App zu verfolgen, um festzustellen, ob sie möglicherweise zu häufig auftreten.

Snapshot-Listener pro Client begrenzen

100

Halten Sie die Anzahl der Snapshot-Listener pro Client unter 100.

Begrenzen Sie die Schreibrate der Sammlung

1.000 Operationen/Sekunde

Halten Sie die Rate der Schreibvorgänge für eine einzelne Sammlung unter 1.000 Vorgängen/Sekunde.

Begrenzen Sie die individuelle Client-Push-Rate

1 Dokument/Sekunde

Halten Sie die Rate der Dokumente, die die Datenbank an einen einzelnen Client sendet, unter 1 Dokument/Sekunde.

Begrenzen Sie die globale Client-Push-Rate

1.000.000 Dokumente/Sekunde

Halten Sie die Rate der Dokumente, die die Datenbank an alle Clients sendet, unter 1.000.000 Dokumenten/Sekunde.

Dies ist eine weiche Grenze. Cloud Firestore hindert Sie nicht daran, diesen Schwellenwert zu überschreiten, wirkt sich jedoch stark auf die Leistung aus.

Begrenzen Sie die Nutzlast einzelner Dokumente

10 KiB/Sekunde

Halten Sie die maximale Dokumentgröße, die von einem einzelnen Client heruntergeladen wird, unter 10 KiB/Sekunde.

Begrenzen Sie die globale Dokumentnutzlast

1 GiB/Sekunde

Halten Sie die maximale Dokumentgröße, die von allen Clients heruntergeladen wird, unter 1 GiB/Sekunde.

Begrenzen Sie die Anzahl der Felder pro Dokument

100

Ihre Dokumente sollten weniger als 100 Felder haben.

Machen Sie sich mit den Standardlimits von Cloud Firestore vertraut

Beachten Sie die Standardlimits für Cloud Firestore .

Achten Sie besonders auf das Limit von 1 Schreibvorgang pro Sekunde für Dokumente und das Limit von 1.000.000 gleichzeitigen Verbindungen pro Datenbank. Dies sind weiche Limits, die Cloud Firestore Sie nicht davon abhält, sie zu überschreiten. Das Überschreiten dieser Grenzwerte kann jedoch die Leistung beeinträchtigen, abhängig von Ihren gesamten Lese- und Schreibraten.

Maßstäblich gestalten

Die folgenden Best Practices beschreiben, wie Situationen vermieden werden können, die zu Konfliktproblemen führen.

Updates für ein einzelnes Dokument

Berücksichtigen Sie beim Entwerfen Ihrer App, wie schnell Ihre App einzelne Dokumente aktualisiert. Die beste Möglichkeit, die Leistung Ihrer Workload zu charakterisieren, ist die Durchführung von Lasttests. Die genaue maximale Rate, mit der eine App ein einzelnes Dokument aktualisieren kann, hängt stark von der Arbeitslast ab. Zu den Faktoren gehören die Schreibrate, Konflikte zwischen Anforderungen und die Anzahl der betroffenen Indizes.

Ein Dokumentschreibvorgang aktualisiert das Dokument und alle zugehörigen Indizes, und Cloud Firestore wendet den Schreibvorgang synchron auf ein Quorum von Replikaten an. Bei ausreichend hohen Schreibraten treten in der Datenbank Konflikte, höhere Latenzen oder andere Fehler auf.

Hohe Lese-, Schreib- und Löschraten für einen engen Dokumentenbereich

Vermeiden Sie hohe Lese- oder Schreibraten, um Dokumente lexikografisch zu schließen, da es sonst zu Konfliktfehlern in Ihrer Anwendung kommt. Dieses Problem wird als Hotspotting bezeichnet, und bei Ihrer Anwendung kann Hotspotting auftreten, wenn eine der folgenden Aktionen ausgeführt wird:

  • Erstellt neue Dokumente mit einer sehr hohen Rate und weist seine eigenen monoton ansteigenden IDs zu.

    Cloud Firestore weist Dokument-IDs mithilfe eines Scatter-Algorithmus zu. Hotspotting bei Schreibvorgängen sollte nicht auftreten, wenn Sie neue Dokumente mit automatischen Dokument-IDs erstellen.

  • Erstellt schnell neue Dokumente in einer Sammlung mit wenigen Dokumenten.

  • Erstellt neue Dokumente mit einem monoton ansteigenden Feld, wie z. B. einem Zeitstempel, mit einer sehr hohen Rate.

  • Löscht Dokumente in einer Sammlung mit hoher Rate.

  • Schreibt mit einer sehr hohen Rate in die Datenbank, ohne den Datenverkehr allmählich zu erhöhen.

Vermeiden Sie es, gelöschte Daten zu überspringen

Vermeiden Sie Abfragen, die kürzlich gelöschte Daten überspringen. Eine Abfrage muss möglicherweise eine große Anzahl von Indexeinträgen überspringen, wenn die frühen Abfrageergebnisse kürzlich gelöscht wurden.

Ein Beispiel für eine Workload, die möglicherweise viele gelöschte Daten überspringen muss, ist eine, die versucht, die ältesten Arbeitsaufgaben in der Warteschlange zu finden. Die Abfrage könnte wie folgt aussehen:

docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
delete_batch.commit()

Jedes Mal, wenn diese Abfrage ausgeführt wird, scannt sie die Indexeinträge für das created Feld in allen kürzlich gelöschten Dokumenten. Dies verlangsamt Abfragen.

Um die Leistung zu verbessern, verwenden Sie die start_at Methode, um den besten Startpunkt zu finden. Zum Beispiel:

completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
    {'created': completed_items.get('last_completed')}).order_by(
        'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
  last_completed = doc.get('created')

if last_completed:
  delete_batch.update(completed_items.reference,
                      {'last_completed': last_completed})
  delete_batch.commit()

HINWEIS: Das obige Beispiel verwendet ein monoton ansteigendes Feld, das ein Antimuster für hohe Schreibraten ist.

Verkehr hochfahren

Sie sollten den Datenverkehr zu neuen Sammlungen schrittweise erhöhen oder Dokumente lexikografisch schließen, um Cloud Firestore genügend Zeit zu geben, Dokumente für den erhöhten Datenverkehr vorzubereiten. Wir empfehlen, mit maximal 500 Vorgängen pro Sekunde zu einer neuen Sammlung zu beginnen und dann den Traffic alle 5 Minuten um 50 % zu erhöhen. Sie können Ihren Schreibdatenverkehr auf ähnliche Weise erhöhen, aber denken Sie an die Cloud Firestore-Standardlimits . Achten Sie darauf, dass die Operationen relativ gleichmäßig über den Tastenbereich verteilt sind. Dies wird als „500/50/5“-Regel bezeichnet.

Datenverkehr in eine neue Sammlung migrieren

Ein schrittweises Hochfahren ist besonders wichtig, wenn Sie App-Traffic von einer Sammlung zu einer anderen migrieren. Eine einfache Möglichkeit, diese Migration zu handhaben, besteht darin, aus der alten Sammlung zu lesen und, wenn das Dokument nicht vorhanden ist, aus der neuen Sammlung zu lesen. Dies könnte jedoch zu einem plötzlichen Anstieg des Datenverkehrs führen, um Dokumente in der neuen Sammlung lexikografisch zu schließen. Cloud Firestore ist möglicherweise nicht in der Lage, die neue Sammlung effizient auf erhöhten Datenverkehr vorzubereiten, insbesondere wenn sie nur wenige Dokumente enthält.

Ein ähnliches Problem kann auftreten, wenn Sie die Dokument-IDs vieler Dokumente innerhalb derselben Sammlung ändern.

Die beste Strategie zum Migrieren von Datenverkehr zu einer neuen Sammlung hängt von Ihrem Datenmodell ab. Nachfolgend finden Sie eine Beispielstrategie, die als parallele Lesevorgänge bekannt ist. Sie müssen bestimmen, ob diese Strategie für Ihre Daten effektiv ist, und eine wichtige Überlegung sind die Kostenauswirkungen paralleler Vorgänge während der Migration.

Parallel liest

Um parallele Lesevorgänge zu implementieren, während Sie Datenverkehr zu einer neuen Sammlung migrieren, lesen Sie zuerst aus der alten Sammlung. Wenn das Dokument fehlt, dann lesen Sie aus der neuen Sammlung. Eine hohe Rate an Lesevorgängen nicht vorhandener Dokumente kann zu Hotspotting führen. Erhöhen Sie daher die Auslastung der neuen Sammlung schrittweise. Eine bessere Strategie besteht darin, das alte Dokument in die neue Sammlung zu kopieren und dann das alte Dokument zu löschen. Parallele Lesevorgänge schrittweise hochfahren, um sicherzustellen, dass Cloud Firestore den Datenverkehr zur neuen Sammlung verarbeiten kann.

Eine mögliche Strategie zum schrittweisen Hochfahren von Lese- oder Schreibvorgängen in eine neue Sammlung besteht darin, einen deterministischen Hash der Benutzer-ID zu verwenden, um einen zufälligen Prozentsatz von Benutzern auszuwählen, die versuchen, neue Dokumente zu schreiben. Stellen Sie sicher, dass das Ergebnis des Benutzer-ID-Hashes weder durch Ihre Funktion noch durch das Benutzerverhalten verzerrt wird.

Führen Sie in der Zwischenzeit einen Batch-Job aus, der alle Ihre Daten aus den alten Dokumenten in die neue Sammlung kopiert. Ihr Batch-Job sollte Schreibvorgänge in sequenzielle Dokument-IDs vermeiden, um Hotspots zu vermeiden. Wenn der Batch-Job abgeschlossen ist, können Sie nur aus der neuen Sammlung lesen.

Eine Verfeinerung dieser Strategie besteht darin, kleine Batches von Benutzern gleichzeitig zu migrieren. Fügen Sie dem Benutzerdokument ein Feld hinzu, das den Migrationsstatus dieses Benutzers verfolgt. Wählen Sie basierend auf einem Hash der Benutzer-ID einen Stapel von Benutzern aus, die migriert werden sollen. Verwenden Sie einen Batch-Job, um Dokumente für diesen Batch von Benutzern zu migrieren, und verwenden Sie parallele Lesevorgänge für Benutzer, die sich mitten in der Migration befinden.

Beachten Sie, dass Sie kein einfaches Rollback durchführen können, es sei denn, Sie führen während der Migrationsphase doppelte Schreibvorgänge sowohl für die alten als auch für die neuen Entitäten durch. Dies würde die anfallenden Cloud Firestore-Kosten erhöhen.

Unbefugten Zugriff verhindern

Verhindern Sie unbefugte Vorgänge in Ihrer Datenbank mit Cloud Firestore-Sicherheitsregeln. Durch die Verwendung von Regeln könnte beispielsweise ein Szenario vermieden werden, in dem ein böswilliger Benutzer wiederholt Ihre gesamte Datenbank herunterlädt.

Erfahren Sie mehr über die Verwendung von Cloud Firestore-Sicherheitsregeln .

,

Verwenden Sie die hier aufgeführten Best Practices als Kurzreferenz beim Erstellen einer Anwendung, die Cloud Firestore verwendet.

Speicherort der Datenbank

Wählen Sie beim Erstellen Ihrer Datenbankinstanz den Datenbankspeicherort aus, der Ihren Benutzern und Rechenressourcen am nächsten liegt. Weitreichende Netzwerksprünge sind fehleranfälliger und erhöhen die Abfragelatenz.

Um die Verfügbarkeit und Dauerhaftigkeit Ihrer Anwendung zu maximieren, wählen Sie einen Standort mit mehreren Regionen aus und platzieren Sie kritische Rechenressourcen in mindestens zwei Regionen.

Wählen Sie einen regionalen Standort aus, um die Kosten zu senken, die Schreiblatenz zu verringern, wenn Ihre Anwendung latenzempfindlich ist, oder für die gemeinsame Nutzung mit anderen GCP-Ressourcen .

Dokument-IDs

  • Vermeiden Sie die Dokument-IDs . und .. .
  • Vermeiden Sie die Verwendung von / -Schrägstrichen in Dokument-IDs.
  • Verwenden Sie keine monoton ansteigenden Dokument-IDs wie:

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

    Solche sequenziellen IDs können zu Hotspots führen, die sich auf die Latenz auswirken.

Feldnamen

  • Vermeiden Sie die folgenden Zeichen in Feldnamen, da sie zusätzliche Escapezeichen erfordern:

    • . Zeitraum
    • [ linke Klammer
    • ] rechte Klammer
    • * Sternchen
    • ` Backtick

Indizes

  • Vermeiden Sie die Verwendung zu vieler Indizes. Eine übermäßige Anzahl von Indizes kann die Schreiblatenz erhöhen und die Speicherkosten für Indexeinträge erhöhen.

  • Beachten Sie, dass das Indizieren von Feldern mit monoton ansteigenden Werten, z. B. Zeitstempeln, zu Hotspots führen kann, die sich auf die Latenz für Anwendungen mit hohen Lese- und Schreibraten auswirken.

Index-Ausnahmen

Bei den meisten Apps können Sie sich bei der Verwaltung Ihrer Indizes auf die automatische Indizierung sowie Links zu Fehlermeldungen verlassen. In den folgenden Fällen möchten Sie jedoch möglicherweise Einzelfeldausnahmen hinzufügen:

Fall Beschreibung
Große Zeichenfolgenfelder

Wenn Sie ein Zeichenfolgenfeld haben, das häufig lange Zeichenfolgenwerte enthält, die Sie nicht für Abfragen verwenden, können Sie die Speicherkosten senken, indem Sie das Feld von der Indizierung ausnehmen.

Hohe Schreibraten in eine Sammlung, die Dokumente mit sequenziellen Werten enthält

Wenn Sie ein Feld indizieren, das zwischen Dokumenten in einer Sammlung sequenziell zunimmt oder abnimmt, wie z. B. ein Zeitstempel, beträgt die maximale Schreibrate in die Sammlung 500 Schreibvorgänge pro Sekunde. Wenn Sie keine Abfrage basierend auf dem Feld mit sequenziellen Werten durchführen, können Sie das Feld von der Indizierung ausnehmen, um dieses Limit zu umgehen.

In einem IoT-Anwendungsfall mit einer hohen Schreibrate könnte beispielsweise eine Sammlung, die Dokumente mit einem Zeitstempelfeld enthält, die Grenze von 500 Schreibvorgängen pro Sekunde erreichen.

TTL-Felder

Wenn Sie TTL-Richtlinien (Time-to-Live) verwenden, beachten Sie, dass das TTL-Feld ein Zeitstempel sein muss. Die Indizierung von TTL-Feldern ist standardmäßig aktiviert und kann die Leistung bei höheren Datenverkehrsraten beeinträchtigen. Fügen Sie als Best Practice Einzelfeldausnahmen für Ihre TTL-Felder hinzu.

Große Array- oder Kartenfelder

Große Array- oder Zuordnungsfelder können die Grenze von 40.000 Indexeinträgen pro Dokument erreichen. Wenn Sie nicht auf der Grundlage eines großen Arrays oder Zuordnungsfelds abfragen, sollten Sie es von der Indizierung ausnehmen.

Lese- und Schreiboperationen

  • Die genaue maximale Rate, mit der eine App ein einzelnes Dokument aktualisieren kann, hängt stark von der Arbeitslast ab. Weitere Informationen finden Sie unter Aktualisierungen eines einzelnen Dokuments .

  • Verwenden Sie asynchrone Aufrufe, sofern verfügbar, anstelle von synchronen Aufrufen. Asynchrone Aufrufe minimieren die Auswirkungen der Latenz. Stellen Sie sich beispielsweise eine Anwendung vor, die das Ergebnis einer Dokumentsuche und die Ergebnisse einer Abfrage benötigt, bevor eine Antwort ausgegeben wird. Wenn die Suche und die Abfrage keine Datenabhängigkeit aufweisen, muss nicht synchron gewartet werden, bis die Suche abgeschlossen ist, bevor die Abfrage gestartet wird.

  • Verwenden Sie keine Offsets. Verwenden Sie stattdessen Cursors . Wenn Sie nur einen Offset verwenden, wird vermieden, dass die übersprungenen Dokumente an Ihre Anwendung zurückgegeben werden, diese Dokumente werden jedoch weiterhin intern abgerufen. Die übersprungenen Dokumente wirken sich auf die Latenz der Abfrage aus, und Ihrer Anwendung werden die zum Abrufen erforderlichen Lesevorgänge in Rechnung gestellt.

Wiederholungen von Transaktionen

Die Cloud Firestore SDKs und Clientbibliotheken wiederholen automatisch fehlgeschlagene Transaktionen, um vorübergehende Fehler zu beheben. Wenn Ihre Anwendung direkt über die REST- oder RPC- APIs statt über ein SDK auf Cloud Firestore zugreift, sollte Ihre Anwendung Transaktionswiederholungen implementieren, um die Zuverlässigkeit zu erhöhen.

Echtzeit-Updates

Für die beste Snapshot-Listener- Leistung sollten Sie Ihre Dokumente klein halten und die Leserate Ihrer Clients kontrollieren. Die folgenden Empfehlungen enthalten Richtlinien zur Maximierung der Leistung. Das Überschreiten dieser Empfehlungen kann zu einer erhöhten Benachrichtigungslatenz führen.

Empfehlung Einzelheiten
Reduzieren Sie die Abwanderungsrate von Snapshot-Listenern

Vermeiden Sie häufig wechselnde Listener, insbesondere wenn Ihre Datenbank unter erheblicher Schreiblast steht

Idealerweise sollte Ihre Anwendung kurz nach dem Öffnen einer Verbindung zu Cloud Firestore alle erforderlichen Snapshot-Listener einrichten. Nachdem Sie Ihre anfänglichen Snapshot-Listener eingerichtet haben, sollten Sie es vermeiden, Snapshot-Listener in derselben Verbindung schnell hinzuzufügen oder zu entfernen.

Um die Datenkonsistenz zu gewährleisten, muss Cloud Firestore jeden neuen Snapshot-Listener aus seinen Quelldaten vorbereiten und dann neue Änderungen nachholen. Abhängig von der Schreibrate Ihrer Datenbank kann dies ein teurer Vorgang sein.

Ihre Snapshot-Listener können eine erhöhte Latenz erfahren, wenn Sie häufig Snapshot-Listener zu Referenzen hinzufügen oder daraus entfernen. Im Allgemeinen schneidet ein ständig verbundener Zuhörer für die gleiche Datenmenge besser ab als das Anschließen und Trennen eines Zuhörers an diesem Ort. Für eine optimale Leistung sollten Snapshot-Listener eine Lebensdauer von 30 Sekunden oder länger haben. Wenn in Ihrer App Probleme mit der Listenerleistung auftreten, versuchen Sie, die Listenings und Delistings Ihrer App zu verfolgen, um festzustellen, ob sie möglicherweise zu häufig auftreten.

Snapshot-Listener pro Client begrenzen

100

Halten Sie die Anzahl der Snapshot-Listener pro Client unter 100.

Begrenzen Sie die Schreibrate der Sammlung

1.000 Operationen/Sekunde

Keep the rate of write operations for an individual collection under 1,000 operations/second.

Limit the individual client push rate

1 document/second

Keep the rate of documents the database pushes to an individual client under 1 document/second.

Limit the global client push rate

1,000,000 documents/second

Keep the rate of documents the database pushes to all clients under 1,000,000 documents/second.

This is a soft limit. Cloud Firestore does not stop you from surpassing this threshold but it greatly affects performance.

Limit the individual document payload

10 KiB/second

Keep the maximum document size downloaded by an individual client under 10 KiB/second.

Limit the global document payload

1 GiB/second

Keep the maximum document size downloaded across all clients under 1 GiB/second.

Limit the number of fields per document

100

Your documents should have fewer than 100 fields.

Understand the Cloud Firestore standard limits

Keep in mind the standard limits for Cloud Firestore .

Pay special attention to the 1 write per second limit for documents and the limit of 1,000,000 concurrent connections per database. These are soft limits that Cloud Firestore does not stop you from exceeding. However, going over these limits might affect performance, depending on your total read and write rates.

Designing for scale

The following best practices describe how to avoid situations that create contention issues.

Updates to a single document

As you design your app, consider how quickly your app updates single documents. The best way to characterize your workload's performance is to perform load testing. The exact maximum rate that an app can update a single document depends highly on the workload. Factors include the write rate, contention among requests, and the number affected indexes.

A document write operation updates the document and any associated indexes, and Cloud Firestore synchronously applies the write operation across a quorum of replicas. At high enough write rates, the database will start to encounter contention, higher latency, or other errors.

High read, write, and delete rates to a narrow document range

Avoid high read or write rates to lexicographically close documents, or your application will experience contention errors. This issue is known as hotspotting, and your application can experience hotspotting if it does any of the following:

  • Creates new documents at a very high rate and allocates its own monotonically increasing IDs.

    Cloud Firestore allocates document IDs using a scatter algorithm. You should not encounter hotspotting on writes if you create new documents using automatic document IDs.

  • Creates new documents at a high rate in a collection with few documents.

  • Creates new documents with a monotonically increasing field, like a timestamp, at a very high rate.

  • Deletes documents in a collection at a high rate.

  • Writes to the database at a very high rate without gradually increasing traffic.

Avoid skipping over deleted data

Avoid queries that skip over recently deleted data. A query may have to skip over a large number of index entries if the early query results have recently been deleted.

An example of a workload that might have to skip over a lot of deleted data is one that tries to find the oldest queued work items. The query might look like:

docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
delete_batch.commit()

Each time this query runs it scans over the index entries for the created field on any recently deleted documents. This slows down queries.

To improve the performance, use the start_at method to find the best place to start. For example:

completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
    {'created': completed_items.get('last_completed')}).order_by(
        'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
  last_completed = doc.get('created')

if last_completed:
  delete_batch.update(completed_items.reference,
                      {'last_completed': last_completed})
  delete_batch.commit()

NOTE: The example above uses a monotonically increasing field which is an anti-pattern for high write rates.

Ramping up traffic

You should gradually ramp up traffic to new collections or lexicographically close documents to give Cloud Firestore sufficient time to prepare documents for increased traffic. We recommend starting with a maximum of 500 operations per second to a new collection and then increasing traffic by 50% every 5 minutes. You can similarly ramp up your write traffic, but keep in mind the Cloud Firestore Standard Limits . Be sure that operations are distributed relatively evenly throughout the key range. This is called the "500/50/5" rule.

Migrating traffic to a new collection

Gradual ramp up is particularly important if you migrate app traffic from one collection to another. A simple way to handle this migration is to read from the old collection, and if the document does not exist, then read from the new collection. However, this could cause a sudden increase of traffic to lexicographically close documents in the new collection. Cloud Firestore may be unable to efficiently prepare the new collection for increased traffic, especially when it contains few documents.

A similar problem can occur if you change the document IDs of many documents within the same collection.

The best strategy for migrating traffic to a new collection depends on your data model. Below is an example strategy known as parallel reads . You will need to determine whether or not this strategy is effective for your data, and an important consideration will be the cost impact of parallel operations during the migration.

Parallel reads

To implement parallel reads as you migrate traffic to a new collection, read from the old collection first. If the document is missing, then read from the new collection. A high rate of reads of non-existent documents can lead to hotspotting, so be sure to gradually increase load to the new collection. A better strategy is to copy the old document to the new collection then delete the old document. Ramp up parallel reads gradually to ensure that Cloud Firestore can handle traffic to the new collection.

A possible strategy for gradually ramping up reads or writes to a new collection is to use a deterministic hash of the user ID to select a random percentage of users attempting to write new documents. Be sure that the result of the user ID hash is not skewed either by your function or by user behavior.

Meanwhile, run a batch job that copies all your data from the old documents to the new collection. Your batch job should avoid writes to sequential document IDs in order to prevent hotspots. When the batch job finishes, you can read only from the new collection.

A refinement of this strategy is to migrate small batches of users at a time. Add a field to the user document which tracks migration status of that user. Select a batch of users to migrate based on a hash of the user ID. Use a batch job to migrate documents for that batch of users, and use parallel reads for users in the middle of migration.

Note that you cannot easily roll back unless you do dual writes of both the old and new entities during the migration phase. This would increase Cloud Firestore costs incurred.

Prevent unauthorized access

Prevent unauthorized operations on your database with Cloud Firestore Security Rules. For example, using rules could avoid a scenario where a malicious user repeatedly downloads your entire database.

Learn more about using Cloud Firestore Security Rules .

,

Use the best practices listed here as a quick reference when building an application that uses Cloud Firestore.

Database location

When you create your database instance, select the database location closest to your users and compute resources. Far-reaching network hops are more error-prone and increase query latency.

To maximize the availability and durability of your application, select a multi-region location and place critical compute resources in at least two regions.

Select a regional location for lower costs, for lower write latency if your application is sensitive to latency, or for co-location with other GCP resources .

Document IDs

  • Avoid the document IDs . and .. .
  • Avoid using / forward slashes in document IDs.
  • Do not use monotonically increasing document IDs such as:

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

    Such sequential IDs can lead to hotspots that impact latency.

Field Names

  • Avoid the following characters in field names because they require extra escaping:

    • . period
    • [ left bracket
    • ] right bracket
    • * asterisk
    • ` backtick

Indexes

  • Avoid using too many indexes. An excessive number of indexes can increase write latency and increases storage costs for index entries.

  • Be aware that indexing fields with monotonically increasing values, such as timestamps, can lead to hotspots which impact latency for applications with high read and write rates.

Index exemptions

For most apps, you can rely on automatic indexing as well as any error message links to manage your indexes. However, you may want to add single-field exemptions in the following cases:

Case Description
Large string fields

If you have a string field that often holds long string values that you don't use for querying, you can cut storage costs by exempting the field from indexing.

High write rates to a collection containing documents with sequential values

If you index a field that increases or decreases sequentially between documents in a collection, like a timestamp, then the maximum write rate to the collection is 500 writes per second. If you don't query based on the field with sequential values, you can exempt the field from indexing to bypass this limit.

In an IoT use case with a high write rate, for example, a collection containing documents with a timestamp field might approach the 500 writes per second limit.

TTL fields

If you use TTL (time-to-live) policies , note that the TTL field must be a timestamp. Indexing on TTL fields is enabled by default and can affect performance at higher traffic rates. As a best practice, add single-field exemptions for your TTL fields.

Large array or map fields

Large array or map fields can approach the limit of 40,000 index entries per document. If you are not querying based on a large array or map field, you should exempt it from indexing.

Read and write operations

  • The exact maximum rate that an app can update a single document depends highly on the workload. For more information, see Updates to a single document .

  • Use asynchronous calls where available instead of synchronous calls. Asynchronous calls minimize latency impact. For example, consider an application that needs the result of a document lookup and the results of a query before rendering a response. If the lookup and the query do not have a data dependency, there is no need to synchronously wait until the lookup completes before initiating the query.

  • Do not use offsets. Instead, use cursors . Using an offset only avoids returning the skipped documents to your application, but these documents are still retrieved internally. The skipped documents affect the latency of the query, and your application is billed for the read operations required to retrieve them.

Transactions retries

The Cloud Firestore SDKs and client libraries automatically retry failed transactions to deal with transient errors. If your application accesses Cloud Firestore through the REST or RPC APIs directly instead of through an SDK, your application should implement transaction retries to increase reliability.

Realtime updates

For the best snapshot listener performance, keep your documents small and control the read rate of your clients. The following recommendations provide guidelines for maximizing performance. Exceeding these recommendations can result in increased notification latency.

Recommendation Details
Reduce snapshot listener churn rate

Avoid frequently churning listeners, especially when your database is under significant write load

Ideally, your application should set up all the required snapshot listeners soon after opening a connection to Cloud Firestore. After setting up your initial snapshot listeners, you should avoid quickly adding or removing snapshot listeners in the same connection.

To ensure data consistency, Cloud Firestore needs to prime each new snapshot listener from its source data and then catch up to new changes. Depending on your database's write rate, this can be an expensive operation.

Your snapshot listeners can experience increased latency if you frequently add or remove snapshot listeners to references. In general, a constantly-attached listener performs better than attaching and detaching a listener at that location for the same amount of data. For best performance, snapshot listeners should have a lifetime of 30 seconds or longer. If you encounter listener performance issues in your app, try tracking your app's listens and unlistens to determine if they may be happening too frequently.

Limit snapshot listeners per client

100

Keep the number of snapshot listeners per client under 100.

Limit the collection write rate

1,000 operations/second

Keep the rate of write operations for an individual collection under 1,000 operations/second.

Limit the individual client push rate

1 document/second

Keep the rate of documents the database pushes to an individual client under 1 document/second.

Limit the global client push rate

1,000,000 documents/second

Keep the rate of documents the database pushes to all clients under 1,000,000 documents/second.

This is a soft limit. Cloud Firestore does not stop you from surpassing this threshold but it greatly affects performance.

Limit the individual document payload

10 KiB/second

Keep the maximum document size downloaded by an individual client under 10 KiB/second.

Limit the global document payload

1 GiB/second

Keep the maximum document size downloaded across all clients under 1 GiB/second.

Limit the number of fields per document

100

Your documents should have fewer than 100 fields.

Understand the Cloud Firestore standard limits

Keep in mind the standard limits for Cloud Firestore .

Pay special attention to the 1 write per second limit for documents and the limit of 1,000,000 concurrent connections per database. These are soft limits that Cloud Firestore does not stop you from exceeding. However, going over these limits might affect performance, depending on your total read and write rates.

Designing for scale

The following best practices describe how to avoid situations that create contention issues.

Updates to a single document

As you design your app, consider how quickly your app updates single documents. The best way to characterize your workload's performance is to perform load testing. The exact maximum rate that an app can update a single document depends highly on the workload. Factors include the write rate, contention among requests, and the number affected indexes.

A document write operation updates the document and any associated indexes, and Cloud Firestore synchronously applies the write operation across a quorum of replicas. At high enough write rates, the database will start to encounter contention, higher latency, or other errors.

High read, write, and delete rates to a narrow document range

Avoid high read or write rates to lexicographically close documents, or your application will experience contention errors. This issue is known as hotspotting, and your application can experience hotspotting if it does any of the following:

  • Creates new documents at a very high rate and allocates its own monotonically increasing IDs.

    Cloud Firestore allocates document IDs using a scatter algorithm. You should not encounter hotspotting on writes if you create new documents using automatic document IDs.

  • Creates new documents at a high rate in a collection with few documents.

  • Creates new documents with a monotonically increasing field, like a timestamp, at a very high rate.

  • Deletes documents in a collection at a high rate.

  • Writes to the database at a very high rate without gradually increasing traffic.

Avoid skipping over deleted data

Avoid queries that skip over recently deleted data. A query may have to skip over a large number of index entries if the early query results have recently been deleted.

An example of a workload that might have to skip over a lot of deleted data is one that tries to find the oldest queued work items. The query might look like:

docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
delete_batch.commit()

Each time this query runs it scans over the index entries for the created field on any recently deleted documents. This slows down queries.

To improve the performance, use the start_at method to find the best place to start. For example:

completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
    {'created': completed_items.get('last_completed')}).order_by(
        'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
  last_completed = doc.get('created')

if last_completed:
  delete_batch.update(completed_items.reference,
                      {'last_completed': last_completed})
  delete_batch.commit()

NOTE: The example above uses a monotonically increasing field which is an anti-pattern for high write rates.

Ramping up traffic

You should gradually ramp up traffic to new collections or lexicographically close documents to give Cloud Firestore sufficient time to prepare documents for increased traffic. We recommend starting with a maximum of 500 operations per second to a new collection and then increasing traffic by 50% every 5 minutes. You can similarly ramp up your write traffic, but keep in mind the Cloud Firestore Standard Limits . Be sure that operations are distributed relatively evenly throughout the key range. This is called the "500/50/5" rule.

Migrating traffic to a new collection

Gradual ramp up is particularly important if you migrate app traffic from one collection to another. A simple way to handle this migration is to read from the old collection, and if the document does not exist, then read from the new collection. However, this could cause a sudden increase of traffic to lexicographically close documents in the new collection. Cloud Firestore may be unable to efficiently prepare the new collection for increased traffic, especially when it contains few documents.

A similar problem can occur if you change the document IDs of many documents within the same collection.

The best strategy for migrating traffic to a new collection depends on your data model. Below is an example strategy known as parallel reads . You will need to determine whether or not this strategy is effective for your data, and an important consideration will be the cost impact of parallel operations during the migration.

Parallel reads

To implement parallel reads as you migrate traffic to a new collection, read from the old collection first. If the document is missing, then read from the new collection. A high rate of reads of non-existent documents can lead to hotspotting, so be sure to gradually increase load to the new collection. A better strategy is to copy the old document to the new collection then delete the old document. Ramp up parallel reads gradually to ensure that Cloud Firestore can handle traffic to the new collection.

A possible strategy for gradually ramping up reads or writes to a new collection is to use a deterministic hash of the user ID to select a random percentage of users attempting to write new documents. Be sure that the result of the user ID hash is not skewed either by your function or by user behavior.

Meanwhile, run a batch job that copies all your data from the old documents to the new collection. Your batch job should avoid writes to sequential document IDs in order to prevent hotspots. When the batch job finishes, you can read only from the new collection.

A refinement of this strategy is to migrate small batches of users at a time. Add a field to the user document which tracks migration status of that user. Select a batch of users to migrate based on a hash of the user ID. Use a batch job to migrate documents for that batch of users, and use parallel reads for users in the middle of migration.

Note that you cannot easily roll back unless you do dual writes of both the old and new entities during the migration phase. This would increase Cloud Firestore costs incurred.

Prevent unauthorized access

Prevent unauthorized operations on your database with Cloud Firestore Security Rules. For example, using rules could avoid a scenario where a malicious user repeatedly downloads your entire database.

Learn more about using Cloud Firestore Security Rules .