Skalierbare Anwendungen mit Firestore erstellen

In diesem Dokument wird beschrieben, wann Sie Firestore zum Erstellen großer Anwendungen verwenden sollten. Es enthält Lösungen für Infrastrukturadministratoren, die Datenbanksysteme für große Anwendungen verwalten. Die Verwendung von Firestore mit anderen Produkten in Google Cloud vereinfacht die Bereitstellung und Verwaltung einer Datenbank, sodass Sie sich auf die Entwicklung Ihrer Anwendung anstatt auf die Kapazitätsplanung konzentrieren können.

Firestore-Funktionen und -Beschränkungen

Firestore wurde für mobile und Webanwendungen entwickelt und eignet sich am besten zum Speichern hierarchischer Transaktionsdaten mit einem flexiblen, nicht relationalen Schema. Achten Sie beim Bewerten von Firestore als potenzielle Datenbanklösung darauf, dass die Kontingente und Limits hinsichtlich Ihrer Anwendungsfälle angemessen sind. Obwohl Firestore in vielen Fällen eine vielseitige und anwendbare Option darstellt, können andere Google Cloud-Datenbankprodukte für bestimmte Szenarien besser geeignet sein. Bei der Entscheidung, ob Sie eine Firestore oder eine andere Lösung verwenden, sollten Sie die folgenden Faktoren berücksichtigen.

Storage

Firestore kann eine beliebige Menge von Datenspeicher hosten. Es werden Datenmengen von Kilobyte bis Petabyte auf dieselbe Weise verarbeitet, ohne die Leistung zu beeinträchtigen.

Echtzeitaktualisierungen

Firebase bietet Aktualisierungen in Echtzeit. Dafür haben Kunden die Möglichkeit, Dokumente zu beobachten und mit Abfragen Aktualisierungen in Echtzeit abzurufen. Sie stellen ein Callback bereit, durch den sofort ein Dokument-Snapshot mit dem aktuellen Inhalt eines einzelnen Dokuments erstellt wird. Immer wenn sich der Inhalt ändert, aktualisiert ein weiterer Aufruf den Dokument-Snapshot.

Offline-Datenpersistenz

Firestore bietet Offline-Datenpersistenz mit vollständiger Offlinesupport für Webclient- und Mobilversionen. Sie können offline auf Ihre Daten zugreifen und diese aktualisieren. Anschließend werden Änderungen automatisch mit der Cloud synchronisiert, wenn Sie wieder online sind. Der integrierte Offlinesupport nutzt den lokalen Cache zum Bereitstellen und Speichern von Daten. Ihre Anwendung ist also unabhängig von der Netzwerklatenz oder der Internetverbindung und bleibt reaktionsfähig.

Transaktionen

Firestore unterstützt ACID-kompatible Transaktionen mit mehreren Dokumenten. ACID steht für "Atomicity", "Consistency", "Isolation" und "Durability".

Abfragen

Firestore bietet strikt konsistente Abfragen für die gesamte Datenbank. Neben den primären Indexen unterstützt Firestore auch sekundäre und zusammengesetzte Indexe, um schnell die Speicherorte von Elementen festzustellen, die Sie in einer Abfrage anfordern.

Firestore-Abfragen sind so eingeschränkt:

  • Firestore ist eine nicht relationale Datenbank. Es werden daher keine relationalen Schemas oder Abfragen unterstützt, die SQL-Semantik verwenden. Insbesondere unterstützt Firestore keine Join-Vorgänge, Ungleichheitsfilter für mehrere Attribute oder Datenfiltervorgänge auf Basis der Ergebnisse einer Unterabfrage.
    • Wenn Ihre Anwendung SQL-Unterstützung für nicht horizontale Skalierungen benötigt, verwenden Sie Cloud SQL.
    • Wenn Ihre Anwendung SQL-Unterstützung für größere horizontale und globale Skalierungen benötigt, verwenden Sie Cloud Spanner.
  • Firestore ist für die Online-Transaktionsverarbeitung (Online Transaction Processing, OLTP) optimiert.

Sicherheit

Firestore verschlüsselt alle Daten automatisch, bevor sie auf das Laufwerk geschrieben werden. Firestore bietet folgende Methoden einer zuverlässigen Zugriffsverwaltung und Authentifizierung, je nachdem, welche Clientbibliotheken Sie verwenden.

Autoscaling

Firestore skaliert automatisch und ohne Ausfallzeiten. Mit diesem Mechanismus kann Firestore Tausende von Anfragen pro Sekunde und Millionen gleichzeitiger Verbindungen verarbeiten. Sie zahlen nur für Ihre tatsächliche Nutzung. Dabei werden die Speichergröße und die Anzahl von Vorgängen zugrunde gelegt. Weitere Informationen finden Sie unter Firestore-Preise.

Firestore-Autoscaling ist so eingeschränkt:

  • Der native Modus von Firestore kann Aktualisierungsvorgänge für Dokumente auf maximal 10.000 Schreibvorgänge pro Sekunde und über eine Million Verbindungen skalieren. Wenn Ihre Anwendung diese Beschränkung überschreitet, empfehlen wir die Verwendung des Datastore-Modus, mit dem Millionen von Schreibvorgängen pro Sekunde skaliert werden können. Weitere Informationen zu den Unterschieden zwischen diesen Modi finden Sie unter Zwischen nativem Modus und Datastore-Modus wechseln.
  • Firestore kann Vorgänge in äußerst großem Maßstab ausführen. Zur Unterstützung komplexer Funktionen wie Replikation und Transaktionen sind jedoch unter Umständen Kompromisse erforderlich. Die Leistung von Anwendungen, die extreme Lasten verarbeiten, kann hierdurch beeinträchtigt werden.
    • Wenn Ihre Anwendung extrem aufwendige Schreibvorgänge generiert, eignet sich die Verwendung von Cloud Bigtable. Sie erhalten dadurch leistungsfähigere Datenaufnahmefunktionen auf Kosten von Transaktionen und sekundären Indexen.
    • Wenn Ihre Anwendung für Nutzer häufig dieselben Informationen anzeigt, z. B. eine Bestenliste für Spiele, empfiehlt sich das clientseitige Caching. Sie erzielen hierdurch eine Lastenreduzierung, da unnötige Anfragen an den Server vermieden werden.

Latenz

Firestore priorisiert Langlebigkeit und Verfügbarkeit gegenüber Latenz mithilfe von regionsübergreifenden oder zonenübergreifenden synchronen Schreibvorgängen. Wenn Ihre Anwendung beim Lesen oder Schreiben von Daten eine Latenz von weniger als zehn Millisekunden erfordert, sollten Sie eine speicherinterne Datenbank wie Memorystore for Redis verwenden.

Redundanz und Verfügbarkeit

Firestore bietet die folgenden Redundanzstufen für mehrere Standorte auf der Grundlage verschiedener Replikationsmechanismen:

  • Die regionale Replikation ist am besten geeignet, wenn Sie eine niedrige Schreiblatenz erreichen möchten. Wenn Sie die regionale Replikation verwenden, werden Daten innerhalb derselben Region repliziert. Damit die niedrigste Latenz gewährleistet wird, sollten Sie Ihre Anwendung in derselben Region platzieren.
  • Die multiregionale Replikation ist am besten geeignet, wenn Sie eine hohe Verfügbarkeit gewährleisten möchten. Wenn Sie die multiregionale Replikation verwenden, werden Daten in verschiedenen Zonen innerhalb von mindestens zwei Regionen repliziert. Dadurch ist die Datenbank auch bei regionalen Ausfällen stabil. Die multiregionale Replikation bietet höhere Verfügbarkeit und Redundanz, hat jedoch eine höhere Schreiblatenz. Ein Witness-Knoten wird in einer dritten Region bereitgestellt, um als Ausgleich zwischen den beiden replizierten Regionen zu dienen, wie in Abbildung 1 veranschaulicht wird.

Replikationsschema für eine multiregionale Datenbank.

Abbildung 1. Diagramm einer multiregionalen Datenbank in Firestore.

Clientbibliotheken

Webclient- und Mobilversionen können mithilfe der Clientbibliotheken für Android, iOS oder Web direkt auf Firestore zugreifen. Firestore lässt sich außerdem nahtlos in die Firebase-Plattform einbinden, die Funktionen wie Crash Reporting, Nutzerauthentifizierung, E-Mail-Zustellung und Nutzerereignisanalysen.

Wann sollte Firestore verwendet werden?

Mit seinen Funktionen eignet sich Firestore für eine Vielzahl von Anwendungsfällen, darunter:

  • Nutzerprofile: Sie verwalten Nutzerprofile, um ein individuell angepasstes Anwendungsverhalten auf der Grundlage bisheriger Aktivitäten und Einstellungen zu ermöglichen. Mit dem flexiblen Schema von Firestore lässt sich die Struktur von Nutzerprofilen weiterentwickeln. Sie haben etwa die Möglichkeit, neue Attribute hinzuzufügen, um neue Funktionen in Ihrer Anwendung zu unterstützen. Schemaänderungen erfolgen ohne Ausfallzeit und die Leistung wird auch bei steigender Nutzerzahl nicht beeinträchtigt.
  • Inventare in Echtzeit: Mit den umfangreichen, verschachtelten Objekten von Firestore können Sie große Mengen nicht homogener Sparse-Daten für diverse Produkte speichern, ohne die Struktur zu sehr zu spezialisieren. Sie haben beispielsweise die Möglichkeit, einen Produktkatalog für einen Händler erstellen.
  • Verwaltung von Nutzersitzungen: Mit der Firestore-Unterstützung für ACID-Transaktionen können Nutzer eines oder mehrere Dokumente sperren, bis die Transaktion abgeschlossen ist. Sie haben beispielsweise die Möglichkeit, Einkaufswagen für Handelstransaktionen oder ein mehrteiliges Verarbeitungsformular für die Buchung von Ereignissen zu erstellen.
  • Statusänderungen: Mit den ACID-Transaktionen von Firestore können Sie Mutationen über eine große Anzahl gleichzeitiger Nutzer verbreiten. Sie haben beispielsweise die Möglichkeit, einen konsistenten Status für alle Spieler in einer Gaming-App zu erstellen.
  • Nichtflüchtiger Write-through-Cache: Die hohe Verfügbarkeit und Langlebigkeit von Firestore bietet einen persistenten Status und verhindert potenzielle Datenverluste durch den Absturz von Apps. Firestore bietet Funktionen wie einen einfachen Schlüssel/Wert-Speicher. Firestore verfügt jedoch nicht über einen integrierten Mechanismus für die Gültigkeitsdauer (TTL) oder den Cache-Ablauf.
  • Geräteübergreifende Datensynchronisierung: Die Aktualisierungen in Echtzeit von Firestore sorgen dafür, dass auf allen verbundenen Geräten immer der aktuelle Status angezeigt wird. Firestore bietet beispielsweise einen konsistenten Status für Apps, die von mehreren Nutzern verwendet und bei denen von mehreren Geräten aus Verbindungen hergestellt werden.
  • IoT-Verwaltung und Asset-Tracking: Mit der Offline-Datenpersistenz von Firestore können Sie Datenpunkte auch dann aufzeichnen, wenn Geräte die Netzwerkverbindung verlieren. So lässt sich etwa das GPS-Tracking in Echtzeit für Mobilgeräte und Fahrzeuge einrichten.
  • Echtzeitfunktionen: Mit den Echtzeitaktualisierungen von Firestore können Sie Echtzeitanalysen und -Messaging einrichten. Sie haben die Möglichkeit, Grafiken und Diagramme wie interaktive visuelle Dashboards auf dem neuesten Stand zu halten und Live-Diskussionsforen und Chatrooms einzurichten.
  • Verteilte Zähler: Sie können verteilte Zähler einrichten, um Dokumentinteraktionen wie die Anzahl von "Gefällt mir"-Bewertungen für einen Beitrag oder Favoriten eines bestimmten Elements anzusehen.

Referenzarchitekturen

Dieser Bereich enthält Referenzarchitekturen für die Erstellung großer Webanwendungen, die Firestore mit anderen Google Cloud-Produkten kombinieren. Dazu gehören:

  • Tägliche Exporte
  • Caching
  • Datenverarbeitung
  • Trainingsmodelle für maschinelles Lernen

Diese Architekturen sind nicht präskriptiv. Stattdessen werden die vielfältigen Einsatzmöglichkeiten von Firestore bei der Erstellung skalierbarer Webanwendungen hervorgehoben. Sie können die Architekturen neu organisieren und anpassen, um eine eigene Webanwendung zu erstellen, die Ihren Anforderungen entspricht.

Gaming

Eine Gamingplattform unterstützt den gleichzeitigen Zugriff von Zehntausenden von Spielern. Die Front-End-Dienste des Spiels verwenden Firestore, um Milliarden von Dokumenten mit hierarchischen Weltstatusdaten zu speichern. Firestore enthält außerdem Daten wie Nutzerkonfigurationen, Gruppenmitgliedschaften, Gilden, Freundeslisten und Präsenzdaten. Dieser Anwendungsfall bindet andere Google Cloud-Produkte ein:

  • Spanner bietet eine global konsistente Datenbank, in der Inventar oder Spielverläufe für riesige Spielergruppen auf der ganzen Welt gespeichert werden können.
  • In Memorystore for Redis wird ein regionaler speicherinterner Cache bereitgestellt, um den Zugriff auf häufig verwendete Daten zu beschleunigen.
  • Ereignisse werden in Cloud Bigtable protokolliert. Hier können Entwickler oder Supportmitarbeiter darauf zugreifen, um Fehler zu beheben.
  • Daten aus Front-End- und Back-End-Datenbanken werden regelmäßig in BigQuery importiert, um Datenanalyse-Pipelines auszuführen. Damit lassen sich Exploits oder Gameplay-Mechanismen aufdecken, die aktualisiert werden müssen, bevor sie die Community des Spiels beeinträchtigen und sich Spieler abwenden.

Abbildung 2 zeigt die Architektur des Gaming-Anwendungsfalls:

Architektur des Gaming-Anwendungsfalls.

Abbildung 2. Beispiel der Architektur für eine Gamingplattform.

Internet der Dinge

Eine interaktive Webanwendung präsentiert Telemetriedaten in Echtzeit, die von IoT-Geräten generiert wurden. Die Geräte messen und erfassen regelmäßig Temperatur und Herzfrequenz des Nutzers und verarbeiten die Daten dann so:

  1. Jede Messung wird über MQTT- und HTTP-Brücken sofort an IoT Core gesendet.
  2. IoT Core veröffentlicht Messungen als einzelne Nachricht in Pub/Sub.
  3. Die Pub/Sub-Nachricht löst Cloud Functions-Funktionen aus, die relevante Informationen aus den Rohnachrichten extrahieren und die Ergebnisse zur langfristigen Speicherung in Firestore speichern.
  4. Eine interaktive Web-Benutzeroberfläche, die von Firebase Hosting gehostet und von Angular unterstützt wird, wartet direkt in Firestore auf Updates. Jedes Update wird automatisch an die Web-Benutzeroberfläche übertragen, um die neuesten Informationen in Echtzeit zu visualisieren.

Abbildung 3 zeigt die Datenpipeline für Telemetriedaten in diesem Szenario:

Architektur des IoT-App-Anwendungsfalls.

Abbildung 3. Beispiel für eine IoT-App-Architektur.

Einzelhandel

Eine Handelsplattform bietet Produktempfehlungen für Neukunden über verschiedene Medien. Eine Webanwendung zeichnet Live-Datenpunkte über Onlinenutzer wie Verweis-URL, geografische Region und Gerätetyp auf und schreibt die erhobenen Daten in Firestore so:

  1. Jede neue Datensatzerstellung löst eine Datenpipeline in Cloud Functions aus, mit der die Nutzerdaten in BigQuery kopiert werden.
  2. Ein Empfehlungssystem, das mit Spark MLlib implementiert und in Dataproc bereitgestellt wird, wird mit den in BigQuery gespeicherten Live-Nutzerdaten und den in Cloud SQL gespeicherten Produktmetadaten trainiert.
  3. Es gibt die folgenden Vorhersagen für empfohlene Produkte aus:
    • Echtzeitvorhersagen, die in Firestore geschrieben und automatisch auf die Geräte der Onlinenutzer übertragen werden.
    • Batchvorhersagen, die von einem E-Mail-Dienst an Offline-Nutzer gesendet werden.

Abbildung 4 zeigt den Datenfluss für das Szenario der Handelsplattform:

Architektur des Anwendungsfalls der Handelsplattform.

Abbildung 4. Beispiel für die Architektur einer Handelsplattform.

Datenänderungen in Echtzeit erfassen

Eine Anwendung erhält Nutzereingaben in Echtzeit, die den globalen Status ändern. Auf einem Dashboard in Data Studio werden Echtzeitereignisse verfolgt, um das Nutzerverhalten und die Interaktionen besser zu verstehen. Wenn ein Statuswert durch eine Nutzeraktion aktualisiert wird, treten die folgenden Ereignisse auf:

  1. Firestore löst eine Cloud Functions-Funktion aus, die die Änderung einschließlich der alten und neuen Statuswerte in BigQuery schreibt.
  2. Das Data Studio-Dashboard führt in BigQuery Aggregationsabfragen in Echtzeit für die Ereignisdaten aus.
  3. Durch die Abfragen werden Messwerte wie "Verhältnis von Ereignisänderungen, die für verschiedene Buckets zusammengefasst wurden", "Einmalige Ereignistypen pro Zeit-Bucket" und "Aufnahmelatenz für Ereignisse".

Eine ausführliche Präsentation und Demo dieser Architektur finden Sie im "Cloud Next '19"-Video Building amazing apps With Firestore.

Abbildung 5 zeigt die Architektur für die Erfassung von Echtzeitdatenänderungen:

Architektur des Anwendungsfalls zur Datenerhebung.

Abbildung 5. Beispiel für eine einfache Architektur zur Datenerhebung.

Gemeinsame Bearbeitung von Inhalten

Mit einem Content-Management-System (CMS) zur gemeinsamen Bearbeitung können mehrere Bearbeiter gleichzeitig am selben Artikel arbeiten. Jedes Mal, wenn ein Bearbeiter eine Änderung vornimmt, etwa um ein Zeichen hinzuzufügen oder zu löschen, sendet der Client des Bearbeiters die Änderung direkt an Firestore.

Wenn mehrere Bearbeiter gleichzeitig Änderungen einreichen, wird der folgende Lösungsprozess eingeleitet:

  1. Durch die Firestore-Transaktionen wird gewährleistet, dass nur die erste empfangene Änderung in die Datenbank geschrieben wird. Sonstige Änderungen werden abgelehnt.
  2. Firestore sendet die aktualisierten Inhalte automatisch an alle Bearbeiter.
  3. Die Bearbeiter, die anfangs abgelehnt wurden, wenden ihre eigenen Änderungen zusätzlich zu den aktualisierten Inhalten noch einmal an und senden die Änderungen dann noch einmal an Firestore.
  4. Derselbe Konfliktlösungsprozess wird wiederholt, bis alle Änderungen von allen Clients akzeptiert und in die Datenbank geschrieben wurden.

Mit einer Staging-Pipeline können Bearbeiter den Inhalt so ansehen:

  1. Ein in Cloud Scheduler gehosteter Cronjob löst jede Sekunde eine Cloud Functions-Funktion aus.
  2. Durch die Funktion werden die neuesten Inhalte aus Firestore in die in Cloud SQL gehostete Staging-Datenbank kopiert.
  3. Bearbeiter sehen sich den bereitgestellten Inhalt auf dem in App Engine gehosteten Staging-Server an.

Wenn der Inhalt vollständig ist, klickt ein Bearbeiter im CMS auf die Schaltfläche "Veröffentlichen". Durch diese Aktion wird eine Cloud Functions-Funktion ausgelöst, die die neuesten Inhalte aus Firestore in die auf Cloud SQL gehostete Produktionsdatenbank kopiert. Die Leser können die neu veröffentlichten Inhalte dann auf der Produktionswebsite ansehen. Ein ähnliches Beispiel dieser Architektur finden Sie im Artikel We Build Collaborative Editing for the Newsroom CMS der New York Times.

Abbildung 6 zeigt die Pipeline für die Bearbeitung, Bereitstellung und Veröffentlichung von Inhalten im Anwendungsfall der gemeinsamen Bearbeitung von Inhalten:

Architektur des Anwendungsfalls zur Inhaltsbearbeitung.

Abbildung 6. Beispiel einer Architektur für eine Plattform zur gemeinsamen Bearbeitung von Inhalten.

Weitere Informationen