Passer automatiquement à Cloud Firestore

Cette page décrit la procédure 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.

Les migrations depuis l'ancien Cloud Datastore vers Firestore en mode Datastore ont commencé en 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 des groupes d'entités sont toujours soumises à la limite de transaction de 25 groupes d'entités, ainsi qu'à une limite d'é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 de la simultanéité avec les 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. Elle ne nécessite pas de mise à niveau ou a déjà été effectuée.

• type absent de la sortie

  Le type de base de données est l'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 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. Ajouter 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. Copier les entrées de données et d'index existantes 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: elles n'indiquent les réussites qu'une fois que 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:La sémantique ancienne de 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 n'ont peut-être pas été appliquées à l'instance dupliqué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, examinez 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'ancien Cloud Datastore commencent également à transiter par un canal secondaire vers l'instance dupliquée 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 de servir d'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 Cloud Datastore pour garantir que les lectures sont toujours cohérentes.

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 service 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 les données de l'ancien 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 les groupes d'entités

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

• Pessimiste

  Certaines bases de données migrées auparavant avec une activité très faible ont été 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 trouver le mode de simultanéité 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 de requêtes, de transactions et d'écriture de l'option "Optimistic With Entity Groups", 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éer 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 groupes d'entités.

4. Remplacez le mode de simultanéité du projet principal OPTIMISTIC_WITH_ENTITY_GROUPS par 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-la hors de cette API ou continuez à 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 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 Google Cloud Console

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

Accéder aux entités Datastore

Afficher l'état actuel d'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 jusqu'à sa reprise. La mise en pause d'une migration peut vous aider à déterminer si un changement observé dans le comportement ou les performances est le résultat du processus de migration ou d'un facteur non lié.

Après avoir reçu la notification par e-mail concernant la migration de votre base de données, exécutez la commande de mise en veille ci-dessous pour vérifier si elle peut être suspendue et réactivée. 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 à s'exécuter 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 interrompre la migration pendant plus d'une semaine, contactez-nous via un canal d'assistance. Après 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.