Passer automatiquement à Cloud Firestore

Cette page décrit la procédure de mise à niveau de l'ancienne version de 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 anciennes limites suivantes relatives à 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 sont plus obligatoires pour ê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.

Les migrations de l'ancienne version de Cloud Datastore vers Firestore en mode Datastore ont commencé depuis juin 2021. 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 groupes d'entités" restent soumises à la limite de 25 transactions de groupe d'entités d'entités et à 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 "Optimiste avec le mode de simultanéité des groupes d'entités".

Passer automatiquement à Firestore en mode Datastore

Si vous gérez une application qui utilise l'ancien service 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 votre type de base de données

Vous pouvez utiliser la commande gcloud alpha firestore databases describe pour afficher votre type de 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 la mise à niveau a déjà été effectuée.

• type absent de la sortie

  Le type de base de données est un ancien 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

De manière générale, nous suivons cette procédure 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 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. Copiez les données existantes et les entrées d'index de l'ancienne version de 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 opérations d'écriture sont appliquées de manière synchrone à l'ancienne version de Cloud Datastore: les opérations d'écriture ne génèrent des résultats que lorsque toutes les modifications apportées aux entités et aux index ont été appliquées à au moins une instance répliquée. Cette opération 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 leur commit).

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 restent cohérentes à terme, car les écritures précédentes peuvent ne pas avoir été appliquées à l'instance répliquée diffusant 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, inspectez les [logs] pour 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'ancienne version de Cloud Datastore commencent également à circuler via un canal secondaire vers l'instance répliquée Firestore en mode Datastore. Cela se produit dans le cadre 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'a aucune incidence sur 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 à celles de l'ancienne version de Cloud Datastore.

3. Rediriger les lectures cohérentes à terme

Diffusez des lectures cohérentes à terme (requêtes sans filtre ascendant) à partir 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 de servir d'instance répliqué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 l'ancienne sémantique 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'ancienne version de Cloud Datastore pour garantir qu'elle est à jour et que les lectures fortement cohérentes sont à jour.

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'ancienne version de Cloud Datastore pour garantir qu'elle est à jour avant chaque écriture. Après un dernier passage 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 affiche l'utilisation de Firestore au lieu de l'ancienne utilisation de Cloud Datastore.

Transactions

Firestore en mode Datastore est compatible avec trois modes de simultanéité:

• Optimiste

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

• Optimiste avec les groupes d'entités

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

• Pessimiste

  Certaines bases de données précédemment migrées avec très peu d'activité étaient migrées avec des verrous 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"

Vous pouvez également vérifier le mode de simultanéité en inspectant les journaux de l'étape PREPARE.

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

Pour supprimer les limites de débit de requêtes, de transactions et d'écriture des groupes d'entités, définissez le mode de simultanéité de votre projet sur "Optimiste". 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. Émettez une requête HTTP PATCH, comme indiqué ci-dessous.

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

4. Passez le mode de simultanéité de votre projet principal de OPTIMISTIC_WITH_ENTITY_GROUPS à OPTIMISTIC.

Remarque :La bibliothèque de l'API Remote nécessite des groupes d'entités et ne fonctionne pas en mode de simultanéité OPTIMISTIC. Si vous utilisez l'API Remote, migrez hors de cette API ou, pour continuer à utiliser cette bibliothèque, conservez 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 la 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 de 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 basées sur les deux journaux et créer des alertes basées sur 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 le processus de migration de votre ancienne base de données Cloud Datastore, une bannière d'informations s'affiche sur la page Datastore Studio 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 Base de données.

   Accéder à la page "Bases de données"

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

3. Dans le menu de navigation, cliquez sur Datastore Studio.

Afficher l'état actuel sur une CLI

Pour afficher rapidement l'état actuel d'une migration, utilisez 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 l'empêche de passer à l'étape suivante tant qu'elle n'a pas été réactivée. La mise en pause d'une migration peut vous aider à déterminer si un changement de comportement ou de performances observé est le résultat du processus de migration ou d'un facteur sans rapport.

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 de pause ci-dessous. Si la migration n'est pas éligible, elle renvoie une erreur indiquant 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 votre migration doit être suspendue pendant plus d'une semaine, contactez l'assistance 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.