Migrer de PostgreSQL vers Spanner (dialecte PostgreSQL)

Cette page explique comment migrer une base de données PostgreSQL Open Source (désormais appelée simplement PostgreSQL) Base de données Spanner PostgreSQL (désormais appelée Spanner).

Pour en savoir plus sur migrer vers Spanner et le dialecte GoogleSQL, consultez la page Migrer depuis PostgreSQL à Spanner (dialecte GoogleSQL).

Contraintes de migration

Cloud Spanner utilise certains concepts différemment des autres outils de gestion de base de données d'entreprise. Par conséquent, vous devrez peut-être ajuster l'architecture de votre application pour tirer pleinement parti de ses fonctionnalités. Vous devrez peut-être également compléter Cloud Spanner avec d'autres services Google Cloud pour répondre à vos besoins.

Procédures et déclencheurs stockés

Cloud Spanner n'est pas compatible avec l'exécution de code utilisateur au niveau de la base de données. Par conséquent, dans le cadre de la migration, la logique métier mise en œuvre par les procédures et les déclencheurs stockés au niveau de la base de données doit être déplacée dans l'application.

Séquences

Spanner recommande d'utiliser l'UUID version 4 comme méthode par défaut pour générer clés primaires. La fonction GENERATE_UUID() (GoogleSQL, PostgreSQL) renvoie des valeurs UUID Version 4 représentées par le type STRING.

Si vous devez générer des valeurs entières, Spanner accepte séquences positives inversées sur les bits (GoogleSQL, PostgreSQL), qui produisent des valeurs qui répartissent uniformément sur l’espace numérique positif de 64 bits. Vous pouvez utilisez ces numéros pour éviter les problèmes de hotspotting.

Pour en savoir plus, consultez la section Stratégies de valeur par défaut de clé primaire.

Contrôle des accès

Spanner permet un contrôle précis des accès au niveau de la table et de la colonne. à l'échelle du projet. Il n'est pas possible de contrôler précisément les accès pour les vues. Pour plus en savoir plus, consultez la section À propos du contrôle ultraprécis des accès.

Processus de migration

La migration implique les tâches suivantes :

• Mapper un schéma PostgreSQL sur Spanner
• Traduire des requêtes SQL
• Créer une instance, une base de données et un schéma Spanner
• Refactoriser l'application pour qu'elle fonctionne avec votre base de données Spanner
• Effectuer la migration des données
• Vérifier le nouveau système et le passer à l'état de production

Étape 1: Mapper votre schéma PostgreSQL sur Spanner

La première étape pour migrer une base de données PostgreSQL Open Source vers Spanner détermine les modifications à apporter au schéma.

Clés primaires

Dans Spanner, chaque table devant stocker plusieurs lignes doit ont une clé primaire composée d'une ou plusieurs colonnes de la table. Votre tableau clé primaire identifie de manière unique chaque ligne d'une table et Spanner utilise la clé primaire pour trier les lignes du tableau. Spanner étant il est important de choisir une génération de clé primaire qui s'adapte bien à la croissance de vos données. Pour en savoir plus, consultez les stratégies de migration de clés primaires qui que nous recommandons.

Notez qu'après avoir défini votre clé primaire, vous ne pouvez plus ajouter ni supprimer colonne de clé primaire, ou modifier une valeur de clé primaire par la suite sans supprimer ni supprimer en recréant la table. Pour en savoir plus sur la manière de désigner votre clé primaire, voir Schéma et modèle de données – principaux clés.

Index

PostgreSQL index B-tree sont semblables aux indices secondaires dans Spanner. Dans une base de données Spanner, vous utilisez des index secondaires pour d'indexer les colonnes fréquemment recherchées pour améliorer les performances et de remplacer UNIQUE contraintes spécifiées dans vos tables. Par exemple, imaginons que votre DDL PostgreSQL affiche l'instruction suivante :

 CREATE TABLE customer (
    id CHAR (5) PRIMARY KEY,
    first_name VARCHAR (50),
    last_name VARCHAR (50),
    email VARCHAR (50) UNIQUE
 );

Vous devez utiliser cette instruction dans votre LDD Spanner:

CREATE TABLE customer (
   id VARCHAR(5) PRIMARY KEY,
   first_name VARCHAR(50),
   last_name VARCHAR(50),
   email VARCHAR(50)
   );

CREATE UNIQUE INDEX customer_emails ON customer(email);

Vous pouvez trouver les index de toutes vos tables PostgreSQL en exécutant la commande \di dans psql.

Une fois que vous avez déterminé les index dont vous avez besoin, ajoutez des instructions CREATE INDEX pour les créer. Suivez les instructions fournies sur la page Index secondaires.

Spanner implémente les index sous forme de tables, de sorte que l'indexation est monotone des colonnes croissantes (comme celles contenant des données TIMESTAMP) peuvent provoquer un hotspot. Voir Ce que les administrateurs de base de données doivent savoir sur Spanner, partie 1: Clés et index pour en savoir plus sur les méthodes permettant d'éviter les hotspots.

Spanner implémente les index secondaires de la même manière que les tables, Les valeurs de colonne à utiliser comme clés d'index auront donc les mêmes contraintes comme clés primaires des tableaux. Cela signifie également que les index ont la même garantie de cohérence que les tables Spanner.

Les recherches de valeurs utilisant des index secondaires sont en réalité les mêmes que les requêtes avec jointure de table. Vous pouvez améliorer les performances des requêtes utilisant des index en stockant des copies des valeurs de colonne de la table d'origine dans l'index secondaire à l'aide de la méthode INCLUDE, ce qui en fait une index de couverture.

L'optimiseur de requêtes de Cloud Spanner n'utilise automatiquement un index secondaire que lorsque l'index stocke lui-même toutes les colonnes interrogées (une requête couverte). Pour forcer l'utilisation d'un index lors de l'interrogation des colonnes de la version d'origine vous devez utiliser Directive FORCE INDEX dans l'instruction SQL, par exemple:

SELECT *
FROM MyTable /*@ FORCE_INDEX=MyTableIndex */
WHERE IndexedColumn=$1;

Voici un exemple d'instruction DDL créant un index secondaire pour la table Albums :

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Si vous créez des index supplémentaires après le chargement de vos données, le remplissage de l'index peut prendre un certain temps. Nous vous recommandons de limiter la fréquence à laquelle vous les ajoutez à une moyenne de trois par jour. Pour obtenir plus de conseils sur la création d'index secondaires, consultez la section Index secondaires. Pour en savoir plus sur les limitations relatives à la création d'index, consultez la section Mises à jour de schémas.

Vues

Les vues Spanner sont en lecture seule. Ils ne peuvent pas être utilisés pour insérer, mettre à jour ou supprimer des données. Pour en savoir plus, consultez la section Vues.

Colonnes générées

Spanner accepte les colonnes générées. Voir Créer et gérer des colonnes générées pour la syntaxe différences et restrictions.

Entrelacement de tables

Cloud Spanner propose une fonctionnalité dans laquelle vous pouvez définir deux tables comme ayant une relation parent/enfant de un à plusieurs. Cette fonctionnalité entrelace les lignes de données enfants à côté de leur ligne parente dans le stockage. L'entrelacement signifie que les tables sont préjointes, ce qui permet d'améliorer l'efficacité de la récupération des données lorsque le parent et les enfants sont recherchés ensemble.

La clé primaire de la table enfant doit commencer par la ou les colonnes de clé primaire de la table parente. Du point de vue de la ligne enfant, la clé primaire de la ligne parente est appelée clé étrangère. Vous pouvez définir jusqu'à six niveaux de relations parent-enfant.

Vous pouvez définir des actions ON DELETE pour les tables enfants afin de déterminer ce qui se passe lorsque la ligne parente est supprimée: soit toutes les lignes enfants sont supprimées, soit la suppression de la ligne parente est bloquée lignes enfants existent.

Voici un exemple de création d'une table Albums entrelacée dans la table parente Singers définie précédemment :

CREATE TABLE Albums (
 SingerID      bigint,
 AlbumID       bigint,
 AlbumTitle    varchar,
 PRIMARY KEY (SingerID, AlbumID)
 )
 INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

Pour en savoir plus, consultez la page Créer des tables entrelacées.

Types de données

Le tableau suivant répertorie les types de données PostgreSQL Open Source qui n'est pas compatible avec l'interface PostgreSQL.

Remarque :HarbourBridge peut effectuer automatiquement certaines des conversions figurent dans la colonne Utiliser à la place. Pour en savoir plus, consultez HarbourBridge: évaluation et migration de Spanner.

Type de données	Utiliser à la place
bigserial,serial8	bigint, int8
bit [ (n) ]	-
bit variable [ (n) ], varbit [ (n) ]	-
box	-
caractère [ (n) ], char [ (n) ]	caractère variable
cidr	texte
cercle	-
inet	texte
entier, int4	bigint, int8
intervalle [champs] [ (p) ]	bigint
json	jsonb
line	-
lseg	-
macaddr	texte
argent	numérique, décimal
chemin d'accès	-
pg_lsn	-
point	-
polygon	-
realfloat4	double précision, float8
smallint, int2	bigint, int8
smallserial, serial2	bigint, int8
série, série4	bigint, int8
time [ (p) ] [ sans fuseau horaire ]	Texte, au format HH:MM:SS.sss
heure [ (p) ] avec fuseau horairetimetz	au format HH:MM:SS.sss+ZZZZ. Ou utilisez deux colonnes.
timestamp [ (p) ] [ sans fuseau horaire ]	texte ou timestamptz
tsquery	-
tsvector	-
txid_snapshot	-
uuid	Texte ou bytea
xml	texte

Étape 2: Traduisez les requêtes SQL

Spanner intègre de nombreux modèles Open Source de PostgreSQL fonctions disponibles pour réduire la charge liée aux conversions.

Les requêtes SQL peuvent être profilées à l'aide de la page Spanner Studio la console Google Cloud pour exécuter la requête. En général, les requêtes qui effectuent des analyses complètes de tables sur des tables volumineuses sont très coûteuses et doivent être utilisées avec parcimonie. Pour en savoir plus sur l'optimisation des requêtes SQL, consultez la Bonnes pratiques SQL dans la documentation Google Cloud.

Étape 3: Créer l'instance, la base de données et le schéma Spanner

Créer l'instance et une base de données dans PostgreSQL dialecte. Créez ensuite votre schéma à l'aide de la définition de données PostgreSQL (LDD).

Utilisez pg_dump pour créer des instructions LDD qui définissent les objets dans votre base de données PostgreSQL, puis modifiez les instructions comme décrit dans le dans les sections précédentes. Après avoir mis à jour les instructions LDD, utilisez-les pour créer votre base de données dans l'instance Spanner.

Pour en savoir plus, consultez les pages suivantes :

• Créer et gérer des instances
• Créer et gérer des bases de données
• À propos des schémas

Étape 4: Refactoriser l'application

Ajouter une logique d'application pour tenir compte du schéma modifié et du code SQL révisé et de remplacer la logique résidente de la base de données, comme les procédures et les déclencheurs.

Étape 5: Migrez vos données

Il existe deux façons de migrer vos données:

• En utilisant Harbourbridge.

  Harbourbridge permet la migration de schémas et de données. Vous pouvez importer un fichier pg_dump ou CSV, ou importez-les via une connexion directe à la base de données PostgreSQL Open Source.

• À l'aide de la commande COPY FROM STDIN

  Pour en savoir plus, consultez Commande COPY pour importer des données.