Auf dieser Seite werden die verschiedenen Schnittstellen beschrieben, die für den Zugriff auf Daten in einer Datenbank im nativen Modus verfügbar sind.
Vorgangsschnittstellen
Der native Modus unterstützt zwei Schnittstellen für den Datenzugriff:
Pipelinevorgänge
Die neuere Abfrageoberfläche für Cloud Firestore. Pipelinevorgänge unterstützen eine stufenbasierte zusammensetzbare Syntax. Sie erstellen einen Vorgang, indem Sie eine Reihe von sequenziellen Phasen definieren, die der Reihe nach ausgeführt werden. Dadurch sind komplexe Vorgänge möglich, z. B. das Filtern nach dem Ergebnis einer Aggregation, was in der ursprünglichen Benutzeroberfläche (Core-Vorgänge) nicht möglich war.
Pipelinevorgänge sind nur in der Firestore Enterprise-Version verfügbar und befinden sich in der Vorschauphase.
Kernvorgänge
Core Operations ist die ursprüngliche Schnittstelle für Cloud Firestore.
Bei Core-Vorgängen wird eine Method-Chaining-Syntax (.where(), .orderBy(), .get()) für Dokument- oder Sammlungsreferenzen verwendet, um Dokumente abzurufen.
Die Reihenfolge der Abfragephasen ist impliziert und die Unterstützung für die Aggregation ist begrenzt.
Kernvorgänge sind sowohl in der Enterprise- als auch in der Standard-Version verfügbar, die Indexstandardeinstellungen sind jedoch sehr unterschiedlich. Weitere Informationen finden Sie im nächsten Abschnitt.
Unterschiede bei der Benutzeroberfläche zwischen den Versionen
Mit der Einführung der Unterstützung des nativen Modus in der Enterprise-Version sind sowohl Firestore Core- als auch Pipeline-Vorgänge verfügbar. Wenn Sie Core-Vorgänge in der Enterprise-Version verwenden, werden durch das neue Indexverhalten und das neue Preismodell viele Einschränkungen der Standard-Version aufgehoben.
| Feature | Standard Edition | Enterprise Edition |
| Unterstützte Vorgänge | Beschränkt auf Firestore Core-Vorgänge. | Unterstützt Firestore Core- und Pipeline-Vorgänge sowie Firestore-Vorgänge mit 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 | Ein zusätzliches Feld __name__ wird automatisch an die indexierten Felder angehängt, sofern es noch nicht vorhanden ist. | __name__ wird nicht automatisch an die indexierten Felder angehängt. Sie müssen __name__ in den indexierten Feldern explizit 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). Dadurch 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 Indexkonfiguration, Ausführungsstrategien usw. variieren. Um eine eindeutige, deterministische Sortierung der Ergebnisse zu gewährleisten, müssen Sie der Sortierreihenfolge ein eindeutiges Feld wie __name__ hinzufügen. |
| Abfrageleistung und ‑kosten | Abfragen sind aufgrund der Indexanforderungen in der Regel leistungsstark. | Erstellen Sie Indexe, um die Abfrageleistung zu optimieren und Kosten zu senken. Mit Query Explain und Query Insights können Sie fehlende Indexe ermitteln.
Abfragen ohne Indexe können mit zunehmender Größe des Datasets langsam und teuer werden und müssen daher überwacht und optimiert werden. |
| Kosten für die Indexierung | Für Indexschreibvorgänge fallen keine Gebühren an, da Indizes automatisch erstellt werden. | Beim Schreiben von Indexeinträgen werden Schreibeinheiten verbraucht, wenn ein zugehöriges Dokument geschrieben wird (1 Schreibeinheit pro 1 KiB Indexeintragsgröße). Sie sparen Speicherkosten, da nicht für jedes Feld Indexeinträge erstellt werden. |
| Abrechnungsmodell (Lese-/Schreib-/Löschvorgänge) | Die Abrechnung erfolgt pro Lese-, Schreib- und Löschvorgang für ein Dokument. | Die Abrechnung erfolgt pro Lese- und Schreibvorgang (Tranche). Lesevorgänge werden in Leseeinheiten (4 KiB-Tranchen) abgerechnet. Schreib- und Löschvorgänge werden in Schreibeinheiten (1 KiB-Tranchen) zusammengefasst. |
| Grundpreis (pro Million)
Die angezeigten 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 umfassen, als die Kosten für das Standardlesen. |
| Echtzeitaktualisierungen
Die angezeigten Preise gelten für die Region us-central1. |
Echtzeitaktualisierungen werden als Lesevorgänge mit 0,03 $pro 100.000 Dokumente abgerechnet. | Für Echtzeitupdates gibt es eine neue separate SKU (Einheiten von Echtzeitupdates), die pro 4 KiB-Tranche berechnet wird. Echtzeitupdates kosten 0,30$pro Million Leseeinheiten. |