Übersicht über Abfrageschnittstellen

Auf dieser Seite werden die verschiedenen Schnittstellen erläutert, die für den Zugriff auf Daten in einer Firestore-Datenbank im nativen Modus verfügbar sind.

Vorgangsschnittstellen

Der native Modus unterstützt zwei Schnittstellen für den Zugriff auf Daten:

Pipeline-Vorgänge

Die neuere Abfrageschnittstelle für Firestore. Pipeline-Vorgänge unterstützen eine stufenbasierte, zusammensetzbare Syntax. Sie erstellen einen Vorgang, indem Sie eine Reihe sequenzieller Stufen definieren, die in der Reihenfolge ausgeführt werden. Dadurch sind komplexe Vorgänge möglich, z. B. das Filtern nach dem Ergebnis einer Aggregation, was in der ursprünglichen Schnittstelle (Kernvorgänge) nicht möglich war.

Pipeline-Vorgänge sind nur in der Firestore Enterprise Edition verfügbar und befinden sich in der Preview Phase.

Kernvorgänge

Kernvorgänge sind die ursprüngliche Schnittstelle für Firestore. Bei Kernvorgängen wird eine Methode-Verkettungssyntax (.where(), .orderBy(), .get()) für Dokument- oder Sammlungsreferenzen verwendet, um Dokumente abzurufen. Die Reihenfolge der Abfragestufen ist impliziert und die Aggregationsunterstützung ist begrenzt.

Kernvorgänge sind sowohl in der Enterprise als auch in der Standard Edition verfügbar, aber die Standardeinstellungen für Indexe unterscheiden sich zwischen den Editionen erheblich. Weitere Informationen finden Sie im nächsten Abschnitt.

Unterschiede zwischen den Schnittstellen der Editionen

Mit der Einführung der Unterstützung für den nativen Modus in der Enterprise Edition sind sowohl Firestore-Kernvorgänge als auch Pipeline-Vorgänge verfügbar. Bei Verwendung von Kernvorgängen in der Enterprise Edition werden durch das neue Indexverhalten und das neue Preismodell viele Einschränkungen der Standard Edition aufgehoben.

Feature Standard Edition Enterprise Edition
Unterstützte Vorgänge Beschränkt auf Firestore-Kernvorgänge. Unterstützt Firestore-Kernvorgänge und Pipeline-Vorgänge sowie Firestore-Vorgänge zur MongoDB-Kompatibilität.
Anforderung an die Indexierung Für alle Abfragen sind Indexe erforderlich. Für Abfragen sind keine Indexe erforderlich.
Indexerstellung Für einzelne Felder werden automatische Indexe erstellt. Sie können zusammengesetzte Indexe manuell erstellen. Es werden keine automatischen Indexe erstellt. Indexe müssen manuell verwaltet werden.
Indexierte Felder Den indexierten Feldern wird automatisch ein zusätzliches Feld __name__ angehängt, falls es noch nicht vorhanden ist. __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 Sortierklausel der Abfrage wird normalisiert, indem Ungleichheitsfelder und das __name__ Feld am Ende angehängt werden (falls noch nicht vorhanden). Dadurch wird eine eindeutige, deterministische Reihenfolge der Ergebnisse garantiert, unabhängig davon, welche anderen Felder in der Sortierklausel enthalten sind. Keine Normalisierung der Sortierreihenfolge. Eine Sortierreihenfolge wie sort a ASC garantiert nur, dass die Ergebnisse nach Feld a sortiert werden. 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 Reihenfolge der Ergebnisse zu garantieren, müssen Sie der Sortierreihenfolge ein eindeutiges Feld wie __name__ hinzufügen.
Abfrageleistung und -kosten Abfragen sind aufgrund der Indexanforderungen in der Regel leistungsstark. Sie können die Abfrageleistung und -kosten optimieren, indem Sie Indexe erstellen. Mit Query Explain und Query Insights können Sie fehlende Indexe ermitteln.

Abfragen ohne Indexe können mit zunehmender Größe des Datasets leistungsschwach und kostspielig sein. Daher sind Überwachung und Optimierung erforderlich.
Zusätzliche Kosten für die Indexierung Für Indexschreibvorgänge fallen keine Kosten an, da Indexe automatisch erstellt werden. Beim Schreiben eines zugehörigen Dokuments werden Schreibeinheiten verbraucht (1 Schreibeinheit pro 1 KiB Indexeintrag). Sie sparen Speicherkosten, da nicht für jedes Feld Indexeinträge erstellt werden.
Abrechnungsmodell (Lesen/Schreiben/Löschen) Die Abrechnung erfolgt pro gelesenem, geschriebenem und gelöschtem Dokument. Die Abrechnung erfolgt pro Lese- und Schreibvorgang (Tranche). Lesevorgänge werden in Leseeinheiten (4 KiB-Tranchen) abgerechnet. Schreib- und Löschvorgänge werden zu Schreibeinheiten (1 KiB-Tranchen) zusammengefasst.
Grundpreis (pro Million)

Die Preise gelten für die Region us-central1.

 		Lesevorgänge: 0,03$pro 100.000 Dokumente (oder 0,30 $pro Million).

Schreibvorgänge: 0,09$pro 100.000 Dokumente (oder 0,90 $pro Million).

Löschvorgänge: 0,01$pro 100.000 Dokumente (oder 0,10 $pro Million)

Leseeinheiten: 0,05$pro 1 Million Leseeinheiten.

Schreibeinheiten: 0,26$pro 1 Million Schreibeinheiten. Die Preise sind in der Regel niedriger, wenn Dokumente weniger als 4 KiB groß sind , als die Standardkosten für Lesevorgänge.
Echtzeitaktualisierungen

Die Preise gelten für die Region us-central1.

 Echtzeitaktualisierungen werden als Lesevorgänge mit 0,03 $pro 100.000 Dokumente in Rechnung gestellt. Für Echtzeitaktualisierungen gibt es eine neue separate SKU (Einheiten für Echtzeitaktualisierungen), die pro 4 KiB-Tranche berechnet wird. Echtzeitaktualisierungen kosten 0,30$pro Million Leseeinheiten.

Nächste Schritte