Echtzeitabfragen im großen Maßstab verstehen
In diesem Dokument finden Sie eine Anleitung zum Skalieren Ihrer serverlosen Anwendung über Tausende von Vorgängen pro Sekunde oder Hunderttausende gleichzeitiger Nutzer. Dieses Dokument enthält weiterführende Themen zur Sie das System im Detail verstehen. Wenn Sie gerade erst mit Informationen zu Firestore finden Sie in der Kurzanleitung.
Firestore und die Firebase Mobile/Web SDKs bieten ein leistungsstarkes Modell für die Entwicklung serverloser Anwendungen, bei denen clientseitiger Code direkt auf die Datenbank. Mit den SDKs können Clients in Echtzeit Aktualisierungen der Daten überwachen. Ich Echtzeit-Updates nutzen, um responsive Apps zu erstellen, die keine Server erfordern und Infrastruktur. Es ist zwar sehr einfach, etwas einzurichten, um die Einschränkungen in den Systemen von Firestore zu verstehen. damit Ihre serverlose Anwendung skaliert wird und auch bei steigendem Traffic eine gute Leistung erzielt.
In den folgenden Abschnitten finden Sie Tipps zur Skalierung Ihrer App.
Datenbankspeicherort in der Nähe der Nutzer auswählen
Das folgende Diagramm zeigt die Architektur einer Echtzeitanwendung:
Wenn eine App, die auf dem Gerät eines Nutzers ausgeführt wird (Mobilgerät oder Web), eine
Verbindung zu Firestore weitergeleitet wird,
Firestore-Frontend-Server im selben
Region, in der sich Ihre Datenbank befindet. Beispiel:
Wenn sich Ihre Datenbank in us-east1 befindet, geht die Verbindung auch zu einem
Firestore-Front-End auch in us-east1. Diese Verbindungen sind
und bleiben geöffnet, bis sie von der App explizit geschlossen werden. Die
Frontend liest Daten aus den zugrunde liegenden Firestore-Speichersystemen.
Die Entfernung zwischen dem physischen Standort eines Nutzers und Firestore Datenbankstandort sich auf die Latenz des Nutzers auswirkt. Beispiel: Nutzer in Indien, dessen App mit einer Datenbank in einer Google Cloud-Region in Nordamerika kommuniziert die Nutzung langsamer und die App weniger knackig, als wenn die Datenbank sich näher befinden, etwa in Indien oder in einem anderen Teil Asiens.
Einhaltung von Zuverlässigkeitsvorgaben
Die folgenden Themen verbessern oder beeinflussen die Zuverlässigkeit Ihrer App:
Offlinemodus aktivieren
Die Firebase SDKs ermöglichen Offline-Datenpersistenz. Wenn die App auf dem Gerät des Nutzers keine Verbindung zu Firestore herstellen kann, bleibt sie durch die Verwendung lokal im Cache gespeicherter Daten nutzbar. Dadurch wird sichergestellt, dass auch wenn die Internetverbindung schlecht oder unterbrochen ist. mehrere Stunden oder Tage lang vollständig den Zugriff verlieren. Weitere Informationen zu Informationen zum Aktivieren des Offlinemodus finden Sie unter Offlinedaten aktivieren.
Informationen zu automatischen Wiederholungsversuchen
Die Firebase SDKs sorgen für Wiederholungsvorgänge und Wiederherstellungen unterbrochene Verbindungen. So können Sie vorübergehende Fehler vermeiden, durch einen Neustart von Servern oder Netzwerkproblemen zwischen Client und Datenbank.
Zwischen regionalen und multiregionalen Standorten wählen
Bei der Auswahl zwischen regionalen und multiregionalen Standorten gibt es mehrere Abwägungen. Der Hauptunterschied besteht darin, wie Daten repliziert werden. Dieses für die Verfügbarkeitsgarantien Ihrer App. Eine multiregionale Instanz sorgt für eine höhere Bereitstellungs- und Langlebigkeit Ihrer Daten, der Kompromiss sind die Kosten.
Das Echtzeit-Abfragesystem verstehen
Echtzeitabfragen, auch Snapshot-Listener genannt, ermöglichen es der App, in der Datenbank ändern und Benachrichtigungen mit niedriger Latenz erhalten, Änderungen. Eine Anwendung kann das gleiche Ergebnis erhalten, indem sie die Datenbank regelmäßig nach ist jedoch oft langsamer und teurer und erfordert mehr Code. Für Beispiele für die Einrichtung und Verwendung von Echtzeitabfragen finden Sie unter Echtzeitinformationen erhalten Die folgenden Abschnitte wie Snapshot-Listener funktionieren, und beschreiben Sie der Best Practices für die Skalierung von Echtzeitabfragen bei gleichbleibender Leistung.
Stellen Sie sich zwei Nutzer vor, die über eine App, die mit einem der mobilen SDKs erstellt wurde.
Client A schreibt in die Datenbank, um Dokumente in einer Sammlung hinzuzufügen und zu aktualisieren.
mit dem Namen chatroom:
collection chatroom:
document message1:
from: 'Sparky'
message: 'Welcome to Firestore!'
document message2:
from: 'Santa'
message: 'Presents are coming'
Client B wartet mit einem Snapshot-Listener auf Aktualisierungen in derselben Sammlung. Kunde B wird sofort benachrichtigt, wenn jemand eine neue Nachricht erstellt. Das folgende Diagramm zeigt die Architektur hinter einem Snapshot-Listener:
Die folgende Ereignissequenz findet statt, wenn Client B einen Snapshot verbindet Listener für die Datenbank:
- Client B öffnet eine Verbindung zu Firestore und registriert einen
indem Sie
onSnapshot(collection("chatroom"))über das Firebase SDK. Dieser Listener kann stundenlang aktiv bleiben. - Das Firestore-Frontend fragt das zugrunde liegende Speichersystem ab zum Bootstrapping des Datasets. Es werden alle übereinstimmenden Ergebnisse geladen. Dokumente. Dies wird als Abfrage bezeichnet. Das System die Leistung der Datenbank auswertet, Firebase-Sicherheitsregeln für um zu prüfen, ob der Nutzer auf diese Daten zugreifen kann. Wenn der Nutzer autorisiert ist, gibt die Datenbank die Daten an den Nutzer zurück.
- Die Abfrage von Client B wird dann in den Wartemodus verschoben. Der Listener registriert die mit einem Abo-Handler und wartet auf Aktualisierungen der Daten.
- Client A sendet jetzt einen Schreibvorgang zum Ändern eines Dokuments.
- Die Datenbank überträgt die Dokumentänderung Speichersystem.
- Transaktionsweise überträgt das System dasselbe Update an eine interne changelog. Das Änderungsprotokoll legt eine strikte Reihenfolge der Änderungen fest, sie passieren.
- Beim Änderungsprotokoll werden die aktualisierten Daten dann auf einen Pool von Abonnements ausgeweitet. Handler.
- Ein umgekehrter Abfrage-Matcher wird ausgeführt, um festzustellen, ob das aktualisierte Dokument übereinstimmt. Alle aktuell registrierten Snapshot-Listener. In diesem Beispiel enthält das Dokument entspricht dem Snapshot-Listener von Client B. Wie der Name schon sagt, können Sie sich den umgekehrten Abfrage-Matcher als normale Datenbankabfrage, aber in umgekehrter Reihenfolge. Anstatt in Dokumenten nach übereinstimmenden Dokumenten zu suchen, Abfragen, um diejenigen zu finden, die mit einem eingehenden Dokument übereinstimmen. Bei einer Übereinstimmung leitet das System das betreffende Dokument an die Snapshot-Listener weiter. Anschließend wertet das System die Firebase-Sicherheitsregeln der Datenbank aus. damit nur autorisierte Nutzer die Daten erhalten.
- Das System leitet die Dokumentaktualisierung an das SDK auf dem Gerät von Client B weiter und
wird der
onSnapshot-Callback ausgelöst. Wenn die lokale Persistenz aktiviert ist, wendet das Update auch auf den lokalen Cache an.
Ein wichtiger Teil der Skalierbarkeit von Firestore hängt vom Fan-Out dem Änderungsprotokoll zu den Abo-Handlern und den Frontend-Servern. Die Durch Fan-Out kann eine einzelne Datenänderung effizient weitergegeben werden und Millionen von Echtzeitabfragen und vernetzte Nutzer. Durch das Ausführen vieler Replikate all dieser Komponenten über mehrere Zonen (oder mehrere Regionen bei einem multiregionalen Standort) Bereitstellung) erreicht, erreicht Firestore Hochverfügbarkeit und Skalierbarkeit.
Alle Lesevorgänge, die von mobilen und Web-SDKs ausgegeben werden, befolgen Sie das obige Modell. Sie führen eine Abfrageabfrage gefolgt vom Überwachungsmodus durch. um Konsistenzgarantien zu gewährleisten. Das gilt auch für Echtzeit-Zuhörer, Aufrufe zum Abrufen eines Dokuments und One-Shot-Abfragen. Stellen Sie sich vor, Dokumentabrufe und One-Shot-Abfragen als kurzlebige Snapshot-Listener, mit ähnlichen Einschränkungen in Bezug auf die Leistung.
Best Practices für die Skalierung von Echtzeitabfragen anwenden
Wenden Sie die folgenden Best Practices an, um skalierbare Echtzeitabfragen zu entwerfen.
Hohe Anzahl von Schreibvorgängen im System verstehen
In diesem Abschnitt erfahren Sie, wie das System auf eine steigende Anzahl von Schreibanfragen reagiert.
Firestore-Änderungslogs, die den Echtzeitabfragen zugrunde liegen automatisch horizontal skaliert werden, wenn der Schreib-Traffic steigt. Als Schreibrate für eine Datenbank übersteigt, was ein einzelner Server verarbeiten kann, wird das Änderungsprotokoll auf mehrere Server aufgeteilt und die Abfrageverarbeitung beginnt, Daten von mehreren Abo-Handlern statt von einem verarbeiten. Wählen Sie im aus Sicht des Clients und des SDKs ist dies transparent und es sind keine Maßnahmen erforderlich. aus der App angezeigt, wenn es zu Spaltungen kommt. Das folgende Diagramm zeigt, Echtzeitabfragen skalieren:
Mit Autoscaling können Sie den Schreibtraffic uneingeschränkt erhöhen, aber wenn der Verkehr zunimmt, kann es eine Weile dauern, bis das System reagiert. Folgen Sie den Empfehlungen der 5-5-5-Regel, um das Erstellen eines Schreibhotspots zu vermeiden. Key Visualizer ist ein ein nützliches Tool zur Analyse von Schreib-Hotspots.
Viele Anwendungen weisen ein vorhersehbares organisches Wachstum auf, das Firestore durch ohne Vorsichtsmaßnahmen einzugehen. Batch-Arbeitslasten wie das Importieren eines großen Dataset jedoch die Zahl der Schreibvorgänge zu schnell erhöhen kann. Achten Sie bei der Entwicklung Ihrer App darauf, wissen, woher der Schreib-Traffic stammt.
Interaktionen zwischen Schreib- und Lesevorgängen
Sie können sich das Echtzeit-Abfragesystem als eine Pipeline vorstellen, die eine Verbindung mit Lesern kommunizieren. Jedes Mal, wenn ein Dokument erstellt, aktualisiert oder gelöscht wird, wird die Änderung vom Speichersystem auf das aktuell registrierte System übertragen zu hören. Die Struktur des Änderungsprotokolls von Firestore garantiert starke Konsistenz, was bedeutet, dass Ihre App nie Benachrichtigungen Aktualisierungen, die nicht in der richtigen Reihenfolge im Vergleich zum Zeitpunkt des Commits für die Daten in der Datenbank sind Änderungen. Dies vereinfacht die App-Entwicklung, indem Grenzfälle in Bezug auf Datenkonsistenz.
Diese verbundene Pipeline bedeutet, dass ein Schreibvorgang oder Sperrenkonflikte, kann sich negativ auf Lesevorgänge auswirken. Wenn Schreibvorgänge fehlschlagen oder eine Drosselung auftritt, kann ein Lesevorgang auf konsistente Daten aus dem Änderungsprotokoll wartet. Wenn das der Fall ist, Ihrer Anwendung können Sie sowohl langsame Schreibvorgänge als auch korrelierte langsame Reaktionen sehen. Mal für die Abfragen. Die Vermeidung von Hotspots ist der Schlüssel, um aus diesem Problem.
Dokumente und Schreibvorgänge klein halten
Wenn Sie Apps mit Snapshot-Listenern entwickeln, möchten Sie in der Regel, dass Nutzer schnell über Datenänderungen informiert werden. Versuchen Sie, die Größe möglichst klein zu halten. Die kann das System kleine Dokumente mit einer großen Anzahl von Feldern schnell ändern. Größere Dokumente mit Hunderten von Feldern und großen Datenmengen dauern länger.
Gleichermaßen sollten Sie kurze, schnelle Commit- und Schreibvorgänge bevorzugen, um die Latenz niedrig zu halten. Große Batches können aus Sicht des Autors zu einem höheren Durchsatz führen aber die Benachrichtigungszeit für Snapshot-Listener verlängern. Dies ist im Vergleich zur Verwendung anderer Datenbanksysteme, können Sie die Leistung mit Batching verbessern.
Effiziente Zuhörer verwenden
Wenn die Schreibraten für Ihre Datenbank steigen, Firestore teilt die Datenverarbeitung auf viele Server auf. Der Fragmentierungsalgorithmus von Firestore versucht, Daten aus der Sammlung oder Sammlungsgruppe auf demselben Änderungsprotokollserver. Das System versucht, den möglichen Schreibdurchsatz zu maximieren und gleichzeitig die Anzahl der Server, die an der Verarbeitung einer Abfrage beteiligt sind, so gering wie möglich zu halten.
Bestimmte Muster können jedoch zu einem suboptimalen Verhalten für Snapshots führen. zu hören. Wenn Ihre App die meisten Daten z. B. auf einem muss der Listener möglicherweise eine Verbindung zu vielen Servern herstellen, um alle Daten, die es benötigt. Dies gilt auch dann, wenn Sie einen Abfragefilter anwenden. Verbinden... erhöht das Risiko langsamerer Antworten.
Um diese langsameren Antworten zu vermeiden, entwerfen Sie Ihr Schema und Ihre Anwendung so, dass das System die Hörer bedienen können, ohne viele verschiedene Server nutzen zu müssen. Es könnte funktionieren Ihre Daten am besten in kleinere Sammlungen mit geringeren Schreibraten aufzuteilen.
Das ist vergleichbar mit Leistungsabfragen, in einer relationalen Datenbank, die vollständige Tabellenscans erfordern. In einer relationalen entspricht eine Abfrage, die einen vollständigen Tabellenscan erfordert, Snapshot-Listener, der sich eine Sammlung mit hoher Abwanderung ansieht. Die Leistung ist möglicherweise langsam. im Vergleich zu einer Abfrage, die die Datenbank mit einem spezifischeren Index verarbeiten kann. Eine Abfrage mit einem spezifischeren Index ist wie ein Snapshot-Listener, der ein einzelnes Dokument oder eine Sammlung beobachtet, die sich seltener ändert. Sie sollten Ihre App testen, um das Verhalten und die Anforderungen Ihres Anwendungsfalls bestmöglich zu verstehen.
Schnelle Abfrage von Abfragen
Ein weiterer wichtiger Bestandteil von responsiven Echtzeitabfragen ist es, sicherzustellen, zum Bootstrapping der Daten schnell und effizient ist. Wenn ein neuer Snapshot-Listener zum ersten Mal eine Verbindung herstellt, muss der Listener den Parameter und an das Gerät des Nutzers senden. Langsame Anfragen weniger reaktionsschnell ist. Dazu gehören z. B. Suchanfragen, viele Dokumente oder Abfragen zu lesen, die nicht die entsprechenden Indexe verwenden.
Ein Listener kann auch von einem Überwachungsstatus in einen Abfragestatus unter unter bestimmten Umständen. Das geschieht automatisch und ist für alle SDKs und deine App Die folgenden Bedingungen können einen Abfragestatus auslösen:
- Das System gleicht aufgrund von Laständerungen ein Änderungsprotokoll neu aus.
- Hotspots verursachen fehlgeschlagene oder verzögerte Schreibvorgänge in die Datenbank.
- Vorübergehende Serverneustarts wirken sich vorübergehend auf Listener aus.
Wenn Ihre Abfrageabfragen schnell genug sind, wird ein Abfragestatus transparent. für die Nutzer Ihrer App.
Langlebige Zuhörer bevorzugen
Das Öffnen und so lange wie möglich Aufrechterhalten von Streams ist oft die kostengünstigste Methode, eine App zu erstellen, die Firestore verwendet. Bei Verwendung Firestore werden Ihnen die an Ihre Anwendung zurückgegebenen Dokumente in Rechnung gestellt. und nicht zur Aufrechterhaltung einer offenen Verbindung. Ein langlebiger Snapshot-Listener liest die für die Abfrage während der gesamten Lebensdauer benötigt werden. Dieses enthält einen anfänglichen Abfragevorgang, gefolgt von Benachrichtigungen, wenn die Daten tatsächlich ändert. Mit One-Shot-Abfragen werden Daten, die möglicherweise seit der letzten Ausführung der Abfrage durch die Anwendung nicht geändert wurden.
Wenn Ihre App eine hohe Datenrate verbrauchen muss, erstellen Snapshot-Listener nicht angemessen sein. Wenn bei Ihrem Anwendungsfall beispielsweise über einen längeren Zeitraum viele Dokumente pro Sekunde über eine Verbindung gesendet werden, sollten Sie besser einmalige Abfragen mit einer geringeren Häufigkeit verwenden.