Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Modifier les applications Python et Perl pour prendre en charge la migration de bases de données de Microsoft SQL Server vers Amazon Aurora PostgreSQL Compatible Edition
Créée par Dwarika Patra (AWS) et Deepesh Jayaprakash (AWS)
Récapitulatif
Ce modèle décrit les modifications apportées aux référentiels d'applications qui peuvent être nécessaires lorsque vous migrez des bases de données de Microsoft SQL Server vers Amazon Aurora PostgreSQL Compatible Edition. Le modèle suppose que ces applications sont basées sur Python ou Perl, et fournit des instructions distinctes pour ces langages de script.
La migration de bases de données SQL Server vers une version compatible avec Aurora PostgreSQL implique la conversion de schémas, la conversion d'objets de base de données, la migration de données et le chargement de données. En raison des différences entre PostgreSQL et SQL Server (relatives aux types de données, aux objets de connexion, à la syntaxe et à la logique), la tâche de migration la plus difficile consiste à apporter les modifications nécessaires à la base de code afin qu'elle fonctionne correctement avec PostgreSQL.
Pour une application basée sur Python, les objets et les classes de connexion sont dispersés dans tout le système. En outre, la base de code Python peut utiliser plusieurs bibliothèques pour se connecter à la base de données. Si l'interface de connexion à la base de données change, les objets qui exécutent les requêtes en ligne de l'application doivent également être modifiés.
Pour une application basée sur Perl, les modifications concernent les objets de connexion, les pilotes de connexion à la base de données, les instructions SQL en ligne statiques et dynamiques, ainsi que la façon dont l'application gère les requêtes DML dynamiques complexes et les ensembles de résultats.
Lorsque vous migrez votre application, vous pouvez également envisager d'apporter des améliorations à AWS, telles que le remplacement du serveur FTP par un accès Amazon Simple Storage Service (Amazon S3).
Le processus de migration des applications comporte les défis suivants :
Objets de connexion. Si les objets de connexion sont dispersés dans le code avec plusieurs bibliothèques et appels de fonctions, vous devrez peut-être trouver un moyen généralisé de les modifier pour qu'ils soient compatibles avec PostgreSQL.
Gestion des erreurs ou des exceptions lors de la récupération ou des mises à jour des enregistrements. Si vous effectuez des opérations conditionnelles de création, de lecture, de mise à jour et de suppression (CRUD) sur la base de données qui renvoient des variables, des ensembles de résultats ou des blocs de données, toute erreur ou exception peut entraîner des erreurs d'application avec des effets en cascade. Celles-ci doivent être traitées avec soin, avec des validations appropriées et des points de sauvegarde. L'un de ces points de sauvegarde consiste à appeler de grandes requêtes SQL en ligne ou des objets de base de données à l'intérieur de
BEGIN...EXCEPTION...END
blocs.Contrôle des transactions et de leur validation. Cela inclut les validations et annulations manuels et automatiques. Le pilote PostgreSQL pour Perl vous oblige à toujours définir explicitement l'attribut de validation automatique.
Gestion des requêtes SQL dynamiques. Cela nécessite une solide compréhension de la logique des requêtes et des tests itératifs pour garantir que les requêtes fonctionnent comme prévu.
Rendement. Vous devez vous assurer que les modifications du code n'entraînent pas de dégradation des performances des applications.
Ce modèle explique le processus de conversion en détail.
Conditions préalables et limitations
Prérequis
Connaissance pratique de la syntaxe Python et Perl.
Compétences de base en SQL Server et PostgreSQL.
Compréhension de l'architecture de votre application existante.
Accès au code de votre application, à la base de données SQL Server et à la base de données PostgreSQL.
Accès à l'environnement de développement Windows ou Linux (ou autre Unix) avec des informations d'identification pour développer, tester et valider les modifications apportées aux applications.
Pour une application basée sur Python, les bibliothèques Python standard dont votre application peut avoir besoin, telles que Pandas pour gérer les trames de données et psycopg2 ou pour les connexions aux bases de données. SQLAlchemy
Pour une application basée sur Perl, des packages Perl avec des bibliothèques ou des modules dépendants sont nécessaires. Le module Comprehensive Perl Archive Network (CPAN) peut répondre à la plupart des exigences des applications.
Toutes les bibliothèques ou modules personnalisés dépendants requis.
Informations d'identification de base de données pour l'accès en lecture à SQL Server et l'accès en lecture/écriture à Aurora.
PostgreSQL pour valider et déboguer les modifications apportées aux applications avec les services et les utilisateurs.
Accès aux outils de développement lors de la migration d'applications, tels que Visual Studio Code, Sublime Text ou pgAdmin.
Limites
Certaines versions, modules, bibliothèques et packages de Python ou Perl ne sont pas compatibles avec l'environnement cloud.
Certaines bibliothèques et frameworks tiers utilisés pour SQL Server ne peuvent pas être remplacés pour prendre en charge la migration vers PostgreSQL.
Les variations de performances peuvent nécessiter des modifications de votre application, des requêtes Transact-SQL (T-SQL) en ligne, des fonctions de base de données et des procédures stockées.
PostgreSQL prend en charge les noms en minuscules pour les noms de tables, les noms de colonnes et les autres objets de base de données.
Certains types de données, tels que les colonnes UUID, sont stockés en minuscules uniquement. Les applications Python et Perl doivent gérer de telles différences de cas.
Les différences de codage de caractères doivent être gérées avec le type de données approprié pour les colonnes de texte correspondantes dans la base de données PostgreSQL.
Versions du produit
Python 3.6 ou version ultérieure (utilisez la version compatible avec votre système d'exploitation)
Perl 5.8.3 ou version ultérieure (utilisez la version compatible avec votre système d'exploitation)
Aurora PostgreSQL Compatible Edition 4.2 ou version ultérieure (voir les détails)
Architecture
Pile technologique source
Langage de script (programmation d'applications) : Python 2.7 ou version ultérieure, ou Perl 5.8
Base de données : Microsoft SQL Server version 13
Système d'exploitation : Red Hat Enterprise Linux (RHEL) 7
Pile technologique cible
Langage de script (programmation d'applications) : Python 3.6 ou version ultérieure, ou Perl 5.8 ou version ultérieure
Base de données : Aurora PostgreSQL 4.2 compatible
Système d'exploitation : RHEL 7
Architecture de migration

Outils
Services et outils AWS
Aurora PostgreSQL—Compatible Edition est un moteur de base de données relationnelle entièrement géré, compatible avec PostgreSQL et ACID qui associe la vitesse et la fiabilité des bases de données commerciales haut de gamme à la rentabilité des bases de données open source. Aurora PostgreSQL remplace directement PostgreSQL et permet de configurer, d'exploiter et de dimensionner vos déploiements PostgreSQL nouveaux et existants de manière plus simple et plus rentable.
L'interface de ligne de commande AWS (AWS CLI) est un outil open source qui vous permet d'interagir avec les services AWS en utilisant des commandes dans votre shell de ligne de commande.
Autres outils
bibliothèques de connexion aux bases de données Python
et PostgressQL telles que psycopg2 et SQLAlchemy Terminal interactif PostgreSQL (psql
)
Épopées
Tâche | Description | Compétences requises |
---|---|---|
Suivez ces étapes de conversion de code pour migrer votre application vers PostgreSQL. |
Les epics suivants fournissent des instructions détaillées pour certaines de ces tâches de conversion pour les applications Python et Perl. | Développeur d’applications |
Utilisez une liste de contrôle pour chaque étape de la migration. | Ajoutez les éléments suivants à votre liste de contrôle pour chaque étape de la migration des applications, y compris la dernière étape :
| Développeur d’applications |
Tâche | Description | Compétences requises |
---|---|---|
Analysez votre base de code Python existante. | Votre analyse doit inclure les éléments suivants pour faciliter le processus de migration des applications :
| Développeur d’applications |
Convertissez vos connexions de base de données pour qu'elles soient compatibles avec PostgreSQL. | La plupart des applications Python utilisent la bibliothèque pyodbc pour se connecter aux bases de données SQL Server comme suit.
Convertissez la connexion à la base de données pour qu'elle prenne en charge PostgreSQL comme suit.
| Développeur d’applications |
Remplacez les requêtes SQL en ligne par PostgreSQL. | Convertissez vos requêtes SQL en ligne dans un format compatible avec PostgreSQL. Par exemple, la requête SQL Server suivante extrait une chaîne d'une table.
Après la conversion, la requête SQL en ligne compatible avec PostgreSQL se présente comme suit.
| Développeur d’applications |
Gérez les requêtes SQL dynamiques. | Le SQL dynamique peut être présent dans un ou plusieurs scripts Python. Les exemples précédents montraient comment utiliser la fonction de remplacement de chaîne de Python pour insérer des variables afin de créer des requêtes SQL dynamiques. Une autre approche consiste à ajouter des variables à la chaîne de requête, le cas échéant. Dans l'exemple suivant, la chaîne de requête est construite à la volée en fonction des valeurs renvoyées par une fonction.
Ces types de requêtes dynamiques sont très courants lors de la migration d'applications. Pour gérer les requêtes dynamiques, procédez comme suit :
| Développeur d’applications |
Gérez les ensembles de résultats, les variables et les blocs de données. | Pour Microsoft SQL Server, vous utilisez des méthodes Python telles que pyodbc (Microsoft SQL Server)
Dans Aurora, pour effectuer des tâches similaires telles que la connexion à PostgreSQL et l'extraction de jeux de résultats, vous pouvez utiliser psycopg2 ou. SQLAlchemy Ces bibliothèques Python fournissent le module de connexion et l'objet curseur permettant de parcourir les enregistrements de la base de données PostgreSQL, comme illustré dans l'exemple suivant. psycopg2 (compatible avec Aurora PostgreSQL)
SQLAlchemy (Compatible avec Aurora PostgreSQL)
| Développeur d’applications |
Testez votre application pendant et après la migration. | Le test de l'application Python migrée est un processus continu. Étant donné que la migration inclut des modifications d'objets de connexion (psycopg2 ou SQLAlchemy), la gestion des erreurs, de nouvelles fonctionnalités (blocs de données), des modifications du code SQL intégré, des fonctionnalités de copie en bloc (
| Développeur d’applications |
Tâche | Description | Compétences requises |
---|---|---|
Analysez votre base de code Perl existante. | Votre analyse doit inclure les éléments suivants pour faciliter le processus de migration des applications. Vous devez identifier :
| Développeur d’applications |
Convertissez les connexions de l'application Perl et du module DBI pour qu'elles soient compatibles avec PostgreSQL. | Les applications basées sur Perl utilisent généralement le module Perl DBI, qui est un module d'accès aux bases de données standard pour le langage de programmation Perl. Vous pouvez utiliser le même module DBI avec différents pilotes pour SQL Server et PostgreSQL. Pour plus d'informations sur les modules Perl requis, les installations et les autres instructions, consultez la documentation DBD : :Pg
| Développeur d’applications |
Remplacez les requêtes SQL en ligne par PostgreSQL. | Votre application peut comporter des requêtes SQL en ligne avec Dans SQL Server :
Pour PostgreSQL, convertissez en :
| Développeur d’applications |
Gérez les requêtes SQL dynamiques et les variables Perl. | Les requêtes SQL dynamiques sont des instructions SQL créées lors de l'exécution de l'application. Ces requêtes sont construites dynamiquement lorsque l'application est en cours d'exécution, en fonction de certaines conditions, de sorte que le texte complet de la requête n'est pas connu avant l'exécution. Par exemple, une application d'analyse financière qui analyse les 10 meilleures actions sur une base quotidienne, et ces actions changent tous les jours. Les tables SQL sont créées en fonction des meilleures performances, et les valeurs ne sont connues qu'au moment de l'exécution. Supposons que les requêtes SQL en ligne de cet exemple soient transmises à une fonction wrapper pour obtenir les résultats définis dans une variable, puis qu'une variable utilise une condition pour déterminer si la table existe :
Voici un exemple de gestion des variables, suivi des requêtes SQL Server et PostgreSQL pour ce cas d'utilisation.
Serveur SQL :
PostgreSQL :
L'exemple suivant utilise une variable Perl dans le SQL en ligne, qui exécute une Serveur SQL :
PostgreSQL :
| Développeur d’applications |
Tâche | Description | Compétences requises |
---|---|---|
Convertissez des constructions SQL Server supplémentaires en PostgreSQL. | Les modifications suivantes s'appliquent à toutes les applications, quel que soit le langage de programmation.
| Développeur d’applications |
Tâche | Description | Compétences requises |
---|---|---|
Tirez parti des services AWS pour améliorer les performances. | Lorsque vous migrez vers le cloud AWS, vous pouvez affiner la conception de votre application et de votre base de données afin de tirer parti des services AWS. Par exemple, si les requêtes de votre application Python, connectée à un serveur de base de données compatible Aurora PostgreSQL, prennent plus de temps que vos requêtes Microsoft SQL Server d'origine, vous pouvez envisager de créer un flux de données historiques directement vers un bucket Amazon Simple Storage Service (Amazon S3) depuis le serveur Aurora, et d'utiliser des requêtes SQL basées sur Amazon Athena pour générer des rapports et des requêtes de données analytiques pour votre tableaux de bord utilisateur. | Développeur d'applications, architecte cloud |
Ressources connexes
Informations supplémentaires
La compatibilité avec Microsoft SQL Server et Aurora PostgreSQL est conforme à la norme ANSI SQL. Cependant, vous devez toujours être conscient des incompatibilités liées à la syntaxe, aux types de données de colonne, aux fonctions natives spécifiques à la base de données, aux insertions groupées et à la distinction majuscules/minuscules lorsque vous migrez votre application Python ou Perl de SQL Server vers PostgreSQL.
Les sections suivantes fournissent plus d'informations sur les incohérences possibles.
Comparaison des types de données
Les changements de type de données entre SQL Server et PostgreSQL peuvent entraîner des différences significatives dans les données obtenues sur lesquelles les applications fonctionnent. Pour une comparaison des types de données, consultez le tableau sur le site Web de Sqlines
Fonctions SQL natives ou intégrées
Le comportement de certaines fonctions diffère entre les bases de données SQL Server et PostgreSQL. Le tableau suivant fournit une comparaison.
Microsoft SQL Server | Description | PostgreSQL |
---|---|---|
| Convertit une valeur d'un type de données en un autre. | PostgreSQL |
| Renvoie la date et l'heure actuelles du système de base de données, dans un |
|
| Ajoute un intervalle heure/date à une date. |
|
| Convertit une valeur dans un format de données spécifique. |
|
| Renvoie la différence entre deux dates. |
|
| Limite le nombre de lignes d'un ensemble |
|
Blocs anonymes
Une requête SQL structurée est organisée en sections telles que la déclaration, les exécutables et la gestion des exceptions. Le tableau suivant compare les versions Microsoft SQL Server et PostgreSQL d'un bloc anonyme simple. Pour les blocs anonymes complexes, nous vous recommandons d'appeler une fonction de base de données personnalisée au sein de votre application.
Microsoft SQL Server | PostgreSQL |
---|---|
|
|
Autres différences
Insertions groupées de lignes : l'équivalent dans PostgreSQL de l'utilitaire bcp de Microsoft SQL Server
est COPY. Sensibilité majuscules/minuscules : les noms de colonnes distinguent les majuscules et minuscules dans PostgreSQL. Vous devez donc convertir les noms de colonne de SQL Server en minuscules ou en majuscules. Cela devient un facteur lorsque vous extrayez ou comparez des données, ou lorsque vous placez des noms de colonnes dans des ensembles de résultats ou des variables. L'exemple suivant identifie les colonnes dans lesquelles les valeurs peuvent être stockées en majuscules ou en minuscules.
my $sql_qry = "SELECT $record_id FROM $exampleTable WHERE LOWER($record_name) = \'failed transaction\'";
Concaténation : SQL Server l'utilise
+
comme opérateur pour la concaténation de chaînes, alors que PostgreSQL l'utilise.||
Validation : vous devez tester et valider les requêtes et les fonctions SQL en ligne avant de les utiliser dans le code d'application pour PostgreSQL.
Inclusion de la bibliothèque ORM : vous pouvez également rechercher l'inclusion ou le remplacement d'une bibliothèque de connexion à une base de données existante par des bibliothèques ORM Python telles que SQLAlchemy
PynomODB . Cela permettra d'interroger et de manipuler facilement les données d'une base de données en utilisant un paradigme orienté objet.