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 service 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 limitations suivantes liées à 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 n'ont plus besoin d'être des requêtes ascendantes1.
- Les transactions ne sont plus limitées à 25 groupes d'entités1.
- Les écritures dans un groupe d'entités ne sont plus limitées à une par seconde1.
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.
1 Les bases de données qui migrent vers le mode de concurrence Optimistic With Entity Groups sont toujours soumises à la limite de 25 transactions par groupe 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 Optimistic avec le mode de concurrence des groupes d'entités.
Passer automatiquement à Firestore en mode Datastore
Si vous gérez une application qui utilise l'ancienne version de 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
gcloud alpha firestore databases describe
pour afficher votre type de base de données. Recherchez la présence du champ type
.
dans la sortie:
type: DATASTORE_MODE
Le type de base de données est Firestore en mode Datastore. Il ne fait pas une mise à niveau est requise ou déjà effectuée.
type
n'est pas présent dans la sortieLe 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 appliquons le processus suivant 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 :
Ajoutez une nouvelle instance dupliquée de données Firestore en mode Datastore à votre ancienne base de données Cloud Datastore. Dupliquez les opérations d'écriture d'entités de manière asynchrone dans Firestore en mode Datastore.
Copiez 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.
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.
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'ancienne version de Cloud Datastore : les écritures ne signalent pas de réussite tant que toutes les modifications apportées aux entités et aux index n'ont pas été appliquées à au moins une instance dupliquée. Cela simule le comportement de Firestore en mode Datastore, applique les écritures de manière synchrone (et diffère du comportement par défaut de l'ancien dans lequel les écritures sont appliquées de manière asynchrone après le 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.
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 :
Journal
Les opérations d'écriture d'entités dans l'ancienne version de Cloud Datastore commencent également à circuler via vers l'instance répliquée Firestore en mode Datastore. Cela se produit dans le système de réplication existant de l'ancienne version de 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.
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 pas d'incidence sur les anciennes opérations Cloud Datastore. Cette étape peut durer plusieurs jours.
Drainer le journal
Appliquez les écritures de l'étape de journalisation aux données de la copie hors connexion.
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. La sémantique Cloud Datastore héritée 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 jouer le rôle 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 continue de s'appliquer. Même si les lectures proviennent désormais directement de Firestore, s'appuie toujours sur l'ancien service Cloud Datastore pour garantir qu'il est à jour des lectures à 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'ancienne version de Cloud Datastore pour garantir qu'il est à jour avant chaque écriture. Après un qui garantit que toutes les écritures précédentes appliqué, Firestore en mode Datastore arrête la consultation 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 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 la les comportements existants des transactions dans l'ancienne version de Cloud Datastore.
Optimiste avec les groupes d'entités
Bases de données qui dépendent d'un groupe d'entités transactionnelles va migrer vers ce mode de simultanéité. Pour en savoir plus, consultez la section sur le mode de cohérence optimiste avec les groupes d'entités.
Pessimistic
Certaines bases de données précédemment migrées avec très peu d'activité ont été migrées avec des verrous pessimistes pour les transactions dans Firestore en mode Datastore.
Le mode de simultanéité est accessible via Firestore projects.databases Ressource REST:
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 rechercher
l'étape PREPARE
.
Mode de simultanéité optimiste avec des groupes d'entités
Pour supprimer les limites de débit en requêtes, en transactions et en écritures d'Optimistic avec les 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 :
Créez un projet de test dans Firestore en mode Datastore.
Définissez le mode de simultanéité du projet de test sur
OPTIMISTIC
. Émettre un PATCH HTTP comme indiqué ci-dessous.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.
Modifier le mode de simultanéité de votre projet principal De
OPTIMISTIC_WITH_ENTITY_GROUPS
àOPTIMISTIC
.
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 utilisez l'explorateur de journaux l'API Cloud Logging ou Google Cloud CLI ;
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 migration, vous pouvez : créer des métriques basées sur les journaux basées sur les deux les journaux créer des alertes en fonction ces métriques.
Bannière de migration dans la console Google Cloud
Pendant que votre ancienne base de données Cloud Datastore est en cours de migration, une d'informations s'affichera 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.
Dans la console Google Cloud, accédez à la page Base de données.
Sélectionnez la base de données requise dans la liste des bases de données.
Dans le menu de navigation, cliquez sur Datastore Studio.
Afficher l'état actuel dans une CLI
Pour afficher rapidement l'état actuel d'une migration, utilisez le code suivant :
Commande gcloud
:
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. Mettre en veille la migration l'empêche de passer à l'étape suivante tant qu'elle n'a pas été réactivée(s) Suspendre 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 sans rapport.
Après avoir reçu la notification par e-mail concernant la migration de votre base de données, vous vous pouvez vérifier s'il est possible de le mettre en veille et de le réactiver ci-dessous. Si la migration n'est pas éligible, une erreur s'affiche, indiquant que la fonctionnalité n'est pas disponible.
Si la migration de votre base de données peut être suspendue et reprise, 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 devez suspendre votre migration pendant plus d'une semaine, contactez 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.