Migrer Spanner vers une base de données en dialecte PostgreSQL

Cette page décrit les principales considérations et les étapes à suivre lors de la migration de Spanner vers une autre base de données en dialecte PostgreSQL si vous souhaitez déplacer une application hors de Spanner ou de Google Cloud. Vous pouvez également utiliser les informations de cette page si vous devez comprendre ou démontrer la faisabilité du transfert de votre base de données, par exemple pour la planification de la sortie en cas de stress en cas de sinistre.

L'interface PostgreSQL de Spanner est le meilleur choix pour les applications qui ont besoin de l'option de déploiement dans un autre environnement compatible avec PostgreSQL, que ce soit dans Google Cloudou ailleurs. L'interface PostgreSQL utilise une syntaxe familière et des clients standards de l'écosystème PostgreSQL. Elle permet ainsi aux développeurs et aux opérateurs d'utiliser leurs connaissances et compétences PostgreSQL existantes.

Il utilise le même traitement des requêtes, la même coordination des transactions, le même stockage distribué et la même infrastructure réseau que le dialecte GoogleSQL. Si vous avez besoin d'une base de données compatible avec la portabilité, vous ne compromettez pas les avantages fondamentaux de Spanner en termes d'évolutivité, de cohérence ou de rapport qualité-prix lorsque vous sélectionnez l'interface PostgreSQL.

En savoir plus sur les différences entre les dialectes PostgreSQL et Google SQL dans Spanner

Voici les grandes étapes à suivre:

  1. Supprimer les extensions spécifiques à Spanner des requêtes et des instructions LDD
  2. Migrer le schéma
  3. Migrer les données
  4. Migrer l'application

Considérations spécifiques à Spanner

L'interface PostgreSQL de Spanner est compatible avec les requêtes PostgreSQL prêtes à l'emploi. Par conséquent, la plupart des requêtes SQL exécutées sur une base de données Spanner en dialecte PostgreSQL ont le même comportement que les autres bases de données compatibles avec PostgreSQL. Avec cette approche, le nombre de modifications SQL et d'accès aux données requises pour déplacer une application d'une plate-forme à une autre est probablement faible. Le processus de portage est ainsi plus rapide, plus facile et moins sujet aux erreurs qu'une base de données de dialecte GoogleSQL similaire.

En plus de la compatibilité étendue avec PostgreSQL, l'interface PostgreSQL propose un certain nombre d'extensions spécifiques à Spanner. Si vous utilisez ces extensions dans vos applications, vous devrez les supprimer ou les mapper manuellement aux fonctionnalités PostgreSQL. Vous trouverez des exemples notables dans les sections Extensions de syntaxe de requête et Extensions de gestion de schéma (LDD).

Extensions de syntaxe des requêtes

L'interface PostgreSQL de Spanner fournit un certain nombre d'extensions spécifiques à Spanner. La plupart utilisent le préfixe spanner. pour l'identification. Dans le tableau suivant, nous listons ces extensions et les actions que vous devrez peut-être effectuer avant que la même application puisse s'exécuter sur une base de données PostgreSQL.

Type d'extension Extensions spécifiques Actions à prendre avant la migration
Fonctions spécifiques à Spanner Recherchez les fonctions précédées du préfixe spanner. et supprimez ces appels.
Extensions de type Supprimez la syntaxe VECTOR LENGTH ou envisagez d'utiliser pgvector.
Syntaxe des requêtes Aucune action n'est requise, car les indices sont représentés dans les commentaires.
Pour en savoir plus sur les considérations sur les performances, consultez la section Migration des requêtes.
Procédures système stockées Supprimez les appels à spanner.cancel_query().
Vous pouvez éventuellement remplacer les appels par un équivalent PostgreSQL.
Opérations SET/SHOW Peut être ignoré, car PostgreSQL ne dispose d'aucun paramètre intégré commençant par spanner.. Par conséquent, la définition de variables avec ce préfixe n'a aucun impact sur le comportement attendu.

Extensions de gestion des schémas (LDD)

Spanner propose une gamme d'extensions liées à la gestion des données, comme décrit sur la page Langage de définition de données (LDD).

Extension Actions à prendre avant la migration
Tables entrelacées
Colocalise les données associées de type "plusieurs à un" dans un espace de stockage physique, ce qui rend les jointures entre elles beaucoup plus efficaces. 		Supprimez la clause INTERLEAVE IN.
Horodatages de commit
Permet de stocker de manière atomique l'horodatage de commit d'une transaction dans une colonne. 		Remplacez SPANNER.COMMIT_TIMESTAMP par un type de code temporel PostgreSQL et gérez le paramétrage du code temporel dans votre application, ou supprimez cette colonne.
Récupération à un moment précis
Protège contre les suppressions ou les écritures accidentelles. 		Supprimez toutes les instructions LDD qui définissent spanner.version_retention_period.
Valeur TTL (Time To Live)
Permet de supprimer automatiquement les enregistrements en fonction de leur âge. 		Supprimez la clause TTL INTERVAL. Envisagez d'utiliser une cron ou une tâche planifiée pour supprimer régulièrement les éléments obsolètes. lignes.
Options de l'optimiseur
Définit des options pour minimiser le risque de régression des performances lorsque l'optimiseur de requêtes ou les statistiques changent. 		Supprimez les instructions DDL qui définissent les options de l'optimiseur.
Flux de modifications
Surveille et diffuse les modifications de données d'une base de données Spanner (insertions, mises à jour et suppressions) en temps quasi réel. 		Supprimez toutes les instructions LDD liées aux flux de modifications.
Leader par défaut
Vous permet de spécifier le leader de votre base de données dans les configurations birégionales et multirégionales.		 Supprimez toutes les instructions LDD qui définissent spanner.default_leader.
Partitionnement géographique
Vous permet de segmenter davantage et de stocker les lignes de votre table de base de données dans différentes configurations d'instance. 		Supprimez toutes les instructions LDD liées au géopartitionnement.
Séquences
Spanner n'est compatible qu'avec la séquence bit_reversed_positive.		 Remplacez bit_reversed_positive par une séquence disponible dans PostgreSQL.

Migration du schéma

Vous pouvez exporter un schéma de base de données en dialecte PostgreSQL dans la syntaxe PostgreSQL. Pour les bases de données configurées pour utiliser l'interface PostgreSQL, vous pouvez y parvenir avec psql à l'aide de PGAdapter, le proxy side-car qui vous permet d'utiliser des pilotes ou des bibliothèques clientes PostgreSQL standards pour vous connecter à Spanner:

psql -v ON_ERROR_STOP=1 \
  --host "$PGADAPTER_HOST" \
  --port "$PGADAPTER_PORT" \
  --dbname "$SPANNER_DATABASE" \
  -qAtX \
  -c "show database ddl"

Vous pouvez également utiliser la commande gcloud suivante pour générer le schéma en tant que script SQL compatible avec PostgreSQL:

gcloud spanner databases ddl describe databasename

Si la base de données utilise des extensions de schéma spécifiques à Spanner, comme celles décrites dans la section Extensions de gestion de schéma, elles sont listées lorsque vous exécutez cette commande. Vous devez les supprimer avant de migrer le schéma vers PostgreSQL.

Migration de données

L'interface PostgreSQL de Spanner est compatible avec les extensions COPY TO STDIN et STDOUT de PostgreSQL à l'aide de PGAdapter. Il s'agit d'une façon de charger des données dans Spanner et de les en extraire. Pour en savoir plus sur la commande COPY, consultez la documentation de l'outil de ligne de commande psql pour Spanner.

Ce script exporte de plus petites quantités de données (recommandé pour moins de 100 Go de données) depuis l'interface PostgreSQL de Spanner vers la nouvelle base de données PostgreSQL:

psql -h pgadapter-host -c "COPY $TABLE TO STDOUT BINARY" | \
psql -h postgresql-host -c "COPY $TABLE FROM STDIN BINARY"

Pour les tables plus volumineuses (100 Go de données ou plus), vous pouvez lancer une exportation Dataflow vers un modèle CSV.

Vous pouvez effectuer des migrations de données en temps réel à l'aide du connecteur Debezium Kafka pour transmettre des mises à jour Spanner dans PostgreSQL. Vous pouvez le personnaliser davantage si vous utilisez l'API Spanner Change Streams pour accéder directement aux flux de capture des données modifiées (CDC).

Migration des requêtes

L'interface PostgreSQL pour Spanner implémente une grande partie de la syntaxe, des fonctions et des opérateurs de requête PostgreSQL les plus courants.

Si vous utilisez des indices dans vos requêtes, vous n'avez pas besoin de réécrire vos requêtes, car les indices de requête sur Spanner sont définis dans des commentaires compatibles avec PostgreSQL:

SELECT s.FirstName, s.LastName,
 s.SingerInfo, a.AlbumTitle, a.Charts
FROM Singers AS s
LEFT OUTER JOIN/*@JOIN_METHOD=APPLY_JOIN*/ Albums AS a
 ON s.SingerId = a.SingerId;

Ces commentaires sont traités par le planificateur de requêtes de Spanner, mais une base de données PostgreSQL les ignore. Vous pouvez donc les inclure ou les supprimer.

Pour obtenir des performances optimales dans le nouvel environnement, les requêtes et le schéma de la base de données (tels que les index) peuvent nécessiter une optimisation. Nous vous recommandons d'exécuter des vérifications de référence pour le confirmer empiriquement.

Migration d'applications

En ce qui concerne la connectivité à partir de vos applications, votre stratégie de migration dépend des choix initiaux effectués lors de la configuration de votre application pour utiliser Spanner, par exemple si vous utilisez des pilotes PostgreSQL, des pilotes Spanner ou des bibliothèques clientes Spanner. Cette section décrit les considérations à prendre en compte pour chaque option.

Pilotes PostgreSQL

Spanner est compatible avec les clients PostgreSQL courants à l'aide de PGAdapter, un proxy léger qui traduit le protocole de communication PostgreSQL en API de requête gRPC de bas niveau de Spanner. Si vous utilisez l'une de ces options, le changement vers une autre cible PostgreSQL implique de mettre à jour votre chaîne de connexion pour qu'elle pointe directement vers la nouvelle base de données PostgreSQL au lieu du proxy PGAdapter. Cette approche offre de bonnes performances et une compatibilité élevée. Elle est donc adaptée lorsque la portabilité est une priorité. La plupart des requêtes exécutées sur l'interface PostgreSQL de Spanner fonctionnent de la même manière dans d'autres environnements PostgreSQL. Cependant, l'inverse n'est pas nécessairement vrai : PostgreSQL est compatible avec la syntaxe et les fonctionnalités que Spanner n'est pas.

Pilotes Spanner

Ces pilotes sont des implémentations spécifiques à Spanner pour les langages et frameworks d'applications courants. Par exemple, le pilote JDBC (Java) Spanner implémente la même API que le pilote JDBC PostgreSQL. Les applications qui utilisent le pilote JDBC Spanner peuvent donc mettre à jour leur processus de compilation pour associer le pilote PostgreSQL intégré équivalent lorsqu'elles souhaitent exécuter l'application avec PostgreSQL. Cette option est préférable si vous utilisez déjà Spanner ou si vous recherchez une solution performante qui exploite les fonctionnalités de Spanner, comme l'API Mutations, qui ne serait pas exposée à l'aide d'un pilote PostgreSQL intégré. Si vous avez besoin d'une compatibilité totale avec les pilotes intégrés et la portabilité des valeurs, envisagez plutôt d'utiliser les pilotes intégrés de PostgreSQL avec PGAdapter pour assurer un certain niveau de portabilité des applications.

Pour en savoir plus, consultez Pilotes et ORM PostgreSQL.

Bibliothèques clientes Spanner

Spanner propose également diverses bibliothèques clientes idiomatiques qui offrent un accès direct à Spanner sans implémenter ni passer par une interface standardisée PostgreSQL. Ces clients offrent un accès maximal aux fonctionnalités spécifiques à Spanner, mais ne sont pas compatibles avec les API des pilotes PostgreSQL. Ces options offrent le niveau de performances le plus élevé, mais sont moins portables que les options mentionnées ci-dessus.

Étape suivante