Babelfish for PostgreSQL, la solution pour migrer de SQL Server à PostgreSQL sans que les applications ne s'en aperçoivent !

Introduction

Il n’est pas rare que l’on abandonne un projet de migration de SQL Server vers d’autres SGBD comme PostgreSQL, car souvent tout est à repenser From Scratch. En effet, la récriture des procédures stockées et des fonctions peut être très chronophage.

Une solution pour cela est l’adoption de Babelfish. Avec ce dernier, nous pouvons gagner un temps considérable lors d’une migration. Bien que toutes les fonctionnalités ne soient pas supportées par Babelfish, les ajustements à faire restent relativement peu nombreux et moins complexes par rapport à une migration classique.

Babelfish for Postgres, de quoi s’agit-il ?

Babelfish for PostgreSQL a été développé par AWS et puis rendu Open source. Il est conçu pour comprendre le dialecte T-SQL de SQL Server via le port TDS (Tabular Data Stream), permettant ainsi de lire et d’écrire des données dans une base de données PostgreSQL comme si c’était une base SQL Server. Il est disponible sous les licences Apache 2.0 et PostgreSQL. Nous le retrouvons intégré à Amazon Aurora PostgreSQL dans AWS.

En d’autres termes, Babelfish permet d'utiliser le dialecte SQL Server pour lire et écrire des données sur une base de données PostgreSQL.

Pourquoi l’adopter ?

Il existe plusieurs raisons pour lesquelles nous pouvons adopter Babelifsh. Nous pouvons citer :

• La réduction des coût du fait de sa gratuité.
• Il est Open Source et la communauté sur GitHub est très réactive. Elle répond aux questions des utilisateurs et fixe les bugs dans les nouvelles Releases. Il est également possible que de nouvelles fonctionnalités soient ajoutées à la demande des utilisateurs.
• Tous le monde est le bienvenu pour contribuer au projet.
• Migration depuis SQL Server pas trop complexe car la plupart des fonctionnalités sont supportées par Babelfish. Même si ce n’est pas à 100%, cela reste possible sans avoir à réécrire toute la structure des BDD.
• La possibilité de se connecter à Babelfish simultanément via le protocole TDS (port 1433) et le protocole PostgreSQL (port 5432). Cela peut s'avérer très pratique lorsqu'on utilise plusieurs applications avec différents langages et chaînes de connexion.
• La possibilité de partir sur une migration progressive. C’est-à-dire commencer par migrer les données tout en continuant d’utiliser le dialecte SQL Server, puis PostgreSQL à terme.
• Le support des transactions ACID (https://blog.atawiz.fr/transactions-acid-spark-databricks-deltalake/) assurant la fiabilité et l’intégrité des données.
• La performance et évolutivité, car Babelfish repose sur PostgreSQL qui est reconnu pour sa robustesse et ses performances.

Ses limites

Bien que Babelfish soit un excellent outil d’alternative de SQL Server, comme tout autre software il présente cependant des défauts et des limites.

• Certaines requêtes complexes peuvent s'exécuter lentement, et des erreurs de connexion au serveur Babelfish peuvent parfois survenir, en particulier avec des requêtes longues ou complexes. Pour y palier, Nous pouvons découper les requêtes complexes en sous-requêtes plus simples, et utilisez des tables temporaires pour stocker les résultats intermédiaires. Si les problèmes de connexion persistent malgré l'optimisation, la solution est d'utiliser des tables permanentes pour stocker les résultats intermédiaires. Il est essentiel de vider ces tables au début de chaque exécution.
• Des soucis d'interférence et d'interopérabilité peuvent survenir dans deux cas principaux :
  • Lorsqu'un utilisateur tente, via le port TDS, d'exécuter des requêtes sur des objets qui ont été créés dans un contexte PostgreSQL natif.
  • À l'inverse, lorsque des objets créés dans un contexte SQL Server (via Babelfish) sont appelés ou manipulés via une connexion PostgreSQL standard.

Ces deux situations peuvent entraîner des comportements inattendus, des erreurs, ou des incompatibilités dues aux différences entre les deux systèmes de gestion de base de données.

Installation

Avant d’attaquer l’installation, il est nécessaire de connaitre et de choisir le mode de la base de données. En effet, Babelfish propose deux types : single-db et multi-db.

• Single-db (par défaut) : avec ce mode, une seule BDD est possible d’être créée côté T-SQL et le schéma de la table sera équivalent à celui d’un schéma d’une BDD PostgreSQL. Ce mode est choisi généralement lorsque l’utilisateur n’a qu’une BDD SQL Server à migrer et que son intension est de migrer plus tard vers du PostgreSQL natif.
• Multi-db : contrairement au premier mode, nous pouvons créer plus d’une BDD coté T-SQL avec chacune son propre schéma. C’est le mode à choisir si le but est de migrer plusieurs BDD SQL Server et de rester sur Babelfish.

Ce choix peut être configuré avec le paramètre « babelfishpg_tsql.migration_mode ». Il n’est pas possible de le modifier une fois la BDD du Cluster initialisée.

Nous allons à présent voir comment installer Babeflish et ses extensions sur Linux. J’ai une distribution Debian 12 sur mon ordinateur, et certains packages peuvent ne pas être compatible avec votre système. Il faudra dans ce cas trouver le package équivalent ou simplement la bonne version.

L’installation des extensions comme Plpython3u et PostGIS est optionnelle. Cependant, j’ai choisi de les inclure dans le guide d’installation afin qu’elles puissent servir d’exemple pour l’installation d’autres extensions si besoin.

Le script complet de l’installation est disponible sur le repos GitHub : https://github.com/bachpro900/babelfish_plpython3u_postgis/blob/main/babelfish_installation.sh

Le script comprend plusieurs étapes d’installation et de Build :

• Installation des packages et téléchargement des fichiers sources de Babelfish et de PostGIS.
• Installation et Build d’ANTLR4. ANTLR est un puissant Parser utilisé dans la lecture, la génération et la traduction du texte structuré ou binaire.
• Build de PostgreSQL compatible avec Babelfish.
• Build des extensions de Babelfish :
  • babelfishpg_money
  • babelfishpg_common
  • babelfishpg_tds
  • babelfishpg_tsql
  • Plpython3u
  • PostGIS
• Configuration et lancement du serveur Babelfish.
• Installation des extensions :
  • babelfishpg_tds
  • Plpython3u
  • PostGIS

Maintenant que l’installation est faite, nous avons deux possibilités pour se connecter au serveur, avec SQLCMD et avec PSQL. Pour cela, nous devons avoir ces clients déjà installés sur notre ordinateur (ou sur un ordinateur distant avec des flux ouverts). Mais il est surtout possible de se connecter avec SSMS et pgAdmin 😊

• Chaine de connexion avec SQLCMD :

sqlcmd -S ip_adress -d master -U babelfish_user -P a$@Qo*iUseiZ$

• Chaine de connexion avec PSQL :

psql "host=ip_adress dbname=babelfish_db user=babelfish_user password=a$@Qo*iUseiZ$"

Sur SSMS :

Connexion au serveur via SSMS

Sur pgAdmin :

Connexion au serveur via pgAdmin

Cas pratique

Nous allons maintenant créer, via le port 1433, la structure de deux bases de données, quatre tables, une procédure stockée et une fonction qui renvoie le niveau de stock des produits.

Le script SQL est disponible ici : https://github.com/bachpro900/babelfish_plpython3u_postgis/blob/main/databases_structure.sql

Comme nous pouvons le voir, tous les objets ont été créés sans problème de syntaxe ni d’incompatibilité :

Structure des BDD dans SSMS

De même via pgAdmin :

Structure des BDD dans pgAdmin

Les tables créées peuvent être lues et écrites via les deux ports (le 1433 et le 5432). Nous pouvons constater que le schéma des objets n’est pas tout à fait le même dans les deux interfaces.

• SSMS : le schéma se présente comme si nous étions sur un serveur SQL natif.
• pgAdmin : Coté Babelfish, nous avons qu’une seule BDD Babelfish et il s’agit de babeflish_db. Puis les objets ont été créés avec cette hiérarchie :
  • Pour les schémas : databaseName_schemaName
  • Pour les autres objets (tables, vues, fonctions, etc.) : databaseName_schemaName.objectName

Ainsi, dans PostgreSQL la table Orders se présente : babelfish_db.retail_sales.orders

Les résultats des deux requêtes via les deux ports sont les mêmes. Le type des colonnes, comme nous pouvons le voir dans pgAdmin, est également le même que celui définit lors de la création de la table dans SSMS.

SELECT de la table [orders] dans SSMS

SELECT de la table [orders] dans pgAdmin

À noter que pour des soucis de collations, il arrive parfois que l’ordre des résultats n’est pas le même que celui sur un SQL Server natif. C’est pourquoi, il peut être nécessaire de définir une collation qui répond au mieux aux besoins du serveur à migrer.

La procédure stockée et la fonction peuvent aussi être exécutées via le port 1433 comme si elles étaient sur un serveur SQL Serveur conventionnel. Je rappelle que nous avons créé les BDD, les tables, la procédure stockée et la fonction avec du T-SQL. Ces objets ont été créés dans Babeldish (donc dans un serveur PostgreSQL), et les données y sont également stockées, mais nous arrivons à effectuer toutes les opérations via le port 1433.

Ci-dessous nous appelons la procédure stockées et la fonction directement dans SSMS !

Appel de la proc stock et de la fonction dans SSMS

Les applications qui étaient habituées à se connecter à l’ancien serveur SQL Server ne verront aucune différence significative. La seule chose à changer est seulement la chaine de connexion pour pointer vers le nouveau serveur Babelfish !

Conclusion

Babelfish offre une opportunité pour les entreprises cherchant à intégrer des applications SQL Server vers un environnement PostgreSQL. Comme il est compatible avec le dialecte T-SQL et grâce ses extensions, Babelfish facilite grandement la migration, et réduit les coûts et les risques liés aux réécritures massives du code.

Il est vrai que Babelfish est encore perfectible sur certains aspects, notamment en matière de prise en charge des fonctionnalités avancées de SQL Server, il se présente comme un outil puissant tirant avantage de la flexibilité et de la robustesse de PostgreSQL tout en conservant un environnement SQL Server familier.