Sqlmed on Carnet de découvertes

Un assistant pour copier les données distantes

Florent Jardin — Tue, 28 May 2024 00:00:00 +0000

Lors de la dernière PGSession 16, j’ai rédigé et animé un atelier de trois heures au sujet de la migration vers PostgreSQL à l’aide des Foreign Data Wrappers, ou FDW. Ce fut notamment l’occasion de présenter au grand public, l’extension db_migrator pour laquelle j’ai dédié un article sur ce blog.

Au cours de cet atelier, nous pouvons constater que la copie des données avec l’extension db_migrator n’est pas parfaitement prise en charge. En effet, bien qu’il existe une fonction de bas niveau pour répartir sur plusieurs processus le transfert table à table, de nombreuses situations devront exiger de rédiger un grand nombre de requêtes SQL pour se tirer d’affaire. Au cours des mois qui suivirent, je me suis attelé à la conception d’un assistant écrit en PL/pgSQL dont le but est de simplifier la génération de ces requêtes.

Transfert des données sans assistant

Il n’y a pas de magie dans l’opération de copie des données à travers un Foreign Data Wrapper. Tout se résume à une série de requêtes INSERT qui doivent être exécutées dans un ordre prédéfini. Prenons les 16 tables du modèle de données très connu « Sakila » (disponible à cette adresse), pour illustrer le besoin de génération des requêtes de transfert.

Pour la pédagogie de cet article, je dispose d’une base de données PostgreSQL avec les deux schémas suivants que j’utiliserai dans mes démonstrations :

mysql : le schéma source contenant la définition des tables externes via l’extension mysql_fdw ;
public : le schéma cible où les données seront copiées.

Chaque table externe fait l’objet d’une étude rapide pour obtenir la bonne correspondance de type de colonne, et leur définition est conservée dans un fichier SQL à destination des équipes du projet. Par exemple, la table externe rental est définie comme suit :

CREATE FOREIGN TABLE mysql.rental (
 rental_id integer NOT NULL,
 rental_date timestamp without time zone NOT NULL,
 inventory_id integer NOT NULL,
 customer_id smallint NOT NULL,
 return_date timestamp without time zone,
 staff_id smallint NOT NULL,
 last_update timestamp without time zone NOT NULL
)
SERVER sakila_mysql
OPTIONS (
 dbname 'sakila',
 table_name 'rental'
);

Lors de la création de la table public.rental qui accueillera les données, il est opportun de décider si nous souhaitons mettre en place un partitionnement, chose que db_migrator est capable d’identifier et de mettre en place. Pour l’exemple, je reprends la structure stricte à l’aide de la syntaxe CREATE TABLE LIKE pour créer toutes mes tables cibles.

CREATE TABLE public.actor (LIKE mysql.actor);
CREATE TABLE public.address (LIKE mysql.address);
...

Avant même de mettre en place un générateur de requêtes INSERT, il est aisé d’entrevoir la forme de celles-ci. Chaque ligne de la table externe sera lue à travers un SELECT global, puis insérée dans la table cible. Le script de migration contient ainsi 16 instructions, une pour chaque table.

-- insert.sql
INSERT INTO public.actor SELECT * FROM mysql.actor;
INSERT INTO public.address SELECT * FROM mysql.address;
...
INSERT INTO public.store SELECT * FROM mysql.store;

Pour bénéficier de plusieurs processus, j’apprécie l’outil xargs qui permet de distribuer chaque ligne du fichier insert.sql sur une nouvelle session psql. Cette technique était présentée dans l’atelier de février, notamment pour paralléliser la construction des index et des clés primaires, définis dans un fichier SQL.

$ xargs -P 4 -a insert.sql -d '\n' -I % sh -c 'psql -c "%"'
INSERT 0 16
INSERT 0 603
...
INSERT 0 16044

C’est un peu rude, ça manque de verbosité, les requêtes SQL sont statiques. Bref, voyons la partie suivante pour découvrir ce que mon assistant peut apporter.

Démonstration de l’assistant

Contrairement à mes autres projets en PL/pgSQL, cet assistant n’est pas une extension et s’installe comme un vulgaire script. Une fois téléchargé, il suffit de l’invoquer sur la base de données de votre choix avec la commande suivante :

$ psql -d sakila -f fdw-assistant.sql

Le schéma par défaut se nomme assistant et contient une table de configuration sobrement appelée config. Pour chaque table à migrer, il suffit d’insérer une unique ligne qui servira d’élément de départ à la génération des requêtes de migration des données. On y retrouve dans la version actuelle les paramètres suivants :

source : la table externe qui contient les données à copier ;
target : la table cible où les données seront copiées ;
pkey : la colonne de clé primaire de la table cible ;
priority : les valeurs les plus faibles définissent les tables à traiter en premier ;
parts : le nombre de processus à lancer pour la copie des données ;
trunc : une option pour vider la table cible avant de copier les données ;
condition : une clause WHERE pour filtrer les données à copier ;
batchsize : le nombre de lignes à copier avant de réaliser un COMMIT intermédiaire.

Pour initialiser cette table en première intention, il est nécessaire de connaître a minima les colonnes de clé primaire de chaque table distante. En reportant les informations du diagramme relationnel de la base Sakila, nous pouvons remplir la table config de la façon suivante :

INSERT INTO assistant.config (source, target, pkey)
VALUES
 ('mysql.actor', 'public.actor', 'actor_id'),
 ('mysql.address', 'public.address', 'address_id'),
 ...
 ('mysql.store', 'public.store', 'store_id');

Pour chaque transfert, nous indiquons la table source et la table cible, ainsi que la colonne de clé primaire. Cette dernière est requise pour trier les lignes, découper le transfert en plusieurs lots (batchs) et redémarrer le transfert en cas d’interruption.

À l’aide de cette configuration, nous pouvons passer à la planification. Les tables stage et job sont alimentées avec de nouveaux éléments qui serviront au pilotage et au suivi des différents transferts à déclencher.

SELECT * FROM assistant.plan();

 target | invocation
---------------+--------------------------
 customer | CALL assistant.copy(1);
 address | CALL assistant.copy(2);
 ...
(16 rows)

Une vue nommée report permet de suivre l’avancement des différentes étapes en joignant les tables stage et job. Elle donne notamment des éléments très utiles pour suivre l’avancement et le débit des transferts.

SELECT target, state, rows FROM assistant.report WHERE stage_id = 1;

 target | state | rows
---------------+---------+------
 rental | pending | 0
 actor | pending | 0
 ...
(16 rows)

Les lignes retournées par la commande plan() peuvent alors être invoquées les unes après les autres avec la méta-commande \gexec de psql, ou alors en reprenant la technique du fichier et la distribution des requêtes avec xargs.

L’appel à la méthode copy() se charge de construire l’instruction INSERT relative à la copie des données d’une table distante vers une table locale. Par exemple, pour la table customer, le résultat de l’appel sera le suivant :

CALL assistant.copy(1);

NOTICE: Executing: TRUNCATE public.customer
NOTICE: Executing: SELECT count(customer_id) FROM mysql.customer
 WHERE customer_id > 0
NOTICE: Executing: INSERT INTO public.customer
 SELECT customer_id, store_id, first_name, last_name, email,
 address_id, active, create_date, last_update
 FROM mysql.customer
 WHERE customer_id > 0 ORDER BY customer_id
CALL

À l’issue du transfert, la vue report nous fait un résumé de l’opération.

SELECT * FROM assistant.report
 WHERE stage_id = 1 AND target = 'public.customer'::regclass;

-[ RECORD 1 ]-------------------------
stage_id | 1
target | public.customer
job_start | 2024-05-28 10:19:18.334917
state | completed
rows | 599
total | 599
elapsed | 00:00:00.081273
rate | 7370.22
progress | 1.00
eti | 00:00:00
eta | 2024-05-28 10:19:18.334917

Distribution sur plusieurs processus

Au fur et à mesure de la conception de l’assistant, j’ai éprouvé le besoin d’enrichir les requêtes sous-jacentes pour répondre à d’autres cas d’usage, récurrents dans le domaine de la migration de données. Parmi ceux-ci, on y retrouve la capacité de répartir les lignes d’une même table sur plusieurs sessions, chacune disposant d’une clause WHERE basé sur le résultat de la division euclidienne (modulo) de la clé primaire.

Pour activer cette fonctionnalité, il suffit de renseigner le paramètre parts dans la table config. Par exemple, pour la table film, nous pouvons définir :

UPDATE assistant.config SET parts = 4 WHERE target = 'public.film'::regclass;

Cette configuration prend effet lors de la prochaine planification. L’appel à la méthode plan() insère alors quatre lignes dans la table job pour la table film, chacune rattachée à une valeur comprise entre 0 et 3. La colonne condition est alors enrichie pour les lignes de la table task en vue de l’étape suivante.

SELECT invocation FROM assistant.plan('{public.film}');

 invocation
--------------------------
 CALL assistant.copy(17);
 CALL assistant.copy(18);
 CALL assistant.copy(19);
 CALL assistant.copy(20);
(4 rows)

SELECT job_id, job.target, state, part, condition
 FROM assistant.job JOIN assistant.task USING (job_id)
 WHERE stage_id = 2;

 job_id | target | state | part | condition
--------+--------+---------+------+-----------------
 17 | film | pending | 0 | film_id % 4 = 0
 18 | film | pending | 1 | film_id % 4 = 1
 19 | film | pending | 2 | film_id % 4 = 2
 20 | film | pending | 3 | film_id % 4 = 3

Lors de l’appel à la méthode copy(), l’assistant construit les requêtes INSERT sur la base des conditions précédemment définies. Par exemple, pour la première partie de la table film, la trace indique les requêtes INSERT qui ont été générées.

CALL assistant.copy(17);

NOTICE: Executing: TRUNCATE public.film
NOTICE: Executing: SELECT count(film_id) FROM mysql.film
 WHERE film_id > 0 AND film_id % 4 = 0
NOTICE: Executing: INSERT INTO public.film
 SELECT film_id, title, description, release_year,
 language_id, original_language_id, rental_duration,
 rental_rate, length, replacement_cost, rating,
 special_features, last_update
 FROM mysql.film WHERE film_id > 0 AND film_id % 4 = 0
 ORDER BY film_id
CALL

L’opération TRUNCATE intervient uniquement pour la session dont la valeur de part est égale à 0. Dans le cas nominal, cette session est lancée avant toutes les autres pour respecter le comportement attendu dans la configuration avec la colonne trunc (true par défaut).

L’intérêt évident de cette méthode est d’obtenir le meilleur débit d’insertion pour une table donnée, en reposant sur la puissance d’extraction du serveur distant et la capacité d’écriture du serveur local. Le débit peut être consulté avec la vue report, notamment pour comparer deux chargements pour une même table, comme l’exemple de la table film. La colonne rate est exprimée en nombre de lignes par seconde.

SELECT stage_id, target, state, rate FROM assistant.report
 WHERE target = 'public.film'::regclass;

 stage_id | target | state | rate
----------+-------------+-----------+----------
 1 | public.film | completed | 19162.59
 2 | public.film | completed | 51389.37

Reprise après interruption

La capacité de pouvoir relancer une copie par lot en cas d’interruption est une des raisons pour lesquelles la clé primaire doit être renseignée dans la configuration. L’assistant s’appuie sur la dernière valeur de clé primaire extraite (à l’aide d’une clause RETURNING) pour connaître le prochain point de reprise. Dans la conception de cette fonctionnalité, il m’a fallu arbitrer sur les limitations qu’impose ce mécanisme.

Les clés primaires ne doivent pas être composées, car la clause RETURNING ne peut retourner qu’une seule valeur ;
Les tables dont la clé primaire est composée ne peuvent pas bénéficier du traitement par lot, et donc de la reprise après interruption ;
Les données sont systématiquement triées lors de l’extraction, même si le traitement par lot n’est pas activé ;
La colonne de la clé primaire doit être de type numérique.

L’activation d’un traitement par lot consiste à mettre à jour la colonne batchsize de la table de configuration. Prenons l’exemple de la table rental :

UPDATE assistant.config SET batchsize = 1000
 WHERE target = 'public.rental'::regclass;

SELECT invocation FROM assistant.plan('{public.rental}');

 invocation
--------------------------
 CALL assistant.copy(21);
(1 row)

Le transfert des données de la table rental est alors découpé en lots de 1000 lignes. Il est bien sûr possible de combiner cette technique avec la parallélisation, la clause WHERE réalisera l’essentiel du travail de répartition pour empêcher que la même ligne soit exportée deux fois.

CALL assistant.copy(21);

TRUNCATE public.rental
SELECT count(rental_id) FROM mysql.rental WHERE rental_id > 0
INSERT INTO public.rental SELECT rental_id, ...
 FROM mysql.rental WHERE rental_id > 0 ORDER BY rental_id LIMIT 1000
...
...
INSERT INTO public.rental SELECT rental_id, ...
 FROM mysql.rental WHERE rental_id > 16005 ORDER BY rental_id LIMIT 1000
INSERT INTO public.rental SELECT rental_id, ...
 FROM mysql.rental WHERE rental_id > 16049 ORDER BY rental_id LIMIT 1000
CALL

Dès qu’une requête ne retourne plus aucune ligne, l’assistant considère que le transfert est terminé. La table job est mise à jour à chaque itération pour suivre la dernière valeur de la séquence de clé primaire.

SELECT target, lastseq FROM assistant.job
 WHERE stage_id = 3 AND target = 'public.rental'::regclass;

 target | lastseq
---------------+---------
 public.rental | 16049

En cas d’interruption, il est possible de relancer le transfert en appelant la méthode copy() avec le même identifiant de tâche. L’assistant se charge de reprendre le transfert à partir de la dernière valeur de clé primaire connue.

CALL assistant.copy(21);

NOTICE: Executing: SELECT count(rental_id) FROM mysql.rental
 WHERE rental_id > 16049
NOTICE: Executing: INSERT INTO public.rental SELECT rental_id, ...
 FROM mysql.rental WHERE rental_id > 16049
 ORDER BY rental_id LIMIT 1000
CALL

Conclusion

La conception d’un tel outil était un petit défi personnel dans la droite lignée de mes recherches autours de la migration vers PostgreSQL avec l’aide exclusive des Foreign Data Wrappers. Ma principale source d’inspiration reste le projet Ora2Pg, l’un des outils open-source le plus complet à ce jour.

J’ai conscience des limites techniques de cet assistant, et du bricolage qu’il reste à mettre en place pour faciliter la vie d’un consultant comme moi. Dans un autre article, j’aimerais présenter un autre outil nommé dispatch que je maintiens depuis quelque temps et avec lequel je réponds aux questions d’orchestration et traçabilité des étapes de la migration.

En prenant un peu de recul, les concepts de base sont là, n’importe quel autre outil dans d’autres langages pourrait parfaitement émerger et enrichir l’écosystème open-source dans la quête de la migration vers PostgreSQL.

En route vers la liberté avec db_migrator

Florent Jardin — Fri, 28 Jul 2023 00:00:00 +0000

J’ai passé plusieurs semaines ces derniers mois à contribuer à l’extension db_migrator. Rédigée uniquement en PL/pgSQL, elle permet de migrer les schémas et les données d’un système de bases de données vers PostgreSQL à l’aide des données externes que j’avais déjà présentées il y a quelques années.

Dans cet article, je présente le fonctionnement de l’outil, sa philosophie et la raison d’être que je lui ai trouvée, alors même qu’il rejoint l’écosystème des projets libres déjà bien installés dans le paysage de la migration. Que vaut-il aux côtés d’Ora2Pg ou de pgloader ?

db_migrator entre dans l’arène

Mon intérêt pour ce projet remonte à décembre dernier, alors qu’un collègue de chez Dalibo nous laissait en héritage un outil similaire avec lequel il lui était possible de copier les données d’instances Oracle ou Sybase à l’aide de la technologie des Foreign Data Wrappers (FDW). Bien que cet outil soit resté en alpha, beaucoup de bonnes idées y ont été expérimentées en interne.

La promesse des FDW réside dans le respect de la norme SQL/MED, à savoir qu’une instance PostgreSQL puisse s’interfacer sur un autre système de stockage et en manipuler les données à travers les tables externes avec de simples requêtes SQL. Ainsi, pour peu qu’une communauté ait développé le wrapper, il est possible de consulter un catalogue distant, reproduire la structure des tables, ses relations et ses contraintes, et de rapatrier les données vers PostgreSQL.

Et db_migrator entre dans l’arène.

Rendue publique en novembre 2019 par Laurenz Albe, connu pour sa contribution active sur PostgreSQL depuis des décennies et également pour le développement de oracle_fdw, l’extension se présente comme un outil générique avec lequel il faut employer des plugins pour la prise en charge des FDW. Il est aisé d’en créer de nouveaux, comme j’ai pu m’en rendre compte avec le plugin mysql_migrator, écrit en quelques jours, grâce à la documentation très complète de l’API des plugins.

Après avoir installé les extensions avec make install ainsi que le FDW du bon système, il est nécessaire de créer les objets dans la base de données qui va contenir les futurs schémas et leurs données.

CREATE EXTENSION mysql_fdw;
CREATE EXTENSION mysql_migrator CASCADE;

CREATE SERVER mysql FOREIGN DATA WRAPPER mysql_fdw
 OPTIONS (host 'mysql_db', fetch_size '1000');
CREATE USER MAPPING FOR PUBLIC SERVER mysql
 OPTIONS (username 'root', password 'password');

L’opération de migration peut être réalisée en une seule commande pour les cas les plus simples (pas de procédure stockée, ni de types de colonnes exotiques) avec la méthode db_migrate(). Sinon, en plusieurs étapes, s’il est nécessaire de faire des ajustements comme le changement du type de colonne ou le retrait d’une table dans le schéma cible.

Lors du développement de l’extension mysql_migration, je suis parti de la base d’exemple Sakila fournie par MySQL afin d’avoir une complexité exhaustive. La première étape consiste à créer deux schémas internes, l’un avec des tables externes fournies par le plugin, l’autre avec des tables de catalogue que l’on peut éditer avant que l’extension ne poursuive la migration.

SELECT db_migrate_prepare(
 plugin => 'mysql_migrator',
 server => 'mysql',
 only_schemas => '{sakila}'
);

Cette partie peut être relativement longue, puisqu’elle va permettre de rapatrier le modèle de données, que j’appelle le catalogue, sous la forme de plusieurs tables qui décrivent la structure des tables, le nom des colonnes ou les contraintes qui leur sont associées. L’extension importe également les sources de toutes les procédures stockées, les fonctions, les vues, mais ne réalise pas leur conversion en PL/pgSQL (vous ne vous rendez pas compte du travail que cela représente).

Dans le cas de la migration de la base Sakila, il est nécessaire de faire plusieurs modifications du catalogue. Comme le reste avec cette extension, toute la préparation se réalise en SQL, ce qui rend facile l’automatisation avec un unique script en guise de configuration.

/* exclude bytea columns from migration */
DELETE FROM pgsql_stage.columns WHERE type_name = 'bytea';

/* quote character expression */
UPDATE pgsql_stage.columns
 SET default_value = quote_literal(default_value)
 WHERE NOT regexp_like(default_value, '^\-?[0-9]+$')
 AND default_value <> 'CURRENT_TIMESTAMP';

/* disable view migration */
UPDATE pgsql_stage.views SET migrate = false;

On pourrait bien sûr aller plus loin, comme réinjecter la définition des vues réécrites dans la table pgsql_stage.views ou activer la migration des procédures en changeant la colonne migrate de la table pgsql_stage.functions. Mais progressons avec l’étape suivante.

SELECT db_migrate_mkforeign(
 plugin => 'mysql_migrator',
 server => 'mysql'
);

SELECT db_migrate_tables(
 plugin => 'mysql_migrator'
);

La première méthode db_migrate_mkforeign() va se charger de créer les schémas et les séquences, puis les tables étrangères avec les colonnes au regard des ajustements précédents. Ensuite, l’étape la plus cruciale, on exécute la fonction db_migrate_tables() : les tables vierges sont créées avec leurs partitions si besoin, et pour chacune d’entre elles, débute alors la copie des données avec l’instruction INSERT INTO SELECT *.

Les autres objets, tels que les index ou les contraintes, disposent de leur propre méthode. Il est nécessaire de créer les fonctions avant ces derniers si vous êtes confronté à des index fonctionnels ou que sais-je.

SELECT db_migrate_functions(plugin => 'mysql_migrator');
SELECT db_migrate_triggers(plugin => 'mysql_migrator');
SELECT db_migrate_views(plugin => 'mysql_migrator');
SELECT db_migrate_indexes(plugin => 'mysql_migrator');
SELECT db_migrate_constraints(plugin => 'mysql_migrator');

Il se pourrait que ce mécanisme change à l’avenir, notamment si je parviens à concrétiser cette issue qui permettrait de découper les méthodes db_migrate_*() en de plus petites étapes.

La fin de la migration consiste à supprimer les schémas temporaires dans lesquels se trouvaient les tables du catalogue.

SELECT db_migrate_finish();

Raison d’être de l’extension

Comme je le disais en introduction, c’est assez surprenant de voir un nouvel outil de migration émerger en 2023 (la version 1.0.0 est sortie en janvier avec mon patch sur l’ajout du partitionnement). Dans le paysage open-source, nous pouvons parler d’Ora2Pg qui a sorti en juillet sa version 24.0 avec le support de SQL Server ou bien de pgloader qui a une excellente réputation.

De très nombreux projets sont listés sur le wiki communautaire. Certains sont spécialisés pour un seul système, d’autres en migrent plusieurs. Une très grande majorité d’entre eux sont propriétaires ou n’ont plus de contribution récente. La plupart sont des boîtes noires et leur documentation peut paraître cryptique, voire quasi inexistante.

L’écosystème est riche, je ne prétends pas tous les connaître, mais j’ai une intuition que je me forge depuis quelques années. L’économie mondiale est en surchauffe. Certaines sociétés se portent bien, d’autres font des coupes budgétaires. La transition vers un système libre et sans licence commerciale comme PostgreSQL est toujours d’actualité, peut-être même plus urgente aujourd’hui en comparaison à la décennie qui vient de s’écouler.

Et pourtant, avec mes lunettes de DBA, je ne me satisfais pas encore des outils qui existent. J’aimerais qu’il y ait une nouvelle alternative, quelque chose d’universel et à portée de tout le monde. Si je me tourne aujourd’hui vers db_migrator, ce serait pour les principaux atouts suivants :

Une implémentation bas niveau au plus près de l’instance : avec le PL/pgSQL comme langage exclusif. Cela n’aurait pas été possible bien sûr sans le développement prolifique des Foreign Data Wrappers pour un grand nombre de systèmes ;
Une très grande flexibilité de configuration : puisque les ajustements se font avec des requêtes UPDATE ou DELETE sur le catalogue. Pour peu que l’on soit à l’aise avec le modèle de ce dernier, il devient facile de changer un comportement sans consulter une documentation technique sur les options qui se présentent à nous ;
Une liberté dans l’orchestration : à ce jour, les exécutions sont déclenchées de façon séquentielle pour les index et les contraintes, mais l’architecture de l’outil pourrait permettre que des outils externes soient responsables de consommer les résultats de l’extension et de déclencher les opérations en parallèle ;
Les plugins sont libres d’enrichir la migration : si une opération n’est pas générique, il est tout à fait possible de fournir une méthode supplémentaire à l’aide du plugin. C’est le cas de la copie incrémentale (et ses fonctions de réplication) du plugin ora_migrator ou bien la conversion des auto-incréments en colonnes d’identité avec le plugin mysql_migrator.

Le chemin vers la liberté me semble encore long pour prétendre faire la moitié de ce que propose déjà Ora2Pg, à commencer par la conversion automatique qui n’est pas du tout à l’ordre du jour. Mais avec de petites avancées, régulières et réfléchies, qui sait ?

Migrer vers PostgreSQL

Florent Jardin — Mon, 06 Dec 2021 00:00:00 +0000

Le marché de la migration en France est intense. Le Groupe de Travail Inter-Entreprises PostgreSQL (PGGTIE) a même publié un guide de transition à PostgreSQL à destination des entreprises françaises. Ce dernier est le fruit de près de cinq années de travaux au sein de plusieurs organismes publics et a pour ambition de démontrer l’intérêt de PostgreSQL aux décideurs techniques en présentant les forces et les faiblesses du moteur.

Le mois dernier, une traduction en anglais est sortie des cartons pour promouvoir davantage ce mouvement vers le logiciel libre dans les autres pays. Je trouvais intéressant de profiter de cette actualité pour partager mes réflexions du moment, entre ma vision du marché français et l’approche technique pour engager les migrations de données vers PostgreSQL.

Une transition à marche forcée

La démarche n’est pas anodine, car depuis 2012, l’État français au travers de ses différents ministères, tente de contrer l’imposant marché des logiciels propriétaires en favorisant leurs remplacements systématiques par une alternative Open Source. Depuis quelques années, le Socle Interministériel de Logiciels Libres (SILL) est mis à jour par un groupe de travail pour faire un bilan des choix structurants engagés sur le territoire français.

La publication d’un guide de transition pour PostgreSQL aspire à rassurer les équipes opérationnelles et décisionnelles en apportant un grand nombre de conseils et de comparaisons sur ce qu’il est aujourd’hui possible de faire avec PostgreSQL. Il mentionne les trois grandes étapes pour réaliser la migration des données d’une application vers le moteur open-source :

migration des données ;
correction et réécriture des requêtes SQL et des procédures embarquées ;
recette du système pour écarter les régressions fonctionnelles.

Chacune de ces étapes a un coût, qu’il sera nécessaire de pondérer durant le chantier de migration. Les logiciels Open Source sont libres, mais ne sont pas gratuits et c’est un rappel essentiel que proposent les conclusions de ce guide. Les coûts de formation et de prestations externes ne sont également pas négligeables…

En 2018, la société française Dalibo avait publié un livre blanc dans ce même esprit de pédagogie sur l’importance des coûts d’investissement et de possession. Dans un scénario de migration, acté sur cinq années de transition, l’étude montre que l’analyse de portabilité vers PostgreSQL est la principale dépense au cours de la première année, suivie par un investissement important pour la recherche et le développement d’un socle d’outils dédiés aux déploiements, la maintenance et l’administration du parc PostgreSQL.

La seconde courbe peut paraître surprenante pour du logiciel libre, mais la nécessité de contracter une offre de support reste d’actualité, car trop peu de services informatiques disposent des compétences internes pour assurer la disponibilité et la maintenance des instances. Un effort initial de formation est requis pour aider les administrateurs en poste à faire également leur transition vers cette autre technologie.

Pour cette raison, de nombreux acteurs se positionnent depuis des décennies pour proposer de l’accompagnement opérationnel et technique auprès des entreprises de toutes tailles qui souhaitent (principalement) réduire les coûts de licence de logiciels propriétaires. Et bien que la transition pouvait être pénible il y a dix ans, les dernières versions de PostgreSQL et la prolifération d’outils communautaires apportent leur lot de fonctionnalités qui ne rougissent plus devant les atouts phares de certains mastodontes historiques du marché.

S’armer d’outils et de courage

Réaliser une migration impose de s’équiper d’un panel d’outils pour simplifier les grandes lignes de la migration et bien sûr, économiser du temps et de l’argent. Parmi les contributions libres, nous retrouverons l’incontournable Ora2pg, spécialisé dans la conversion d’un schéma Oracle et la migration de son contenu vers une instance PostgreSQL. Pour une base de type SQL Server de Microsoft, pgloader sera privilégié. Les deux outils supportent également les données en provenance de MySQL.

En juillet dernier, je partageais mes réflexions sur l’implémentation de la norme SQL/MED et des foreign data wrappers, ou connecteurs. L’actualité fut particulièrement riche cet été, avec la sortie de la version 22.0 du projet Ora2Pg, dont le nouveau support de l’extension oracle_fdw annonçait des gains vertigineux sur le temps de copie des données.

Ni une ni deux, j’ai souhaité comprendre et découvrir les dessous d’un tel procédé en manipulant moi-même les tables externes pour réaliser une migration de schémas et de données d’une base Oracle vers PostgreSQL, sans utiliser l’outil Ora2Pg. Cette procédure s’inspire d’un autre article de MigOps, publié plus tôt cette année.

1. Compiler le wrapper communautaire

Le connecteur oracle_fdw nécessite d’être compilé à partir des sources du projet pour prendre en compte les bibliothèques propriétaires d’Oracle, garantes du protocole de connexion et des échanges de données. Dans l’exemple ci-dessous, je dispose d’un serveur CentOS 7 avec une instance PostgreSQL 14 et j’ai installé l’Instant Client 19, disponible sur la plateforme de téléchargement d’Oracle.

yum install -y postgresql14-devel
export ORACLE_HOME=/usr/lib/oracle/19.13/client64
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
export PATH=$PATH:$ORACLE_HOME/bin

cd ORACLE_FDW_2_4_0/
make PG_CONFIG=/usr/pgsql-14/bin/pg_config
make PG_CONFIG=/usr/pgsql-14/bin/pg_config install

Pour résoudre d’éventuels problèmes de détection de la librairie Oracle Instant Client et permettre la création de l’extension, il est nécessaire de renseigner la variable $LD_LIBRARY_PATH pour l’instance PostgreSQL au niveau de son service :

systemctl edit postgresql-14

[Service]
Environment="ORACLE_HOME=/usr/lib/oracle/19.13/client64"
Environment="LD_LIBRARY_PATH=/usr/lib/oracle/19.13/client64/lib"

L’extension peut ainsi être créée avec les privilèges d’un super-utilisateur dans la base qui accueillera les données finales. Le privilège USAGE peut ensuite être octroyé au propriétaire de la base pour préparer le schéma.

CREATE EXTENSION oracle_fdw;
GRANT USAGE ON FOREIGN DATA WRAPPER oracle_fdw TO hr;

2. Importer les tables externes

L’unique configuration repose sur la création d’un objet SERVER et l’attribution d’un mot de passe pour l’utilisateur courant, afin d’ouvrir un pont entre les deux systèmes.

CREATE SERVER orcl_hr FOREIGN DATA WRAPPER oracle_fdw
 OPTIONS (dbserver '//localhost:1521/hr');

CREATE USER MAPPING FOR hr SERVER orcl_hr
 OPTIONS (user 'hr', password 'demo');

La magie du wrapper opère lors de l’inspection de la base de données externe et de la création des relations dans un schéma PostgreSQL. Dans mon exemple, je dispose d’une base Oracle XE avec le schéma prédéfini HR contenant une variété de tables, de vues, d’index et de contraintes d’intégrité.

CREATE SCHEMA source;
SET search_path = source;
IMPORT FOREIGN SCHEMA "HR" FROM SERVER orcl_hr INTO source;

Avec psql et la méta-commande \dE, il est dès lors possible de consulter les tables externes importées dans le schéma source. L’une des huit tables est en réalité une vue, car l’extension consulte le catalogue ALL_TAB_COLUMNS dans lequel figurent les tables et vues accessibles par l’utilisateur connecté. Dans la phase d’étude de la migration, ce point doit être correctement identifié pour récupérer l’ordre de création de la vue, en adaptant la requête SQL si besoin.

 List of relations
 Schema | Name | Type | Owner
--------+------------------+---------------+-------
 source | countries | foreign table | hr
 source | departments | foreign table | hr
 source | emp_details_view | foreign table | hr
 source | employees | foreign table | hr
 source | job_history | foreign table | hr
 source | jobs | foreign table | hr
 source | locations | foreign table | hr
 source | regions | foreign table | hr

3. Créer les tables et les vues

Pour chacune de ces tables externes, il faut créer leur équivalent dans la base PostgreSQL. Pour mon exemple, je choisis le schéma public comme destination. L’une des méthodes les plus rapides repose sur l’option LIKE de l’instruction CREATE TABLE.

CREATE TABLE public.countries (LIKE source.countries);
CREATE TABLE public.departments (LIKE source.departments);
CREATE TABLE public.employees (LIKE source.employees);
CREATE TABLE public.job_history (LIKE source.job_history);
CREATE TABLE public.jobs (LIKE source.jobs);
CREATE TABLE public.locations (LIKE source.locations);
CREATE TABLE public.regions (LIKE source.regions);

À partir de cette étape, il est judicieux d’apporter quelques modifications aux types de colonnes. En effet, les types DATE et NUMBER en provenance d’Oracle ont des équivalences bien plus riches et efficientes avec PostgreSQL. Pour aller plus loin, l’un des chapitres de la formation Dalibo « Migrer d’Oracle à PostgreSQL » revient sur les différences notables entre les deux systèmes.

ALTER TABLE public.regions ALTER region_id TYPE smallint;
ALTER TABLE public.countries ALTER region_id TYPE smallint;
ALTER TABLE public.employees ALTER hire_date TYPE date;
ALTER TABLE public.job_history
 ALTER start_date TYPE date,
 ALTER end_date TYPE date;

La vue, quant à elle, doit être recréée pour les besoins de l’application.

CREATE OR REPLACE VIEW public.emp_details_view (
 employee_id, job_id, manager_id, department_id, location_id, country_id,
 first_name, last_name, salary, commission_pct, department_name, job_title,
 city, state_province, country_name, region_name
) AS
SELECT e.employee_id, e.job_id, e.manager_id, e.department_id, d.location_id,
 l.country_id, e.first_name, e.last_name, e.salary, e.commission_pct,
 d.department_name, j.job_title, l.city, l.state_province,
 c.country_name, r.region_name
 FROM public.employees e
 JOIN public.departments d ON e.department_id = d.department_id
 JOIN public.jobs j ON j.job_id = e.job_id
 JOIN public.locations l ON d.location_id = l.location_id
 JOIN public.countries c ON l.country_id = c.country_id
 JOIN public.regions r ON c.region_id = r.region_id;

4. Importer les données

La méthode la plus simple pour importer les données reste la copie table à table avec l’instruction INSERT INTO. Avec PostgreSQL, la commande TABLE est équivalente à un SELECT * FROM, que j’utilise pour alléger les requêtes dans l’exemple ci-dessous.

INSERT INTO public.countries TABLE source.countries;
INSERT INTO public.departments TABLE source.departments;
INSERT INTO public.employees TABLE source.employees;
INSERT INTO public.job_history TABLE source.job_history;
INSERT INTO public.jobs TABLE source.jobs;
INSERT INTO public.locations TABLE source.locations;
INSERT INTO public.regions TABLE source.regions;

Dans le cas de tables hautement volumineuses, cette méthode montrera très vite des faiblesses de performance, car les instructions sont exécutées les unes après les autres et que le parcours d’une table distante n’est réalisé que par un seul processus.

À moins de développer son propre système de distribution de requêtes et de lectures parallélisées, sachez que l’outil Ora2Pg propose parfaitement des pistes d’optimisation pour accélérer grandement les insertions lors de cette phase de chargement.

5. Créer les séquences, les index et les contraintes

Cette dernière étape est indispensable pour maintenir la cohérence du modèle et pour garantir des performances similaires, il ne faut donc pas mésestimer la phase d’étude qui permettra d’inventorier les séquences, les index et les contraintes à recréer dans la base PostgreSQL. Pour aller jusqu’au bout de ma démonstration, voici les instructions à exécuter pour finaliser la migration.

-- regions
ALTER TABLE regions
 ADD CONSTRAINT reg_id_pk PRIMARY KEY (region_id);

-- countries
ALTER TABLE countries
 ADD CONSTRAINT country_c_id_pk PRIMARY KEY (country_id),
 ADD CONSTRAINT countr_reg_fk FOREIGN KEY (region_id)
 REFERENCES regions(region_id);

-- locations
CREATE SEQUENCE locations_seq
 START WITH 3300 INCREMENT BY 100 MAXVALUE 9900;

ALTER TABLE locations
 ALTER location_id SET DEFAULT nextval('locations_seq'::regclass),
 ADD CONSTRAINT loc_id_pk PRIMARY KEY (location_id),
 ADD CONSTRAINT loc_c_id_fk FOREIGN KEY (country_id)
 REFERENCES countries(country_id);

-- departments
CREATE SEQUENCE departments_seq
 START WITH 280 INCREMENT BY 10 MAXVALUE 9990;

ALTER TABLE departments
 ALTER department_id SET DEFAULT nextval('departments_seq'::regclass),
 ADD CONSTRAINT dept_id_pk PRIMARY KEY (department_id),
 ADD CONSTRAINT dept_loc_fk FOREIGN KEY (location_id)
 REFERENCES locations (location_id);

-- jobs
ALTER TABLE jobs
 ADD CONSTRAINT job_id_pk PRIMARY KEY(job_id);

-- employees
CREATE SEQUENCE employees_seq
 START WITH 207 INCREMENT BY 1;

ALTER TABLE employees
 ALTER employee_id SET DEFAULT nextval('employees_seq'::regclass),
 ADD CONSTRAINT emp_emp_id_pk PRIMARY KEY (employee_id),
 ADD CONSTRAINT emp_dept_fk FOREIGN KEY (department_id)
 REFERENCES departments,
 ADD CONSTRAINT emp_job_fk FOREIGN KEY (job_id)
 REFERENCES jobs (job_id),
 ADD CONSTRAINT emp_manager_fk FOREIGN KEY (manager_id)
 REFERENCES employees;

ALTER TABLE departments
 ADD CONSTRAINT dept_mgr_fk FOREIGN KEY (manager_id)
 REFERENCES employees (employee_id);

-- job_history
ALTER TABLE job_history
 ADD CONSTRAINT jhist_emp_id_st_date_pk PRIMARY KEY (employee_id, start_date),
 ADD CONSTRAINT jhist_job_fk FOREIGN KEY (job_id)
 REFERENCES jobs,
 ADD CONSTRAINT jhist_emp_fk FOREIGN KEY (employee_id)
 REFERENCES employees,
 ADD CONSTRAINT jhist_dept_fk FOREIGN KEY (department_id)
 REFERENCES departments;

Dans des situations particulièrement simples, la migration vers PostgreSQL peut être intégralement réalisée à l’aide du langage SQL et d’une extension de la famille des foreign data wrappers. Cependant, le temps de copie restera très dépendant de l’ordonnancement que l’on peut en faire, et du débit de transfert entre les deux systèmes.

Conclusion

La migration deviendra complexe lorsque la base de données à migrer embarque du code PL/SQL stratégique. À moins d’extraire la logique métier et de l’implémenter dans une application dédiée, la conversion du code en routines PL/pgSQL méritera toute votre attention. Bien qu’Ora2Pg puisse simplifier le travail de portage avec une conversion automatique tout à fait honorable, il sera indispensable de tester la non-régression fonctionnelle.

Un outil comme pgTAP peut aider à rédiger des tests unitaires ou de bout en bout pour couvrir le code et vous accompagner dans le portage des procédures. L’année dernière, j’avais pris plaisir à rédiger un atelier complet sur la traduction des procédures PL/SQL fournies avec le schéma HR présenté aujourd’hui. N’hésitez pas à le consulter !

Parlons un peu des données externes

Florent Jardin — Fri, 16 Jul 2021 00:00:00 +0000

Depuis plusieurs semaines, j’étudie les nouveautés de la prochaine version majeure de PostgreSQL avec un intérêt grandissant pour le connecteur postgres_fdw. Cette extension assez folle n’a pas son équivalent sur les autres systèmes de bases de données du marché, et pour cause, PostgreSQL est l’un des rares à respecter la norme SQL/MED, sous-partie du langage SQL tel que défini par le standard ISO/IEC 9075-9.

Un langage pour les gouverner tous

Il y a maintenant plus d’un demi-siècle que fut conçu le langage SQL, fruit de la collaboration de deux chercheurs, Donald D. Chamberlin et Ray Boyce, dans la lancée des innovations des années 70, tel que le modèle relationnel. Ces deux personnages souhaitaient à l’époque proposer un outil de requêtage relationnel qui pourrait être accessible au plus grand nombre, dans une langue universelle et sans formation particulière en mathématique ou en programmation logicielle.

Alors que Ray Boyce mourut prématurément à l’âge de 26 ans, la notoriété de leur langage s’amplifia lors de sa phase de développement chez IBM et le sobrement nommé « Sequel » changea de nom en conflit avec une autre marque déposée. Ainsi le nom du projet fut raccourci en « SQL » à l’aube de l’année 1977. La décennie qui suivit fut marquée par l’émergence des produits comme Oracle Database et DB2, implémentant alors les prémices du SQL que l’on connait aujourd’hui.

En 1986, le langage évolua sous la forme d’un standard, repris par les regroupements ANSI et ISO, afin de promouvoir les règles d’écriture et la conformité auprès des différents éditeurs. Les standards ANSI X3.135 et ISO/IEC 9075 étaient nés. À partir de ce point précis, et les nombreuses révisions du standard SQL, les utilisateurs avaient l’assurance de ne pas être dépendants d’un unique éditeur logiciel, bien que certains ne répondaient pas à la totalité du standard et intégraient volontiers des fonctionnalités propriétaires.

La dernière révision stable de la norme a été proposée en 2016 et PostgreSQL tend à couvrir la totalité des fonctionnalités obligatoires de la norme.

C’est lors de la révision de l’année 2003 que le standard fut subdivisé en 9 parties issues du standard précédent. Chacune d’entre elles ayant pour ambition de couvrir un aspect différent du langage et parmi elles, nous retrouvons celle qui m’intéresse particulièrement ces temps-ci : la norme ISO/IEC 9075-9, Management of External Data, aussi appelée SQL/MED.

Ce chapitre de la norme propose les concepts de datalink et de foreign-data wrapper, ainsi que les différentes syntaxes pour les manipuler. Ces éléments peuvent déjà vous paraître familiers, il s’agit de la même terminologie qu’emploie PostgreSQL pour répondre à la norme. Ce standard impliquerait que les données d’un système soient dites externes, si elles sont disponibles et gérés par un autre système de base de donnée.

Une telle architecture répondant à ces contraintes permet l’émergence des systèmes de bases de données fédérées, responsables de la gestion d’un ensemble de données autonomes et hétérogènes. Sur le plan théorique, les utilisateurs et les applications ne se connectent plus qu’à un seul point d’accès et seraient capables de consulter et modifier les données éparpillées sur différents moteurs de bases de données.

Pour garantir un tel résultat, la norme SQL/MED articule autours des connecteurs (wrappers), une série de composant tels que les serveurs distants (foreign servers) ou les correspondances d’utilisateurs (user mappings). Ainsi, chaque connecteur s’appuie sur une librairie logicielle pour permettre la communication avec le serveur à l’aide de ces identifiants de connexion.

Au cours des années qui suivirent, la communauté de développeurs autours de PostgreSQL s’est aligné avec la norme pour proposer plusieurs extensions stables de connecteurs. Aujourd’hui, la plupart des systèmes relationnels disposent d’une abstraction pour permettre l’accès des données externe à l’intérieur de PostgreSQL.

Une implémentation aux petits oignons

Avec un cycle de développement annuel et le support d’une version majeure sur une durée de cinq années, les grands chantiers ont fréquemment été menés par petits pas. L’implémentation de SQL/MED dans PostgreSQL n’y a pas fait exception.

C’est en juillet 2009 que sort la version 8.4, la dernière de la branche 8.x avant l’avènement des versions plus récentes. L’architecture qui rendrait possible les connecteurs avait été posée. Le catalogue fut enrichi par de nouvelles vues, telles que pg_foreign_data_wrapper, pg_foreign_server ou pg_user_mapping et de nouvelles commandes préparaient le terrain.

CREATE FOREIGN DATA WRAPPER postgresql;
CREATE SERVER demo FOREIGN DATA WRAPPER postgresql OPTIONS (dbname 'demo');
CREATE USER MAPPING FOR public SERVER demo;

La gestion des données distantes n’était alors possible qu’à travers l’extension dblink qui fut rendue compatible avec les nouveaux objets de la norme SQL/MED. L’exemple ci-dessous s’appuie sur le serveur demo avec une connexion préalable à l’aide de la méthode dblink_connect. À cette époque, les connecteurs reposaient sur la libpq par défaut.

-- les extensions n'existent pas encore en version 8.4 :-)
\i src/contrib/dblink/dblink.sql

SELECT dblink_connect('myconn', 'demo');

-- dblink_connect
-- ----------------
-- OK

SELECT *
 FROM dblink('myconn', 'SELECT word FROM messages')
 AS t(hello text);

-- hello
-- -------
-- world

Le projet pl/proxy profita également de ces améliorations pour définir un cluster de serveurs distants sur lesquels il était possible d’exécuter des fonctions déportées, et d’envisager une architecture éclatée (sharding) sur plusieurs instances PostgreSQL.

En septembre 2011, les choses s’accélérèrent à la sortie de PostgreSQL 9.1 avec l’ajout des tables distantes (ou foreign tables) pour compléter le chantier initié par la version 8.4. Bien qu’elles n’étaient accessibles qu’en lecture seule, leur fonctionnement faisait pâlir dblink à bien des égards.

Derrière chaque table distante se cache un connecteur, préalablement configuré avec ses informations d’accès et d’authentification. En plus du wrapper interne pour les instances PostgreSQL, la contribution file_fdw fut ajoutée au projet afin d’autoriser les fichiers CSV et COPY comme sources de données externes. Ce type de table est similaire aux tables externes qu’Oracle propose pour les formats CSV, Datapump ou SQL*Loader.

CREATE EXTENSION file_fdw;
CREATE SERVER file_server FOREIGN DATA WRAPPER file_fdw;

CREATE FOREIGN TABLE departments (
 department_id int,
 department_name varchar(30) NOT NULL
) SERVER file_server OPTIONS (
 filename '<path>/departments.dat'
);

Sur pareilles tables, PostgreSQL supporte uniquement les contraintes (NOT) NULL et CHECK pour des besoins de planification. Ces contraintes doivent être assurées par le serveur distant. Les clés primaires ou contraintes UNIQUE impliquent la création d’un index, qui ne sont pas supportés pour les tables distantes.

CREATE INDEX ON departments (department_id);
-- ERROR: cannot create index on foreign table "departments"

L’usage premier des tables distantes consiste à intégrer ces relations dans les requêtes SQL comme de simples tables, ce qui vous l’avouerez, reste bien plus simple que d’écrire des sous-requêtes avec les résultats par dblink. Par ailleurs, le nœud Foreign Scan fait son introduction pour représenter la lecture distante à travers le connecteur.

EXPLAIN (analyze, costs off)
SELECT department_name, count(employee_id)
 FROM employees JOIN departments USING (department_id)
 WHERE department_id = 1
 GROUP BY department_name;

 QUERY PLAN
-----------------------------------------------------------------------
 HashAggregate (actual time=0.084..0.084 rows=1 loops=1)
 -> Nested Loop (actual time=0.058..0.077 rows=1 loops=1)
 -> Foreign Scan on departments
 (actual time=0.034..0.050 rows=1 loops=1)
 Filter: (department_id = 1)
 Foreign File: departments.dat
 -> Index Scan using employees_department_id_idx on employees
 (actual time=0.020..0.022 rows=1 loops=1)
 Index Cond: (department_id = 1)
 Total runtime: 0.230 ms

Conclusion

La page pgpedia sur les FDW reprend l’historique des améliorations apportées entre chaque version majeure depuis une décennie. Le travail abattu est impressionnant et se poursuit encore avec la prochaine version. L’architecture pensée lors de la version 8.4 reste toujours fiable, robuste et aura permis l’émergence de nombreux connecteurs pour PostgreSQL (postgres_fdw), Oracle (oracle_fdw) ou SQL Server (tds_fdw).

Parmi les nombreuses possibilités qu’apporte la norme SQL/MED, j’ai pu apprécier récemment l’usage du connecteur Oracle dans la version 22.0 de l’outil Ora2Pg pour les migrations de données grâces aux tables distantes. Avec la version 14 de PostgreSQL, la lecture asynchrone des partitions distantes permettra d’accélérer passablement les requêtes d’analyse sur de fortes volumétries.