Übersicht über Firestore im nativen Modus

Firestore im nativen Modus besteht aus zwei Gruppen von Vorgängen: Firestore Core-Vorgänge und Firestore Pipeline-Vorgänge.

Die Firestore Core-Vorgänge bieten die Standardfunktionen zum Erstellen, Lesen, Aktualisieren und Löschen (CRUD) von Dokumenten sowie integrierte Unterstützung für Echtzeit-Listen-Abfragen und Offline-Persistenz. Ein wesentlicher Unterschied zu anderen Editionen besteht darin, dass Indexe optional sind und nicht automatisch für einzelne Felder erstellt werden. Dadurch können Abfragen ohne vorherige Indexkonfiguration ausgeführt werden. Bei nicht indexierten Abfragen wird jedoch standardmäßig die gesamte Sammlung gescannt. Dies kann zu erhöhter Latenz und höheren Kosten führen, wenn der Datensatz wächst.

Firestore-Pipeline-Operationen sind eine zentrale Funktion der Firestore Enterprise-Version, die auf einer erweiterten Abfrage-Engine basiert und die Bandbreite möglicher Abfragen erheblich erweitert. Für Pipelinevorgänge wird eine flexible Abfragesyntax und eine spezielle Indexierungsmethode verwendet, bei der Indizes optional sind und nicht automatisch erstellt werden. So können Anwendungen erweiterte Datenabrufvorgänge ausführen.

Funktionen von Firestore-Kernvorgängen

Die Gacklaxiekern-Vorgänge ermöglichen standardmäßige CRUD-Vorgänge und Echtzeit-Listenabfragen. Wenn Sie diese Vorgänge jedoch in der Enterprise-Version verwenden, ändert sich das zugrunde liegende Verhalten in Bezug auf die Indexierung und Abrechnung im Vergleich zur Standard-Version erheblich.

Funktionalität und Kontinuität

Bei den Kernvorgängen wird die aus der Standardversion bekannte Methodenkettungssyntax beibehalten (z. B. .where(), .orderBy()). Diese Vorgänge unterstützen Echtzeit-Abfragefunktionen und Offline-Persistenz für Mobil- und Webclients. Es wird empfohlen, diese Vorgänge für standardmäßige transaktionale Arbeitslasten, einfache Suchvorgänge und die Migration von vorhandenem Anwendungscode zu verwenden.

Benutzerdefinierte Indexierung

Im Gegensatz zur Standard-Edition werden in der Enterprise-Edition bei Core-Vorgängen keine Einzelfeldindexe automatisch erstellt. Indexe sind optional und nicht erforderlich, um eine Abfrage auszuführen. Wenn ein bestimmter Index fehlt, wird bei der Abfrage ein vollständiger Sammlungs-Scan durchgeführt. Nicht indexierte Abfragen ermöglichen zwar ein schnelles Prototyping, können aber langsamer ausgeführt werden und mehr kosten, wenn das Dataset wächst. Entwickler müssen Indexe manuell erstellen, um die Abfrageleistung zu optimieren und den Verbrauch von Lese-Einheiten zu reduzieren.

Abrechnungsmodell (einheitenbasiert)

Leseeinheiten werden in 4-KB-Tranchen und nicht pro Dokumentanzahl berechnet. Bei einer nicht indexierten Abfrage, die eine große Sammlung durchsucht, werden Leseeinheiten basierend auf der Gesamtzahl der gescannten Byte in allen Dokumenten verbraucht. Schreibeinheiten werden in 1-KB-Tranchen abgerechnet. Wenn Sie ein Dokument schreiben, werden Einheiten für die Daten sowie zusätzliche Einheiten für jeden aktualisierten Indexeintrag verbraucht. Anders als in der Standard-Version, in der die automatische Indexierung einzelner Felder erzwungen wird, können Sie jetzt bestimmte Felder für die Indexierung auswählen, um die Schreibkosten und die Leistung zu optimieren.

Funktionen von Firestore-Pipelinevorgängen

Für die Firestore Enterprise-Version mit Pipeline-Operationen wird eine erweiterte Abfrage-Engine verwendet, mit der viele bestehende Einschränkungen der Firestore Standard-Version aufgehoben werden. Pipeline-Vorgänge bieten Hunderte zusätzlicher Abfragefunktionen. Die Pipeline-Vorgänge haben die folgenden Funktionen:

Composable-Syntax für Phasen

Pipeline-Abfragen werden erstellt, indem eine Reihe von sequenziellen Phasen definiert wird, die in der Reihenfolge ausgeführt werden. Das ermöglicht komplexe Vorgänge wie das Filtern nach dem Ergebnis einer Aggregation, was bisher nicht möglich war.

Im folgenden Beispiel wird eine Pipelineabfrage gezeigt, mit der die Anzahl der eindeutigen Produkt-IDs ermittelt wird, die im letzten Monat aufgerufen wurden:

guard let cutoffDate = Calendar.current.date(byAdding: .month, value: -1, to: Date()) else {
  return
}
let snapshot = try await db.pipeline()
  .collection("productViews")
  .where(Field("viewedAt").greaterThan(cutoffDate.timeIntervalSince1970))
  .aggregate([Field("productId").countDistinct().as("uniqueProductViews")])
  .execute()

Erweiterte Funktionen

Die Pipeline-Abfrage bietet eine Vielzahl neuer Funktionen, darunter:

  • Aggregationen: Unterstützung für neue Aggregationsfunktionen (wie sum(...), min(...) und count_distinct(...)) in Kombination mit beliebigen Gruppierungsfeldern.
  • Relationale Joins: Führen Sie serverseitige Joins für Sammlungen und Untersammlungen mit korrelierten Unterabfragen aus.
  • Komplexes Filtern: Unterstützung von Hunderten zusätzlicher Funktionen, um beliebig komplexe where(...)-Anweisungen auszudrücken, einschließlich regex_match(...), add(...) und str_contains(...), ohne dass ein harter Index erforderlich ist.
  • Teilweises Lesen / Projektionen: Rufen Sie dynamische Teilmengen von Dokumenten mit select(...), remove_fields(...) und vielen anderen Phasen zur Dokumentbearbeitung ab.

Weitere Informationen zu diesen Funktionen finden Sie unter Daten mit Pipelinevorgängen abfragen.

Echtzeit- und Offlinesupport

Um Echtzeit- und Offlinefunktionen zu nutzen, können Entwickler die Firestore Core-Vorgänge in der Firestore Enterprise-Version verwenden.

Client- und Toolintegration

Die Enterprise-Version umfasst spezielle Funktionen für die Interaktion mit und die Verwaltung von Pipeline-Abfragen:

  • Abfrageerklärung und ‑profilerstellung:Mit den Ergebnissen von „Query Explain“ können Sie nachvollziehen, wie viele Lese- oder Schreibeinheiten eine Abfrage verbraucht, und die Ausführung analysieren.
  • Query Insights : Die Enterprise-Version unterstützt Query Insights. Damit können Sie ermitteln, wo Indexe erstellt werden könnten, um die Leistung und die Kosten zu verbessern. Sie erhalten Einblick in die wichtigsten Abfragen, die in Ihrer Datenbank ausgeführt werden, und in deren Leistungsmerkmale.
  • Neue Indextypen : Sie können spezielle Indexe für die Enterprise-Version erstellen, einschließlich Indextypen wie Sparse-, Non-Sparse- und Unique-Indexe. Außerdem können Sie Vektorsuchindizes für Enterprise-Datenbanken erstellen und bearbeiten.

Unterschiede zwischen der Firestore Standard- und der Firestore Enterprise-Version

Der Hauptunterschied zwischen den Core-Vorgängen und den Pipeline-Vorgängen liegt in der Verwaltung der Indexierung, die sich direkt auf Leistung und Kosten auswirkt.

Standardversion – Kernvorgänge Enterprise-Version – Core- und Pipeline-Vorgänge
Anforderung an die Indexierung Für Abfragen sind Indexe erforderlich.

Indexe für einzelne Felder werden automatisch erstellt. Für komplexere Abfragen sind zusammengesetzte Indexe oder Sammlungsgruppenindexe erforderlich, die manuell konfiguriert werden müssen.

 Indexe sind nicht erforderlich und daher für Abfragen optional.

Sie definieren Indexe nach Bedarf. Die Enterprise-Version unterstützt auch eine größere Auswahl an Indextypen, darunter nicht-sparse/sparse und eindeutige Indizes.
Indexierte Felder Den indexierten Feldern wird automatisch ein zusätzliches Feld __name__ angehängt, sofern es noch nicht vorhanden ist. __name__ wird nicht automatisch an die indexierten Felder angehängt. Sie müssen __name__ explizit in den indexierten Feldern angeben, wenn es für Ihre Anwendung wichtig ist.
Normalisierung der Sortierreihenfolge Die ORDER BY-Klausel der Abfrage wird normalisiert, indem Ungleichheitsfelder und das Feld __name__ am Ende angehängt werden (sofern nicht bereits vorhanden). So wird eine eindeutige, deterministische Reihenfolge der Ergebnisse garantiert, unabhängig davon, welche anderen Felder in der ORDER BY-Klausel enthalten sind. Keine Normalisierung der Sortierreihenfolge. Eine Sortierreihenfolge wie sort a ASC garantiert nur, dass die Ergebnisse nach dem Feld a sortiert werden. Cloud Firestore verwendet Ihre vorhandenen Indexe, um Ergebnisse in der effizientesten Reihenfolge zurückzugeben. Wenn a also nicht eindeutig im Ergebnissatz ist, kann die Reihenfolge der Ergebnisse je nach Abfrage variieren. Das hängt von der Indexkonfiguration, den Ausführungsstrategien usw. ab. Um eine eindeutige, deterministische Sortierung der Ergebnisse zu gewährleisten, müssen Sie der Sortierreihenfolge ein eindeutiges Feld wie __name__ hinzufügen.
Leistung Indexierte Abfragen:Leistung und Kosten skalieren mit der Größe des Ergebnissatzes.

Nicht indexierte Abfragen:Leistung und Kosten skalieren mit der Größe Ihres Datasets.

Indexierte Abfragen:Leistung und Kosten skalieren mit der Größe Ihres Ergebnissatzes.

Wir empfehlen, die Tools „Query Explain“ und „Query Insights“ zu verwenden, um Indexe zu erstellen und die Leistung und Kosten Ihrer Abfragen zu verbessern.
Auswirkungen auf die Speicherkosten Durch automatische und zusammengesetzte Indexe entsteht Speicher-Overhead. Sie sparen Speicherkosten, da nicht automatisch für jedes Feld Indexe erstellt werden.
Kostenbasis Die Abrechnung erfolgt pro Lese-, Schreib- und Löschvorgang für Dokumente. Die Abrechnung erfolgt pro Leseeinheit (4-KB-Tranchen) und Schreibeinheit (1-KB-Tranchen). Das Schreiben von Indexeinträgen verbraucht Schreibeinheiten.

Beispiele für die neuen Preise
Sicherheitsregeln Sicherheitsregeln schützen Sammlungen, indem sie Lese-/Schreibberechtigungen prüfen. Sicherheitsregeln schützen Sammlungen, indem sie Lese-/Schreibberechtigungen prüfen. Informationen zum Modellieren von Daten zur Unterstützung von Pipeline-Abfragen finden Sie im Leitfaden Datenmodell.