Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Best Practices

Die hier aufgeführten Best Practices bieten eine Kurzreferenz, wenn Sie eine Anwendung erstellen, die Firestore verwendet.

Datenbankspeicherort

Wählen Sie beim Erstellen Ihrer Datenbankinstanz den Datenbankspeicherort aus, der Ihren Nutzern und Rechenressourcen am nächsten ist. Weit reichende Netzwerk-Hops sind fehleranfälliger und erhöhen die Abfragelatenz.

Wählen Sie zum Maximieren der Verfügbarkeit und Langlebigkeit Ihrer Anwendung einen Standort mit mehreren Regionen aus und platzieren Sie wichtige Rechenressourcen in mindestens zwei Regionen.

Wählen Sie einen regionalen Standort aus, um die Kosten niedrig zu halten, um eine niedrige Schreiblatenz zu erzielen, wenn Ihre Anwendung empfindlich auf Latenz reagiert, oder um die Datenbank gemeinsam mit anderen GCP-Ressourcen am selben Standort zu speichern.

Dokument-IDs

  • Vermeiden Sie die Dokument-IDs . und ...
  • Verwenden Sie in Dokument-IDs keine Schrägstriche (/).
  • Verwenden Sie keine kontinuierlich ansteigenden Dokument-IDs, z. B.:

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

    Solche aufeinanderfolgenden IDs können zum Heißlaufen führen, was sich auf die Latenz auswirkt.

Feldnamen

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

    • Punkt (.)
    • Eckige Klammer links ([)
    • Eckige Klammer rechts (])
    • Sternchen (*)
    • Backtick (`)

Indexe

  • Vermeiden Sie zu viele Indexe. Eine zu große Anzahl von Indexen kann die Schreiblatenz und damit die Speicherkosten für Indexeinträge erhöhen.

  • Beachten Sie, dass die Indexierung von Feldern mit kontinuierlich steigenden Werten wie Zeitstempeln zum Heißlaufen führen kann, was sich auf die Latenz bei Anwendungen mit hohen Lese- und Schreibraten auswirkt.

Indexausnahmen

Bei den meisten Anwendungen sind die automatische Indexierung sowie Fehlermeldungslinks zur Verwaltung der Indexe ausreichend. In den folgenden Fällen können Sie aber Ausnahmen für einzelne Felder hinzufügen:

Case Beschreibung
Große Stringfelder

Wenn Sie ein Stringfeld haben, das oft lange Stringwerte enthält, die Sie nicht für Abfragen verwenden, können Sie die Speicherkosten senken, indem Sie das Feld von der Indexierung ausnehmen.

Hohe Schreibraten für eine Sammlung, die Dokumente mit aufeinanderfolgenden Werten enthält

Wenn Sie ein Feld indexieren, dessen Werte über die Dokumente einer Sammlung hinweg kontinuierlich zu- oder abnehmen, z. B. im Fall eines Zeitstempels, beträgt die maximale Schreibrate für die Sammlung 500 Schreibvorgänge pro Sekunde. Wenn Sie keine Abfrage basierend auf dem Feld mit aufeinanderfolgenden Werten durchführen, können Sie das Feld von der Indexierung ausnehmen, um dieses Limit zu umgehen.

In einem IoT-Anwendungsfall mit einer hohen Schreibrate kann sich beispielsweise eine Sammlung, die Dokumente mit einem Zeitstempelfeld enthält, dem Limit von 500 Schreibvorgängen pro Sekunde nähern.

Große Array- oder Map-Felder

Große Array- oder Kartenfelder können sich dem Limit von 40.000 Indexeinträgen pro Dokument nähern. Wenn Sie keine Abfragen basierend auf einem großen Array- oder Kartenfeld durchführen, sollten Sie dieses von der Indexierung ausnehmen.

Lese- und Schreibvorgänge

  • Vermeiden Sie es, mehr als einmal pro Sekunde in ein Dokument zu schreiben. Weitere Informationen finden Sie unter Aktualisierungen für ein einzelnes Dokument.

  • Verwenden Sie sofern verfügbar asynchrone Aufrufe anstelle von synchronen Aufrufen. Asynchrone Aufrufe minimieren die Auswirkung auf die Latenz. Angenommen, eine Anwendung benötigt das Ergebnis eines Dokument-Lookups sowie die Ergebnisse einer Abfrage, bevor eine Antwort gerendert wird. Wenn der Lookup und die Abfrage keine Datenabhängigkeit haben, muss nicht synchron auf den Abschluss des Lookups gewartet werden, bevor die Abfrage initiiert wird.

  • Verwenden Sie keine Offsets. Verwenden Sie stattdessen Cursors. Wenn Sie einen Offset verwenden, werden die übersprungenen Dokumente nicht an Ihre Anwendung zurückgegeben, werden aber 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.

Wiederholungsversuche für Transaktionen

Die SDKs und Clientbibliotheken von Firestore wiederholen fehlgeschlagene Transaktionen automatisch, um vorübergehende Fehler zu beheben. Wenn Ihre Anwendung direkt über die REST API oder die RPC API statt über ein SDK auf Firestore zugreift, sollte Ihre Anwendung Transaktionswiederholungen ausführen. Dies erhöht die Zuverlässigkeit.

Echtzeitaktualisierungen

Für die optimale Snapshot-Listener-Leistung sollten Sie Ihre Dokumente klein halten und die Leserate Ihrer Clients unter Kontrolle halten. Unten sehen Sie einige Empfehlungen zur Maximierung der Leistung. Das Überschreiten dieser Empfehlungswerte kann die Latenz von Benachrichtigungen erhöhen.

Empfehlung Details
Churn-Rate von Snapshot-Listenern verringern

Achten Sie darauf, dass Listener nicht immer wieder unterbrochen werden, insbesondere wenn Ihre Datenbank eine hohe Schreiblast aufweist.

Idealerweise werden von Ihrer Anwendung alle erforderlichen Snapshot-Listener eingerichtet, sobald eine Verbindung zu Firestore hergestellt wurde. Nach der Einrichtung der ersten Snapshot-Listener sollten Sie es vermeiden, derselben Verbindung sofort weitere Snapshot-Listener hinzuzufügen oder daraus zu entfernen.

Um die Datenkonsistenz zu gewährleisten, muss Firestore jeden neuen Snapshot-Listener anhand der Quelldaten vorbereiten und dann die sich daraus ergebenden Änderungen erfassen. Abhängig von der Schreibrate Ihrer Datenbank kann dies ein aufwändiger Vorgang sein.

Ihre Snapshot-Listener können eine erhöhte Latenz aufweisen, wenn Sie regelmäßig Snapshot-Listener zu Referenzen hinzufügen oder davon entfernen. Im Allgemeinen ist ein kontinuierlich angehängter Listener besser, als an diesem Standort für dieselbe Datenmenge einen Listener anzuhängen und zu trennen. Für eine optimale Leistung sollten Snapshot-Listener eine Lebensdauer von mindestens 30 Sekunden haben. Wenn bei der Anwendung Probleme mit der Listener-Leistung auftreten, versuchen Sie, das Starten und Beenden der Überwachung durch die Anwendung nachzuverfolgen, um zu sehen, wie häufig dies geschieht.

Snapshot-Listener pro Client beschränken

100

Die Anzahl der Snapshot-Listener pro Client muss unter 100 liegen.

Schreibrate einer Sammlung beschränken

1.000 Vorgänge pro Sekunde

Die Rate der Schreibvorgänge für eine einzelne Sammlung sollte unter 1.000 Vorgängen pro Sekunde liegen.

Push-Rate einzelner Clients beschränken

1 Dokument/Sekunde

Halten Sie die Anzahl der Dokumente, die die Datenbank per Push an einen einzelnen Client sendet, unter 1 Dokument pro Sekunde.

Globale Client-Push-Rate beschränken

1.000.000 Dokumente pro Sekunde

Halten Sie die Anzahl der Dokumente, die die Datenbank per Push an sämtliche Clients sendet, unter 1.000.000 Dokumenten pro Sekunde.

Nutzlast einzelner Dokumente beschränken

10 KiB/Sekunde

Halten Sie die Größe einzelner Dokumente, die von einem einzelnen Client heruntergeladen werden, unter 10 KiB pro Sekunde.

Globale Dokumentnutzlast beschränken

1 GiB/Sekunde

Halten Sie die Gesamtgröße der Dokumente, die von sämtlichen Clients heruntergeladen werden, unter 1 GiB pro Sekunde.

Anzahl der Felder pro Dokument beschränken

100

Ihre Dokumente sollten weniger als 100 Felder enthalten.

Mit den standardmäßigen Firestore-Limits vertraut machen

Beachten Sie die Standardlimits für Firestore, insbesondere das Limit von 1 Schreibvorgang pro Sekunde für Dokumente sowie das Limit von 1.000.000 gleichzeitigen Verbindungen pro Datenbank.

Skalierbares Programmdesign

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

Aktualisierungen für ein einzelnes Dokument

Sie sollten ein einzelnes Dokument nicht öfter als einmal pro Sekunde aktualisieren. Wenn Sie ein Dokument zu häufig aktualisieren, kommt es in Ihrer Anwendung zu Konflikten, einschließlich erhöhter Latenz, Zeitüberschreitungen und anderer Fehler.

Hoher Lese-, Schreib- und Löschraten für einen kleinen Dokumentbereich

Vermeiden Sie hohe Lese- oder Schreibraten bei Dokumenten, die lexikografisch eng beieinanderliegen. Andernfalls treten bei Ihrer Anwendung Konfliktfehler auf. Dieses Problem wird als Heißlaufen bezeichnet. Dazu kann es bei Ihrer Anwendung kommen, wenn sie eine der folgenden Aktionen ausführt:

  • Sie erstellt neue Dokumente mit einer sehr hohen Rate und ordnet ihre eigenen kontinuierlich ansteigenden IDs zu.

    Firestore ordnet Dokument-IDs mithilfe eines Streuungsalgorithmus zu. Wenn Sie neue Dokumente mit automatischen Dokument-IDs erstellen, sollte es bei Schreibvorgängen nicht zu einem Heißlaufen kommen.

  • Sie erstellt neue Dokumente in einer Sammlung mit wenigen Dokumenten mit einer hohen Rate.

  • Sie erstellt mit einer sehr hohen Rate neue Dokumente mit einem kontinuierlich zunehmenden Feld, z. B. einem Zeitstempel.

  • Sie löscht Dokumente in einer Sammlung mit einer hohen Rate.

  • Sie schreibt mit einer sehr hohen Rate in die Datenbank, ohne den Traffic nach und nach zu erhöhen.

Traffic erhöhen

Sie sollten den Traffic zu neuen Sammlungen oder lexikografisch eng beieinanderliegenden Dokumenten schrittweise erhöhen, damit Firestore genügend Zeit hat, Dokumente auf den erhöhten Traffic vorzubereiten. Wir empfehlen, bei einer neuen Sammlung mit maximal 500 Vorgängen pro Sekunde zu beginnen und den Traffic dann alle 5 Minuten um 50 % zu erhöhen. Beispielsweise können Sie mit diesem Erhöhungsplan den Lesetraffic innerhalb von 90 Minuten auf 740.000 Vorgänge pro Sekunde steigern. Auf ähnliche Weise lässt sich auch der Schreibtraffic erhöhen. Beachten Sie dabei aber die Standardlimits von Firestore. Achten Sie darauf, dass die Vorgänge relativ gleichmäßig über den Schlüsselbereich verteilt sind. Dies wird als "500/50/5"-Regel bezeichnet.

Traffic zu einer neuen Sammlung migrieren

Die schrittweise Erhöhung ist besonders wichtig, wenn Sie den Anwendungs-Traffic von einer Sammlung zu einer anderen migrieren. Eine einfache Möglichkeit zur Umsetzung dieser Migration besteht darin, aus der alten Sammlung zu lesen. Wenn das Dokument nicht vorhanden ist, lesen Sie aus der neuen Sammlung. Dies kann aber zu einem plötzlichen Anstieg des Traffics zu lexikografisch eng beieinanderliegenden Dokumenten in der neuen Sammlung führen. Firestore ist möglicherweise nicht in der Lage, die neue Sammlung effizient auf erhöhten Traffic vorzubereiten, insbesondere wenn sie nur wenige Dokumente enthält.

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

Die beste Strategie für die Migration des Traffics zu einer neuen Sammlung hängt von Ihrem Datenmodell ab. Unten sehen Sie eine Beispielstrategie, die als parallele Lesevorgänge bezeichnet wird. Sie müssen prüfen, ob diese Strategie für Ihre Daten effektiv ist. Ein wichtiger Aspekt sind die Kosten paralleler Vorgänge während der Migration.

Parallele Lesevorgänge

Um für das Migrieren des Traffics zu einer neuen Sammlung parallele Lesevorgänge zu implementieren, lesen Sie zuerst aus der alten Sammlung. Wenn das Dokument fehlt, lesen Sie aus der neuen Sammlung. Eine hohe Rate von Lesevorgängen in nicht vorhandenen Dokumenten kann zum Heißlaufen führen. Achten Sie daher darauf, dass die Last für die neue Sammlung nur allmählich erhöht wird. Eine bessere Strategie besteht darin, das alte Dokument in die neue Sammlung zu kopieren und dann zu löschen. Erhöhen Sie parallele Lesevorgänge schrittweise, um zu gewährleisten, dass Firestore den Traffic zur neuen Sammlung verarbeiten kann.

Ein mögliches Vorgehen zur schrittweisen Steigerung von Lese- oder Schreibvorgängen für eine neue Sammlung ist die Verwendung eines deterministischen Hash-Werts der Nutzer-ID. Damit kann per Zufallsprinzip ein Teil der Nutzer ausgewählt werden, die versuchen, in neue Dokumente zu schreiben. Achten Sie darauf, dass das Ergebnis des Nutzer-ID-Hash-Werts weder durch die Funktion noch durch das Nutzerverhalten verzerrt wird.

Führen Sie einen Batchjob aus, durch den alle Ihre Daten aus den alten Dokumenten in die neue Sammlung kopiert werden. Der Batchjob sollte Schreibvorgänge für aufeinanderfolgende Dokument-IDs vermeiden, damit es zu keinem Heißlaufen kommt. Wenn der Batchjob abgeschlossen ist, können Sie nur aus der neuen Sammlung lesen.

Eine Verfeinerung dieser Strategie besteht darin, kleine Batches von Nutzern gleichzeitig zu migrieren. Fügen Sie dem Nutzerdokument ein Feld hinzu, das den Migrationsstatus des entsprechenden Nutzers verfolgt. Wählen Sie einen Batch von zu migrierenden Nutzern basierend auf einem Hash-Wert der Nutzer-ID aus. Verwenden Sie einen Batchjob, um Dokumente für diesen Batch von Nutzern zu migrieren, und verwenden Sie parallele Lesevorgänge für Nutzer, die gerade migriert werden.

Beachten Sie, dass ein Rollback nur dann problemlos ausgeführt werden kann, wenn Sie bei der Migration doppelte Schreibvorgänge für die alten wie für die neuen Entitäten vornehmen. Dadurch steigen allerdings die anfallenden Firestore-Kosten.