Automatisches Upgrade auf Firestore

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

Firestore kann im Datenspeichermodus verwendet werden und ist damit abwärtskompatibel mit Legacy-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. Mit Firestore im Datastore-Modus werden die folgenden Legacy-Einschränkungen von Cloud Datastore aufgehoben:

  • 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 mehr Ancestor-Abfragen sein1.
  • Transaktionen sind nicht mehr auf 25 Entitätengruppen1 beschränkt.
  • Schreibvorgänge in eine Entitätengruppe sind nicht mehr auf einen Vorgang pro Sekunde1 beschränkt.

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 Nebenläufigkeitsmodus „Optimistisch mit Entitätsgruppen“ migriert werden, unterliegen weiterhin dem Transaktionslimit von 25 Entitätengruppen sowie dem Limit von 1 Schreibvorgang pro Sekunde in Firestore im Datastore-Modus. Abfragen in Transaktionen müssen Ancestor-Abfragen sein. Weitere Informationen finden Sie im Abschnitt „Optimistisch mit Entitätsgruppen-Parallelitätsmodus“.

Automatisches Upgrade auf Firestore im Datastore-Modus

Wenn Sie eine Anwendung verwalten, die Legacy-Cloud Datastore verwendet, müssen Sie Ihren Anwendungscode nicht 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

Mit dem Befehl gcloud alpha firestore databases describe können Sie den Datenbanktyp aufrufen. Suchen Sie in der Ausgabe nach dem Feld type:

  • type: DATASTORE_MODE

    Der Datenbanktyp ist Firestore im Datastore-Modus. Ein Upgrade ist nicht erforderlich und das Upgrade wurde bereits abgeschlossen.

  • type nicht in der Ausgabe vorhanden

    Der Datenbanktyp ist Legacy-Cloud Datastore. Die Datenbank wird auf Firestore im Datastore-Modus aktualisiert.

  • type: FIRESTORE_NATIVE

    Der Datenbanktyp ist Firestore im nativen Modus.

Upgrade-Phasen

Grundsätzlich führen wir die folgenden Schritte aus, um Ihre Legacy-Cloud Datastore-Datenbank auf Firestore im Datastore-Modus zu aktualisieren. Für diesen Prozess ist keine Ausfallzeit der Anwendung erforderlich:

  1. Fügen Sie der vorhandenen Cloud Datastore-Legacy-Datenbank ein neues Datenreplikat für Firestore im Datastore-Modus hinzu. Duplizieren Sie asynchron Entitätenschreibvorgänge in Firestore im Datastore-Modus.

  2. Kopieren Sie vorhandene Daten und Indexeinträge aus dem Legacy-Cloud Datastore in 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 Legacy-Cloud Datastore angewendet: Schreibvorgänge werden erst als erfolgreich gemeldet, wenn alle Änderungen an Entitäten und Indexen auf mindestens ein Replikat angewendet wurden. Dies simuliert das Verhalten von Firestore im Datastore-Modus, das auch Schreibvorgänge synchron anwendet (und unterscheidet sich vom Standardverhalten des Legacy-Cloud Datastore, bei 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. Prüfen Sie die Logs für die Phase APPLY_WRITES_SYNCHRONOUSLY, um festzustellen, ob diese Phase in das Upgrade der Datenbank einbezogen wurde.

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

    Auch die Schreibvorgänge von Entitäten im Legacy-Cloud Datastore beginnen über einen Seitenkanal zum Replikat von Firestore im Datastore-Modus. Dies geschieht im Rahmen des bestehenden Replikationssystems von 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 Kopierschritt hat keine Auswirkungen auf Legacy-Cloud Datastore-Vorgänge. 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

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

3. Lesevorgänge mit Eventually Consistency weiterleiten

Stellen Sie letztendlich konsistente Lesevorgänge (Abfragen ohne Ancestor-Filter) aus Firestore im Datastore-Modus bereit. Die Legacy-Semantik von Cloud Datastore für Lesevorgänge gilt auch jetzt:

  • 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 Cloud Datastore-Legacy-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 von Firestore stammen, verlässt sich Firestore weiterhin auf den Legacy-Cloud Datastore, um sicherzustellen, dass dieser für stark konsistente Lesevorgänge auf dem neuesten Stand ist.

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 verlässt sich Firestore im Datastore-Modus weiterhin auf den Legacy-Cloud Datastore, um sicherzustellen, dass er vor jedem Schreibvorgang auf dem neuesten Stand ist. Nach einem letzten Durchlauf, mit dem sichergestellt wird, dass alle vorherigen Schreibvorgänge angewendet wurden, beendet Firestore im Datastore-Modus die Nutzung des Legacy-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 jetzt die Firestore-Nutzung anstelle der Legacy-Cloud Datastore-Nutzung angezeigt.

Transaktionen

Firestore im Datastore-Modus unterstützt drei Nebenläufigkeitsmodi:

  • optimistisch

    Die meisten Legacy-Cloud Datastore-Datenbanken verwenden optimistische Nebenläufigkeit für Transaktionen in Firestore im Datastore-Modus. Die optimistische Nebenläufigkeit bewahrt das vorhandene Verhalten von Transaktionen im Legacy-Cloud Datastore.

  • Optimistisch mit Entitätsgruppen

    Datenbanken, die von der Transaktionssemantik der Entitätengruppe abhängen, werden zu diesem Nebenläufigkeitsmodus migriert. Weitere Informationen finden Sie im Abschnitt „Optimistisch mit Entitätsgruppen-Gleichzeitmodus“.

  • Pessimistisch

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

Der Nebenläufigkeitsmodus kann über die Firestore-REST-Ressource projects.databases aufgerufen werden:

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

Den Nebenläufigkeitsmodus finden Sie auch in den Logs für die Phase PREPARE.

Optimistisch mit Nebenläufigkeitsmodus von Entitätsgruppen

Wenn Sie die „Optimistic With Entity Groups“-Abfrage-, Transaktions- und Schreibdurchsatzbeschränkungen entfernen möchten, ändern Sie den Nebenläufigkeitsmodus Ihres Projekts in „Optimistisch“. So sorgen Sie dafür, dass diese Änderung mit Ihrem Projekt kompatibel ist:

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

  2. Ändern Sie den Nebenläufigkeitsmodus des Testprojekts in OPTIMISTIC. Senden Sie eine HTTP PATCH-Anfrage wie unten gezeigt.

  3. Führen Sie Tests für das Testprojekt aus, um zu prüfen, ob die Arbeitslast ohne Entitätsgruppen wie erwartet funktioniert.

  4. Ändern Sie den Nebenläufigkeitsmodus des Hauptprojekts von OPTIMISTIC_WITH_ENTITY_GROUPS zu OPTIMISTIC.

HTTP-PATCH-Anfrage zum Ändern des Nebenläufigkeitsmodus der Datenbank:

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.

Updates werden in zwei Logs unter dem Namen des Logging-Dienstes 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).

Wenn Sie im Rahmen des Upgrades Benachrichtigungen erhalten möchten, können Sie basierend auf den beiden Logs logbasierte Messwerte erstellen und darauf Benachrichtigungen erstellen.

Migrationsbanner in der Google Cloud Console

Während die Cloud Datastore-Legacy-Datenbank migriert wird, wird auf der Seite Datastore Studio der Google Cloud Console ein Informationsbanner angezeigt. Dieses Banner enthält einen Link zum Öffnen von Cloud Logging und zum Filtern 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 ansehen

Mit dem folgenden gcloud-Befehl können Sie schnell den aktuellen Status einer Migration aufrufen:

gcloud datastore operations describe datastore-firestore-migration

Migration pausieren

Große Datenbankmigrationen können angehalten und fortgesetzt werden. Dadurch wird verhindert, dass die Migration zur nächsten Phase fortgesetzt wird, bis sie fortgesetzt wird. Durch Pausieren einer Migration können Sie feststellen, ob eine beobachtete Verhaltens- oder Leistungsänderung auf den Migrationsprozess oder einen nicht verwandten Faktor zurückzuführen ist.

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. Dazu führen Sie den Befehl „Pause“ unten aus. Wenn die Migration nicht zulässig ist, wird ein Fehler zurückgegeben, der darauf hinweist, dass die Funktion nicht verfügbar ist.

Wenn die Migration Ihrer Datenbank angehalten und fortgesetzt werden kann, beginnen die folgenden Befehle, sobald die Migration die Phase START erreicht.

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 Abschluss der Migration nicht mehr.

Wenn Ihre Migration länger als eine Woche pausiert bleiben soll, wenden Sie sich über einen Supportkanal an uns. 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.