Passer automatiquement à Cloud Firestore

Cette page décrit le processus de mise à niveau de l'ancien Cloud Datastore vers Firestore en mode Datastore.

Firestore peut fonctionner en mode Datastore, ce qui permet d'assurer la rétrocompatibilité avec l'ancien Cloud Datastore. Avec Firestore en mode Datastore, vous pouvez accéder à la couche de stockage améliorée de Cloud Firestore, tout en conservant le comportement du système Datastore. Firestore en mode Datastore supprime les limites suivantes de l'ancien service Cloud Datastore:

• Les requêtes ne sont plus cohérentes à terme. Elles sont au contraire fortement cohérentes, sauf si vous demandez explicitement une cohérence à terme.
• Les requêtes dans les transactions ne doivent plus être des requêtes ascendantes¹.
• Les transactions ne sont plus limitées à 25 groupes d'entités¹.
• Les écritures dans un groupe d'entités ne sont plus limitées à 1 par seconde¹.

Pour en savoir plus sur le mode Datastore, consultez la page Firestore en mode Datastore.

Depuis juin 2021, les migrations de l'ancien Cloud Datastore vers Firestore en mode Datastore ont commencé. Les migrations commencent avec des bases de données à très faible trafic et s'étendront à des bases de données à trafic plus élevé au cours des prochains mois.

¹ Les bases de données qui migrent vers le mode de simultanéité Optimiste avec des groupes d'entités sont toujours soumises à la limite de transaction de 25 groupe d'entités d'entités, ainsi qu'à la limite d'une écriture par seconde dans Firestore en mode Datastore. Les requêtes dans les transactions doivent être des requêtes ascendantes. Pour en savoir plus, consultez la section "Optimisation des modes de simultanéité des groupes d'entités".

Passer automatiquement à Firestore en mode Datastore

Si vous gérez une application qui utilise l'ancien Cloud Datastore, vous n'avez pas besoin de mettre à jour le code de votre application. Nous vous informerons du calendrier de mise à niveau de votre application vers Firestore en mode Datastore. La mise à niveau ne nécessite pas de temps d'arrêt.

Si vous avez d'autres questions concernant la procédure de mise à niveau automatique, contactez l’un de nos canaux d'assistance.

Afficher le type de votre base de données

Vous pouvez utiliser la commande gcloud alpha firestore databases describe pour afficher le type de votre base de données. Recherchez la présence du champ type dans le résultat:

• type: DATASTORE_MODE

  Le type de base de données est Firestore en mode Datastore. Il ne nécessite pas de mise à niveau ou est déjà terminée.

• type absent de la sortie

  Le type de base de données est l'ancien service Cloud Datastore. La base de données sera mise à niveau vers Firestore en mode Datastore.

• type: FIRESTORE_NATIVE

  Le type de base de données est Firestore en mode natif.

Étapes de mise à niveau

Dans les grandes lignes, nous suivons ce processus pour mettre à niveau votre ancienne base de données Cloud Datastore vers Firestore en mode Datastore. Ce processus ne nécessite pas de temps d'arrêt des applications :

1. Ajoutez une nouvelle instance dupliquée de données Firestore en mode Datastore à votre ancienne base de données Cloud Datastore existante. Dupliquez les opérations d'écriture d'entités de manière asynchrone dans Firestore en mode Datastore.

2. Copier les données existantes et les entrées d'index de l'ancien Cloud Datastore vers Firestore en mode Datastore Vérifiez les données après la copie.

3. Redirigez les lectures d'entités directement vers Cloud Firestore en mode Datastore. Redirigez d'abord les lectures cohérentes à terme, puis les lectures fortement cohérentes.

4. Redirigez les écritures d'entités et les lectures transactionnelles directement vers Firestore en mode Datastore.

Ce processus comprend les étapes suivantes.

1. Appliquer les écritures de manière synchrone

Au cours de cette étape, les écritures sont appliquées de manière synchrone à l'ancien Cloud Datastore: les écritures ne signalent les succès que lorsque toutes les modifications apportées aux entités et aux index ont été appliquées à au moins une instance dupliquée. Cela simule le comportement de Firestore en mode Datastore, qui applique également les écritures de manière synchrone (et diffère du comportement par défaut de l'ancien Cloud Datastore dans lequel les écritures sont appliquées de manière asynchrone après avoir été validées).

Cette étape vise à mettre en évidence l'impact de la latence des applications synchrones dans Firestore en mode Datastore avant la mise à niveau. L'application synchrone des écritures se poursuit pendant et après la migration.

Remarque : L'ancienne sémantique Cloud Datastore pour les lectures s'applique toujours à cette étape. Les requêtes non ascendantes sont toujours cohérentes à terme, car les écritures précédentes n'ont peut-être pas été appliquées à l'instance dupliquée qui diffuse la lecture.

Les bases de données ayant peu d'activité ignorent cette étape. Pour déterminer si cette étape a été incluse dans la mise à niveau de votre base de données, examinez les [journaux] de l'étape APPLY_WRITES_SYNCHRONOUSLY.

2. Copier et valider

Cette étape représente le début de la migration. Elle présente une instance dupliquée Firestore en mode Datastore et effectue les étapes suivantes :

1. Journal

   Les opérations d'écriture d'entités dans l'ancien Cloud Datastore commencent également à passer par un canal secondaire vers l'instance dupliquée de Firestore en mode Datastore. Cela fait partie du système de réplication existant de l'ancien Cloud Datastore. Ces opérations d'écriture n'affectent pas la latence en écriture. L'instance dupliquée Firestore en mode Datastore met ces opérations d'écriture en mémoire tampon pour les appliquer après l'étape de copie.

2. Copier

   Dans l'instance dupliquée Firestore en mode Datastore, créez une copie hors connexion de vos données et entrées d'index existantes. L'étape de copie n'affecte pas les anciennes opérations Cloud Datastore. Cette étape peut durer plusieurs jours.

3. Drainer le journal

   Appliquez les écritures de l'étape de journalisation aux données de la copie hors connexion.

4. Vérifier les données

   Vérifiez à nouveau les données dans Firestore en mode Datastore en les comparant aux données de l'ancien Cloud Datastore.

3. Rediriger les lectures cohérentes à terme

Diffusez les lectures cohérentes à terme (requêtes sans filtre d'ancêtre) de Firestore en mode Datastore. L'ancienne sémantique Cloud Datastore pour les lectures s'applique toujours à ce stade:

• Les requêtes ascendantes sont fortement cohérentes.
• Les requêtes non ascendantes sont cohérentes à terme.
• Les recherches sont fortement cohérentes (sauf celles explicitement configurées pour la cohérence à terme).

Firestore en mode Datastore continue d'agir en tant qu'instance dupliquée de vos anciennes données Cloud Datastore.

4. Rediriger les lectures à cohérence forte

Diffusez des lectures fortement cohérentes (non transactionnelles) à partir de Firestore en mode Datastore. Notez que la sémantique ancienne de Cloud Datastore pour les lectures s'applique toujours. Même si les lectures proviennent désormais directement de Firestore, Firestore s'appuie toujours sur l'ancien service Cloud Datastore pour garantir qu'elles sont à jour et assurent une cohérence forte.

5. Rediriger les écritures

Redirigez les écritures d'entités et les lectures transactionnelles vers Firestore en mode Datastore. Les modifications simultanées apportées à la même entité continuent de provoquer l'annulation des transactions. Les modifications simultanées apportées à différentes entités au sein d'un même groupe d'entités n'entraînent plus d'annulations de transactions.

Au début de cette étape, Firestore en mode Datastore s'appuie toujours sur l'ancien Cloud Datastore pour garantir qu'il est à jour avant chaque écriture. Après une dernière vérification qui garantit que toutes les écritures précédentes sont appliquées, Firestore en mode Datastore cesse de consulter l'ancienne version de Cloud Datastore.

6. Migration terminée

La sémantique de Firestore en mode Datastore pour les lectures s'applique désormais. Toutes les requêtes sont fortement cohérentes.

Les tarifs restent les mêmes, mais votre facturation liste désormais les codes SKU Firestore. La page "Quotas" d'App Engine commence à afficher l'utilisation de Firestore au lieu de l'ancienne utilisation de Cloud Datastore.

Transactions

Firestore en mode Datastore accepte trois modes de simultanéité:

• Optimiste

  La plupart des anciennes bases de données Cloud Datastore utilisent une simultanéité optimiste pour les transactions dans Firestore en mode Datastore. La simultanéité optimiste préserve les comportements existants des transactions dans l'ancien Cloud Datastore.

• Optimiste avec des groupes d'entités

  Les bases de données qui dépendent de la sémantique transactionnelle des groupes d'entités migreront vers ce mode de simultanéité. Pour en savoir plus, consultez la section Optimisme avec le mode de simultanéité des groupes d'entités.

• Pessimiste

  Certaines bases de données migrées précédemment avec très peu d'activité ont été migrées avec des verrouillages pessimistes pour les transactions dans Firestore en mode Datastore.

Le mode de simultanéité est accessible via la ressource REST projects.databases de Firestore:

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

Le mode de simultanéité est également disponible en inspectant les journaux pour l'étape PREPARE.

Optimiste avec le mode de simultanéité des groupes d'entités

Pour supprimer les limites de débit des requêtes, des transactions et des écritures en écriture des groupes d'entités, définissez le mode de simultanéité de votre projet sur "Optimistic". Pour vous assurer que cette modification est compatible avec votre projet:

1. Créez un projet de test dans Firestore en mode Datastore.

2. Définissez le mode de simultanéité du projet de test sur OPTIMISTIC. Envoyez une requête HTTP PATCH, comme indiqué ci-dessous.

3. Exécutez des tests sur le projet de test pour vous assurer que votre charge de travail fonctionne comme prévu sans groupe d'entités.

4. Remplacez le mode de simultanéité de votre projet principal (OPTIMISTIC_WITH_ENTITY_GROUPS) par OPTIMISTIC.

Remarque :La bibliothèque Remote API nécessite des groupes d'entités et ne fonctionne pas en mode de simultanéité OPTIMISTIC. Si vous utilisez l'API Remote, migrez-la hors de cette API ou pour continuer à utiliser cette bibliothèque, laissez votre projet en mode OPTIMISTIC_WITH_ENTITY_GROUPS.

Requête HTTP PATCH pour modifier le mode de simultanéité de la base de données:

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"

Journalisation et notifications de progression

Le processus de mise à niveau utilise Cloud Logging pour publier des mises à jour de progression. Pour afficher les journaux, utilisez l'explorateur de journaux, l'API Cloud Logging ou Google Cloud CLI.

Remarque : La facturation doit être activée dans votre projet Google Cloud pour pouvoir recevoir les journaux de progression. Découvrez comment vérifier que la facturation est activée pour votre projet.

Les mises à jour sont publiées dans deux journaux sous le nom du service de journalisation datastore.googleapis.com:

Nom du journal	Ressource surveillée	Charge utile
migration_state	datastore_database	type.googleapis.com/google.datastore.admin.v1.MigrationStateEvent
migration_progress	datastore_database	type.googleapis.com/google.datastore.admin.v1.MigrationProgressEvent

Le journal migration_state est mis à jour lorsque l'état général de la mise à niveau change (RUNNING et COMPLETE).

Le journal migration_progress est mis à jour chaque fois que la mise à niveau passe à une nouvelle étape (PREPARE, START, APPLY_WRITES_SYNCHRONOUSLY, COPY_AND_VERIFY, REDIRECT_EVENTUALLY_CONSISTENT_READS, REDIRECT_STRONGLY_CONSISTENT_READS et REDIRECT_WRITES).

Pour recevoir des notifications au fur et à mesure de la mise à niveau, vous pouvez créer des métriques basées sur les journaux en fonction des deux journaux et créer des alertes en fonction de ces métriques.

Remarque : Les métriques basées sur les journaux basées sur ces journaux doivent utiliser le type de ressource global.

Bannière de migration dans la console Google Cloud

Pendant la migration de votre ancienne base de données Cloud Datastore, une bannière d'informations s'affiche sur la page Entités de la console Google Cloud. Cette bannière inclut un lien pour ouvrir Cloud Logging et filtrer les mises à jour de migration.

1. Dans la console Google Cloud, accédez à la page Bases de données.

   Accéder aux bases de données

2. Sélectionnez la base de données requise dans la liste.

3. Dans le menu de navigation, cliquez sur Entités.

Afficher l'état actuel d'une CLI

Pour afficher rapidement l'état actuel d'une migration, exécutez la commande gcloud suivante:

gcloud datastore operations describe datastore-firestore-migration

Suspension de la migration...

Les migrations de bases de données volumineuses peuvent être suspendues et réactivées. La mise en pause d'une migration empêche sa progression à l'étape suivante jusqu'à sa reprise. La mise en pause d'une migration peut vous aider à déterminer si un changement de comportement ou de performances est dû au processus de migration ou à un facteur non lié.

Après avoir reçu la notification par e-mail concernant la migration de votre base de données, vous pouvez vérifier si elle peut être suspendue et réactivée en exécutant la commande "pause" ci-dessous. Si la migration n'est pas éligible, un message d'erreur indique que la fonctionnalité n'est pas disponible.

Si la migration de votre base de données peut être suspendue et réactivée, les commandes ci-dessous commenceront à fonctionner une fois que la migration aura atteint l'étape START.

Pour suspendre une 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"

Pour reprendre une 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:resumeMigration"

Ces commandes ne fonctionneront plus une fois la migration terminée.

Si vous souhaitez que votre migration soit suspendue pendant plus d'une semaine, contactez-nous via un canal d'assistance. Au bout de deux semaines, la migration peut reprendre automatiquement.

Métriques Cloud Monitoring

Les métriques Cloud Monitoring disponibles pour votre base de données Datastore restent identiques tout au long du processus de mise à niveau. Consultez les métriques Datastore disponibles.