Automatisches Upgrade auf Firestore

Auf dieser Seite wird der Upgradepfad vom alten Cloud Datastore zu Firestore im Datastore-Modus beschrieben.

Firestore kann im Datastore-Modus verwendet werden und ist damit abwärtskompatibel mit dem bisherigen Cloud Datastore. Mit Firestore im Datastore-Modus können Sie Zugriff auf die verbesserte Speicherschicht von Firestore erhalten und gleichzeitig das Systemverhalten von Datastore beibehalten. Firestore im Datastore-Modus hebt die folgenden Legacy-Einschränkungen von Cloud Datastore auf:

  • Abfragen haben keine Eventual Consistency mehr. Stattdessen sind sie strikt konsistent, es sei denn, Sie fordern explizit Eventual Consistency an.
  • Abfragen in Transaktionen müssen nicht länger Ancestor-Abfragen sein1.
  • Transaktionen sind nicht mehr auf 25 Entitätengruppen beschränkt1.
  • Schreibvorgänge in eine Entitätengruppe sind nicht mehr auf 1 Schreibvorgang pro Sekunde beschränkt1.

Weitere Informationen zum Datastore-Modus finden Sie unter Firestore im Datastore-Modus.

Seit Juni 2021 haben Migrationen vom Legacy-Cloud Datastore zu Firestore im Datastore-Modus begonnen. Die Migrationen beginnen mit Datenbanken mit sehr geringem Traffic und werden in den nächsten Monaten auf Datenbanken mit höherem Traffic erweitert.

1 Datenbanken, die zum Gleichzeitigkeitsmodus „Optimistisch mit Entitätengruppen“ migrieren, unterliegen weiterhin dem Transaktionslimit von 25 Entitätengruppen sowie dem Limit von einem Schreibvorgang pro Sekunde in Firestore im Datastore-Modus. Abfragen in Transaktionen müssen Ancestor-Abfragen sein. Der optimistische Bericht Mit Entitätsgruppen-Nebenläufigkeitsmodus Abschnitt.

Automatisches Upgrade auf Firestore im Datastore-Modus

Wenn Sie eine Anwendung verwalten, die Legacy-Cloud Datastore nutzt, müssen Sie Ihren Anwendungscode aktualisieren. Wir informieren Sie über den Zeitplan für das Upgrade Ihrer Anwendung auf Firestore im Datastore-Modus. Bei diesem Upgrade kommt es zu keinen Ausfallzeiten.

Wenn Sie weitere Fragen zum automatischen Upgradevorgang haben, setzen Sie sich über einen unserer Supportkanäle mit uns in Verbindung.

Datenbanktyp ansehen

Sie können die gcloud alpha firestore databases describe um Ihren Datenbanktyp anzuzeigen. Prüfen Sie, ob das Feld type in der Ausgabe vorhanden ist:

  • type: DATASTORE_MODE

    Der Datenbanktyp ist Firestore im Datastore-Modus. Nicht ein Upgrade erfordern oder die Umstellung bereits abgeschlossen ist.

  • type ist in der Ausgabe nicht vorhanden

    Der Datenbanktyp ist der alte Cloud Datastore. Die Datenbank wird auf Firestore im Datastore-Modus umgestellt.

  • type: FIRESTORE_NATIVE

    Der Datenbanktyp ist Firestore im nativen Modus.

Upgrade-Phasen

Im Folgenden wird der Ablauf beschrieben, der für das Upgrade Ihrer alten Cloud Datastore-Datenbank auf Firestore im Datastore-Modus verwendet wird. Für diesen Prozess ist keine Ausfallzeit der Anwendung erforderlich:

  1. Neues Datenreplikat für Firestore im Datastore-Modus zu vorhandenem vorhandenen Datenreplikat hinzufügen Cloud Datastore-Legacy-Datenbank. Duplizieren Sie asynchron Entitätenschreibvorgänge in Firestore im Datastore-Modus.

  2. Vorhandene Daten und Indexeinträge aus Legacy-Cloud Datastore kopieren zu Firestore im Datastore-Modus. Prüfen Sie die Daten nach dem Kopieren.

  3. Leiten Sie die Entitäten direkt an Firestore im Datastore-Modus weiter. Leiten Sie zuerst Lesevorgänge mit Eventually Consistency und dann Lesevorgänge mit strikter Konsistenz weiter.

  4. Leiten Sie Entitätenschreibvorgänge und transaktionale Lesevorgänge direkt an Firestore im Datastore-Modus weiter.

Dieser Prozess umfasst die folgenden Phasen.

1. Schreibvorgänge synchron anwenden

In dieser Phase werden Schreibvorgänge synchron auf die bisherige Cloud Datastore-Version angewendet: Schreibvorgänge melden den Erfolg erst, wenn alle Änderungen an Entitäten und Indexen auf mindestens ein Replikat angewendet wurden. Dadurch wird das Verhalten von Firestore im Datastore-Modus simuliert, das auch Schreibvorgänge synchron anwendet (und unterscheidet sich vom Standardverhalten des bisherigen Cloud Datastore, in dem Schreibvorgänge nach dem Commit asynchron angewendet werden).

In dieser Phase sollen vor dem Upgrade Latenzauswirkungen von synchronen Firestore in Datastore-Modus angezeigt werden. Die synchrone Anwendung von Schreibvorgängen wird während und nach der Migration fortgesetzt.

Datenbanken mit sehr geringer Aktivität überspringen diese Phase. Um festzustellen, ob diese Phase in das Upgrade Ihrer Datenbank einbezogen wurde, prüfen Sie die [Protokolle] für die Phase APPLY_WRITES_SYNCHRONOUSLY.

2. Kopieren und verifizieren

Diese Phase steht für den Beginn der Migration. Damit wird ein Replikat von Firestore im Datastore-Modus eingeführt und es werden die folgenden Schritte ausgeführt:

  1. Übersicht

    Entitätsschreibvorgänge in der bisherigen Cloud Datastore-Version fließen auch in einen Nebenkanal zum Replikat von Firestore im Datastore-Modus ein. Dies geschieht als Teil des vorhandenen Replikationssystems des alten Cloud Datastore. Diese Schreibvorgänge wirken sich nicht auf die Schreiblatenz aus. Das Replikat von Firestore im Datastore-Modus puffert diese Schreibvorgänge, um sie nach dem Kopierschritt anzuwenden.

  2. Kopieren

    Erstellen Sie im Replikat von Firestore im Datastore-Modus eine Offline-Kopie Ihrer vorhandenen Daten und Indexeinträge. Der Schritt „Kopieren“ hat keine Auswirkungen Legacy-Vorgänge von Cloud Datastore. Dieser Schritt kann mehrere Tage dauern.

  3. Drain-Übersicht

    Wenden Sie die Schreibvorgänge aus dem Übersichtsschritt auf die Daten aus der Offline-Kopie an.

  4. Daten prüfen

    Prüfen Sie die Daten in Firestore im Datastore-Modus noch einmal, indem Sie sie mit den Daten im bisherigen Cloud Datastore vergleichen.

3. Lesevorgänge mit Eventually Consistency weiterleiten

Stellen Sie Lesevorgänge mit Eventually Consistency (Abfragen ohne Ancestor-Filter) aus Firestore im Datastore-Modus bereit. Die bisherige Cloud Datastore-Semantik für Lesevorgänge gilt an dieser Stelle nach wie vor:

  • Ancestor-Abfragen haben strikte Konsistenz.
  • Nicht-Ancestor-Abfragen haben Eventual Consistency.
  • Suchvorgänge haben strikte Konsistenz (mit Ausnahme der explizit für Eventual Consistency konfigurierten Jobs).

Firestore im Datastore-Modus fungiert weiterhin als Replikat Ihrer bisherigen Cloud Datastore-Daten.

4. Lesevorgänge mit strikter Konsistenz weiterleiten

Stellen Sie strikt konsistente Lesevorgänge (nicht transaktional) aus Firestore im Datastore-Modus bereit. Beachten Sie, dass die Legacy-Semantik von Cloud Datastore für Lesevorgänge weiterhin gilt. Obwohl Lesevorgänge jetzt direkt aus Firestore, immer noch auf Legacy-Cloud Datastore angewiesen, um deren Aktualität Lesevorgänge mit Strong Consistency.

5. Schreibvorgänge weiterleiten

Leiten Sie Entitätenschreibvorgänge und transaktionale Lesevorgänge an Firestore im Datastore-Modus weiter. Gleichzeitige Änderungen an derselben Entität führen weiterhin zu Transaktionsabbrüchen. Gleichzeitige Änderungen an verschiedenen Entitäten innerhalb derselben Entitätengruppe führen nicht mehr zu Transaktionsabbrüchen.

Zu Beginn dieser Phase stützt sich Firestore im Datastore-Modus noch auf Cloud Datastore, damit er vor jedem Schreibvorgang auf dem neuesten Stand ist. Nach einem abschließenden Durchlauf, bei dem alle vorherigen Schreibvorgänge angewendet werden, verlässt sich Firestore im Datastore-Modus nicht mehr auf das bisherige Cloud Datastore.

6. Migration abgeschlossen

Nun gilt die Semantik von Firestore im Datastore-Modus für Lesevorgänge: Alle Abfragen sind strikt konsistent.

Die Preise bleiben unverändert, aber Ihre Abrechnung listet jetzt Firestore-SKUs auf. Auf der Seite „App Engine-Kontingente“ wird die Firestore-Nutzung anstelle der bisherigen Cloud Datastore-Nutzung angezeigt.

Transaktionen

Firestore im Datastore-Modus unterstützt drei Parallelitätsmodi:

  • optimistisch

    Für die meisten älteren Cloud Datastore-Datenbanken wird die optimistische Gleichzeitigkeit für Transaktionen in Firestore im Datastore-Modus verwendet. Durch die optimistische Gleichzeitigkeit wird das vorhandene Verhalten von Transaktionen im bisherigen Cloud Datastore beibehalten.

  • Optimistisch mit Entitätsgruppen

    Datenbanken, die von einer Entitätengruppe abhängen wird die transaktionale Semantik in diesen Gleichzeitigkeitsmodus migriert. Weitere Informationen finden Sie im Abschnitt Optimistischer Parallelisierungsmodus mit Entitätengruppen.

  • Pessimistisch

    Einige zuvor migrierte Datenbanken mit sehr geringer Aktivität wurden migriert mit pessimistischen Sperren für Transaktionen in Firestore im Datastore-Modus.

Der Gleichzeitigkeitsmodus ist über Firestore zugänglich projects.databases REST-Ressource:

curl -X GET -H "Authorization: Bearer "$(gcloud auth print-access-token) \
"https://firestore.googleapis.com/v1/projects/PROJECT_ID/databases"

Sie finden den Gleichzeitigkeitsmodus auch in den Logs auf PREPARE-Phase.

Optimistischer Nebenläufigkeitsmodus mit Entitätengruppen

Um die „Optimistic With Entity Groups“-Beschränkungen bei Abfrage, Transaktions- und Schreibdurchsatz zu entfernen, den Gleichzeitigkeitsmodus Ihres Projekts in Optimistisch. So prüfen Sie, ob diese Änderung mit Ihrem Projekt kompatibel ist:

  1. Erstellen Sie ein Testprojekt in Firestore im Datastore-Modus.

  2. Nebenläufigkeit des Testprojekts ändern Modus auf OPTIMISTIC ändern. Senden Sie eine HTTP-PATCH-Anfrage, wie unten gezeigt.

  3. Führen Sie Tests für das Testprojekt durch, um sicherzustellen, dass Ihre Arbeitslast ohne Entitätsgruppen wie erwartet funktioniert.

  4. Nebenläufigkeitsmodus des Hauptprojekts von ändern OPTIMISTIC_WITH_ENTITY_GROUPS in OPTIMISTIC.

HTTP-Anfrage PATCH, um den Gleichzeitigkeitsmodus der Datenbank zu ändern:

curl --request PATCH \
--header "Authorization: Bearer "$(gcloud auth print-access-token) \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--data '{"concurrencyMode":"OPTIMISTIC"}' \
"https://firestore.googleapis.com/v1/projects/PROJECT_ID/databases/(default)?updateMask=concurrencyMode"

Logging und Fortschrittsbenachrichtigungen

Beim Upgradeprozess wird Cloud Logging verwendet, um Fortschrittsaktualisierungen zu veröffentlichen. Verwenden Sie zum Aufrufen der Logs den Log-Explorer, die Cloud Logging API oder die Google Cloud CLI.

Aktualisierungen werden in zwei Logs unter dem Logging-Dienstnamen datastore.googleapis.com veröffentlicht:

Logname Überwachte Ressource Nutzlast
migration_state datastore_database type.googleapis.com/google.datastore.admin.v1.MigrationStateEvent
migration_progress datastore_database type.googleapis.com/google.datastore.admin.v1.MigrationProgressEvent

Das Log migrationmigration_state“ wird aktualisiert, wenn sich der Gesamtstatus des Upgrades (RUNNING und COMPLETE) ändert.

Das Log zur Migration_Progress wird jedes Mal aktualisiert, wenn das Upgrade in eine neue Phase verschoben wird (PREPARE, START, APPLY_WRITES_SYNCHRONOUSLY, COPY_AND_VERIFY, REDIRECT_EVENTUALLY_CONSISTENT_READS, REDIRECT_STRONGLY_CONSISTENT_READS und REDIRECT_WRITES).

Um Benachrichtigungen zu erhalten, während Ihr Upgrade fortgesetzt wird, können Sie anhand der beiden Logs logbasierte Messwerte erstellen und auf dieser Grundlage Benachrichtigungen erstellen.

Migrationsbanner in der Google Cloud Console

Während die Migration Ihrer bisherigen Cloud Datastore-Datenbank läuft, wird auf der Seite Datastore Studio in der Google Cloud Console ein Informationsbanner angezeigt. Dieses Banner enthält einen Link zum Öffnen von Cloud Logging und filtern Sie nach Migrationsaktualisierungen.

  1. Rufen Sie in der Google Cloud Console die Seite Datenbanken auf.

    Zur Seite „Datenbanken“

  2. Wählen Sie die benötigte Datenbank aus der Liste der Datenbanken aus.

  3. Klicken Sie im Navigationsmenü auf Datastore Studio.

Aktuellen Status in einer Befehlszeile aufrufen

So können Sie sich den aktuellen Status einer Migration schnell ansehen: gcloud-Befehl:

gcloud datastore operations describe datastore-firestore-migration

Migration pausieren

Große Datenbankmigrationen können pausiert und fortgesetzt werden. Eine Pausierung des Migration verhindert, dass er in die nächste Phase übergeht, bis er abgeschlossen ist. wurde(n) fortgesetzt. Durch Pausieren einer Migration können Sie feststellen, Verhalten oder der Leistung ist das Ergebnis des Migrationsprozesses oder unabhängiger Faktor.

Nachdem Sie die E-Mail-Benachrichtigung über die Migration Ihrer Datenbank erhalten haben, können Sie prüfen, ob sie pausiert und fortgesetzt werden kann, indem Sie die Befehl unten. Wenn die Migration nicht zulässig ist, wird ein Fehler zurückgegeben. gibt an, dass die Funktion nicht verfügbar ist.

Wenn die Migration Ihrer Datenbank pausiert und fortgesetzt werden kann, führen die Befehle unten beginnen, sobald die Migration die Phase START erreicht hat.

So pausieren Sie eine Migration:

curl --request POST \
--header "Authorization: Bearer "$(gcloud auth print-access-token) \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--data '{}' \
"https://datastore.googleapis.com/v1/projects/PROJECT_ID:pauseMigration"

So setzen Sie eine Migration fort:

curl --request POST \
--header "Authorization: Bearer "$(gcloud auth print-access-token) \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--data '{}' \
"https://datastore.googleapis.com/v1/projects/PROJECT_ID:resumeMigration"

Diese Befehle funktionieren nach der Migration nicht mehr.

Wenn Sie die Migration länger als eine Woche pausieren müssen, wenden Sie sich an Supportkanal nutzen. Nach zwei Wochen wird die Migration möglicherweise automatisch fortgesetzt.

Cloud Monitoring-Messwerte

Die für Ihre Datastore-Datenbank verfügbaren Cloud Monitoring-Messwerte bleiben während des Upgrades erhalten, siehe verfügbare Datastore-Messwerte.