Firestore im nativen Modus besteht aus zwei Gruppen von Vorgängen: Firestore-Kernvorgänge und Firestore-Pipeline-Vorgänge.
Die Firestore-Kernvorgänge bieten die Standardfunktionen zum Erstellen, Lesen, Aktualisieren und Löschen von Dokumenten (CRUD) sowie integrierte Unterstützung für Echtzeit-Abfragevorgänge und Offline-Persistenz. Ein wesentlicher Unterschied in dieser Version 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 Abfragen ohne Index wird standardmäßig die gesamte Sammlung gescannt. Mit zunehmender Größe des Datasets kann dies zu einer höheren Latenz und höheren Kosten führen.
Die Firestore-Pipeline-Vorgänge sind eine zentrale Funktion der Firestore Enterprise-Version, die auf einer erweiterten Abfrage-Engine basiert und die Bandbreite der möglichen Abfragen erheblich erweitert. Pipeline-Vorgänge verwenden eine flexible Abfragesyntax und eine spezielle Indexierungsmethode, bei der Indexe optional sind und nicht automatisch erstellt werden. Dadurch werden erweiterte Datenabrufvorgänge für Anwendungen ermöglicht.
Funktionen von Firestore-Kernvorgängen
Der Gacklaxiekern ermöglicht Standard-CRUD-Vorgänge und Echtzeit-Abfragevorgänge. Wenn Sie diese Vorgänge in der Enterprise-Version verwenden, ändert sich das zugrunde liegende Verhalten in Bezug auf Indexierung und Abrechnung im Vergleich zur Standard-Version erheblich.
Funktionalität und Kontinuität
Bei den Kernvorgängen bleibt die bekannte Methodenkettensyntax (z. B. .where(), .orderBy()) erhalten, die in der Standard-Version verwendet wird. Diese Vorgänge unterstützen Echtzeit-Abfragevorgänge und Offline-Persistenz für Mobil- und Webclients. Es empfiehlt sich, diese Vorgänge für standardmäßige Transaktionsarbeitslasten, einfache Suchvorgänge und die Migration von vorhandenem Anwendungscode zu verwenden.
Benutzerdefinierte Indexierung
Im Gegensatz zur Standard-Version werden bei den Kernvorgängen in der Enterprise-Version keine Indexe für einzelne Felder automatisch erstellt. Indexe sind optional und für die Ausführung einer Abfrage nicht erforderlich. Wenn ein bestimmter Index fehlt, wird bei der Abfrage ein vollständiger Sammlungs-Scan durchgeführt. Abfragen ohne Index ermöglichen zwar eine schnelle Prototyperstellung, können aber mit zunehmender Größe des Datasets langsamer und teurer werden. Entwickler müssen Indexe manuell erstellen, um die Abfrageleistung zu optimieren und den Verbrauch von Leseeinheiten zu reduzieren.
Abrechnungsmodell (einheitenbasiert)
Leseeinheiten werden in 4-KB-Tranchen und nicht pro Dokument berechnet. Bei einer Abfrage ohne Index, bei der eine große Sammlung gescannt wird, werden Leseeinheiten basierend auf der Gesamtzahl der gescannten Byte in allen Dokumenten verbraucht. Schreibeinheiten werden in 1-KB-Tranchen berechnet. Beim Schreiben eines Dokuments werden Einheiten für die Daten sowie zusätzliche Einheiten für jeden aktualisierten Indexeintrag verbraucht. Im Gegensatz zur Standard-Version, bei der die automatische Indexierung für einzelne Felder erzwungen wird, können Sie jetzt bestimmte Felder für die Indexierung auswählen, um die Schreibkosten und -leistung zu optimieren.
Funktionen von Firestore-Pipeline-Vorgängen
Die Firestore Enterprise-Version mit Pipeline-Vorgängen verwendet eine erweiterte Abfrage-Engine, 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:
Stufenbasierte, zusammensetzbare Syntax
Pipeline-Abfragen werden durch Definieren einer Reihe sequenzieller Stufen erstellt, die in der Reihenfolge ausgeführt werden. Dadurch sind komplexe Vorgänge möglich, z. B. das Filtern nach dem Ergebnis einer Aggregation, was bisher nicht möglich war.
Im folgenden Beispiel wird eine Pipeline-Abfrage 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 Aggregatfunktionen wie
sum(...),min(...)undcount_distinct(...)in Kombination mit beliebigen Gruppierungsfeldern. - Relationale Joins: Serverseitige Joins über Sammlungen und Untersammlungen hinweg mit korrelierten Unterabfragen ausführen.
- Komplexes Filtern: Unterstützung für Hunderte zusätzlicher Funktionen, um beliebig komplexe
where(...)-Anweisungen auszudrücken, einschließlichregex_match(...),add(...)undstr_contains(...), ohne dass strenge Indexanforderungen gelten. - Teilweise Lesevorgänge / Projektionen: Dynamische Teilmengen von Dokumenten mit
select(...),remove_fields(...)und vielen anderen Stufen zur Dokumentbearbeitung abrufen.
Weitere Informationen zu diesen Funktionen finden Sie unter Daten mit Pipeline Vorgängen abfragen.
Echtzeit- und Offlinesupport
Um Echtzeit- und Offlinesupport zu nutzen, können Entwickler die Firestore-Kernvorgänge in der Firestore Enterprise-Version verwenden.
Client- und Toolintegration
Die Enterprise-Version enthält spezielle Funktionen für die Interaktion mit Pipeline-Abfragen und deren Verwaltung:
- 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.
- Abfragestatistiken : Die Enterprise-Version unterstützt Query Insights. Damit können Sie ermitteln, wo Indexe erstellt werden könnten, um Leistung und Kosten zu verbessern. Dazu erhalten Sie Einblick in die wichtigsten Abfragen, die in Ihrer Datenbank ausgeführt werden, und in ihre Leistungsmerkmale.
- Neue Indexarten: Sie können spezielle Indexe für die Enterprise-Version erstellen, einschließlich Indexarten wie Sparse-, Non-Sparse- und Unique-Indexe. Außerdem können Sie Vektorsuchindexe für Enterprise-Datenbanken erstellen und bearbeiten.
Unterschiede zwischen der Firestore Standard-Version und der Firestore Enterprise-Version
Der größte betriebliche Unterschied zwischen den Kernvorgängen und den Pipeline-Vorgängen liegt in der Verwaltung der Indexierung, die sich direkt auf Leistung und Kosten auswirkt.
| Standard-Version – Kernvorgänge | Enterprise-Version – Kernvorgänge und Pipeline-Vorgänge | |
| Indexierungsanforderung | 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 für Abfragen nicht erforderlich und daher optional.
Sie definieren Indexe nach Bedarf. Die Enterprise-Version unterstützt auch eine größere Auswahl an Indexarten, einschließlich Non-Sparse-, Sparse- und Unique-Indexe. |
| Indexierte Felder | Wenn noch nicht vorhanden, wird den indexierten Feldern automatisch ein zusätzliches Feld __name__ angehängt. | __name__ wird den indexierten Feldern nicht automatisch 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 am Ende Ungleichheitsfelder und das Feld __name__ angehängt werden (falls noch nicht vorhanden). Dadurch wird unabhängig von anderen Feldern in der „order by“-Klausel eine eindeutige, deterministische Reihenfolge der Ergebnisse garantiert. | 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 im Ergebnissatz nicht eindeutig ist, kann die Reihenfolge der Ergebnisse je nach Abfrage variieren, abhängig von der Indexkonfiguration, den Ausführungsstrategien usw. Um eine eindeutige, deterministische Reihenfolge der Ergebnisse zu garantieren, 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. |
Abfragen ohne Index:Leistung und Kosten skalieren mit der Größe des Datasets. Indexierte Abfragen:Leistung und Kosten skalieren mit der Größe des 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 | Es fallen Speicherkosten für automatische und zusammengesetzte Indexe an. | Sie sparen Speicherkosten, da Indexe nicht automatisch für jedes Feld erstellt werden. |
| Kostengrundlage | Die Kosten werden pro Lese-, Schreib- und Löschvorgang für ein Dokument berechnet. | Die Kosten werden pro Leseeinheit (4-KB-Tranchen) und Schreibeinheit (1-KB-Tranchen) berechnet. Beim Schreiben von Indexeinträgen werden Schreibeinheiten verbraucht.
Informationen zu den neuen Preisen mit einigen Beispielen. |
| Sicherheitsregeln | Sicherheitsregeln schützen Sammlungen, indem sie Lese-/Schreibberechtigungen überprüfen. | Sicherheitsregeln schützen Sammlungen, indem sie Lese-/Schreibberechtigungen überprüfen. Informationen zum Modellieren von Daten zur Unterstützung von Pipeline Abfragen finden Sie im Leitfaden zum Datenmodell. |