Sélectionner vos préférences de cookies

Nous utilisons des cookies essentiels et des outils similaires qui sont nécessaires au fonctionnement de notre site et à la fourniture de nos services. Nous utilisons des cookies de performance pour collecter des statistiques anonymes afin de comprendre comment les clients utilisent notre site et d’apporter des améliorations. Les cookies essentiels ne peuvent pas être désactivés, mais vous pouvez cliquer sur « Personnaliser » ou « Refuser » pour refuser les cookies de performance.

Si vous êtes d’accord, AWS et les tiers approuvés utiliseront également des cookies pour fournir des fonctionnalités utiles au site, mémoriser vos préférences et afficher du contenu pertinent, y compris des publicités pertinentes. Pour accepter ou refuser tous les cookies non essentiels, cliquez sur « Accepter » ou « Refuser ». Pour effectuer des choix plus détaillés, cliquez sur « Personnaliser ».

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 - Recommandations AWS

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.

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

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

Migration d'une application Perl ou Python avec SQL Server vers une application compatible avec Aurora PostgreSQL

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

Épopées

TâcheDescriptionCompétences requises

Suivez ces étapes de conversion de code pour migrer votre application vers PostgreSQL.

  1. Définissez des pilotes et des bibliothèques ODBC spécifiques à la base de données pour PostgreSQL. Par exemple, vous pouvez utiliser l'un des modules CPAN pour Perl et pyodbc, psycopg2 ou Python. SQLAlchemy

  2. Convertissez des objets de base de données à l'aide de ces bibliothèques pour vous connecter à Aurora PostgreSQL compatible.

  3. Appliquez des modifications de code dans les modules d'application existants pour obtenir des instructions T-SQL compatibles.

  4. Réécrivez les appels de fonction et les procédures stockées spécifiques à la base de données dans le code de l'application.

  5. Gérez les modifications apportées aux variables de votre application et à leurs types de données utilisés pour les requêtes SQL en ligne.

  6. Gérez les fonctions incompatibles spécifiques à la base de données.

  7. end-to-endTest complet du code d'application converti pour la migration de base de données.

  8. Comparez les résultats de Microsoft SQL Server à ceux de l'application que vous avez migrée vers PostgreSQL.

  9. Réalisez une analyse comparative des performances des applications entre Microsoft SQL Server et PostgreSQL.

  10. Révisez les procédures stockées ou les instructions T-SQL en ligne appelées par l'application pour améliorer les performances.

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 :

  • Consultez la documentation de PostgreSQL pour vous assurer que toutes vos modifications sont compatibles avec le standard PostgreSQL.

  • Vérifiez les valeurs entières et flottantes pour les colonnes.

  • Identifiez le nombre de lignes insérées, mises à jour et extraites, ainsi que les noms des colonnes et les horodatages. Vous pouvez utiliser un utilitaire de comparaison ou écrire un script pour automatiser ces vérifications.

  • Effectuez des contrôles de performance pour les instructions SQL intégrées de grande taille et vérifiez les performances globales de l'application.

  • Vérifiez que les erreurs sont correctement gérées pour les opérations de base de données et que vous quittez le programme correctement en utilisant plusieurs blocs try/catch.

  • Vérifiez que les processus de journalisation appropriés sont en place.

Développeur d’applications

Migrez votre référentiel d'applications vers PostgreSQL : étapes de haut niveau

TâcheDescriptionCompétences requises

Suivez ces étapes de conversion de code pour migrer votre application vers PostgreSQL.

  1. Définissez des pilotes et des bibliothèques ODBC spécifiques à la base de données pour PostgreSQL. Par exemple, vous pouvez utiliser l'un des modules CPAN pour Perl et pyodbc, psycopg2 ou Python. SQLAlchemy

  2. Convertissez des objets de base de données à l'aide de ces bibliothèques pour vous connecter à Aurora PostgreSQL compatible.

  3. Appliquez des modifications de code dans les modules d'application existants pour obtenir des instructions T-SQL compatibles.

  4. Réécrivez les appels de fonction et les procédures stockées spécifiques à la base de données dans le code de l'application.

  5. Gérez les modifications apportées aux variables de votre application et à leurs types de données utilisés pour les requêtes SQL en ligne.

  6. Gérez les fonctions incompatibles spécifiques à la base de données.

  7. end-to-endTest complet du code d'application converti pour la migration de base de données.

  8. Comparez les résultats de Microsoft SQL Server à ceux de l'application que vous avez migrée vers PostgreSQL.

  9. Réalisez une analyse comparative des performances des applications entre Microsoft SQL Server et PostgreSQL.

  10. Révisez les procédures stockées ou les instructions T-SQL en ligne appelées par l'application pour améliorer les performances.

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 :

  • Consultez la documentation de PostgreSQL pour vous assurer que toutes vos modifications sont compatibles avec le standard PostgreSQL.

  • Vérifiez les valeurs entières et flottantes pour les colonnes.

  • Identifiez le nombre de lignes insérées, mises à jour et extraites, ainsi que les noms des colonnes et les horodatages. Vous pouvez utiliser un utilitaire de comparaison ou écrire un script pour automatiser ces vérifications.

  • Effectuez des contrôles de performance pour les instructions SQL intégrées de grande taille et vérifiez les performances globales de l'application.

  • Vérifiez que les erreurs sont correctement gérées pour les opérations de base de données et que vous quittez le programme correctement en utilisant plusieurs blocs try/catch.

  • Vérifiez que les processus de journalisation appropriés sont en place.

Développeur d’applications
TâcheDescriptionCompé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 :

  • Identifiez tous les objets de connexion dans le code.

  • Identifiez toutes les requêtes SQL en ligne incompatibles (telles que les instructions T-SQL et les procédures stockées) et analysez les modifications requises.

  • Consultez la documentation de votre code et suivez le flux de contrôle pour comprendre les fonctionnalités du code. Cela vous sera utile ultérieurement lorsque vous testerez l'application pour des comparaisons de performances ou de charge.

  • Comprenez l'objectif de l'application afin de pouvoir la tester efficacement après la conversion de la base de données. La plupart des applications Python susceptibles d'être converties par des migrations de bases de données sont soit des flux qui chargent des données provenant d'autres sources dans des tables de base de données, soit des extracteurs qui extraient les données des tables et les transforment en différents formats de sortie (tels que CSV, JSON ou fichiers plats) adaptés à la création de rapports ou aux appels d'API pour effectuer des validations. 

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.

import pyodbc .... try: conn_string = "Driver=ODBC Driver 17 for SQL Server;UID={};PWD={};Server={};Database={}".format (conn_user, conn_password, conn_server, conn_database) conn = pyodbc.connect(conn_string) cur = conn.cursor() result = cur.execute(query_string) for row in result: print (row) except Exception as e: print(str(e))

Convertissez la connexion à la base de données pour qu'elle prenne en charge PostgreSQL comme suit.

import pyodbc import psycopg2 .... try: conn_string = ‘postgresql+psycopg2://’+ conn_user+’:’+conn_password+’@’+conn_server+’/’+conn_database conn = pyodbc.connect(conn_string, connect_args={‘options’:’-csearch_path=dbo’}) cur = conn.cursor() result = cur.execute(query_string) for row in result: print (row) except Exception as e: print(str(e))
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.

dtype = “type1” stm = ‘“SELECT TOP 1 searchcode FROM TypesTable (NOLOCK) WHERE code=”’ + “’” + str(dtype) + “’” # For Microsoft SQL Server Database Connection engine = create_engine(‘mssql+pyodbc:///?odbc_connect=%s’ % urllib.parse.quote_plus(conn_string), connect_args={‘connect_timeout’:login_timeout}) conn = engine_connect() rs = conn.execute(stm) for row in rs: print(row)

Après la conversion, la requête SQL en ligne compatible avec PostgreSQL se présente comme suit.

dtype = “type1” stm = ‘“SELECT searchcode FROM TypesTable WHERE code=”’ + “’” + str(dtype) + “’ LIMIT 1” # For PostgreSQL Database Connection engine = create_engine(‘postgres+psycopg2://%s’ %conn_string, connect_args={‘connect_timeout’:login_timeout}) conn = engine.connect() rs = conn.execute(stm) for row in rs: print(row)
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.

query = ‘“SELECT id from equity e join issues i on e.permId=i.permId where e.id’” query += get_id_filter(ids) + “ e.id is NOT NULL

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 :

  • Vérifiez la syntaxe globale (par exemple, la syntaxe de l'SELECTinstruction contenant une JOIN clause).

  • Vérifiez toutes les variables ou les noms de colonnes utilisés dans la requête, tels que i etid.

  • Vérifiez les fonctions, les arguments et les valeurs de retour utilisés dans la requête (par exemple, get_id_filter et son argumentids).

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 fetchone() ou fetchall() pour récupérer le jeu de résultats de la base de données. Vous pouvez également utiliser fetchmany(size) et spécifier le nombre d'enregistrements à renvoyer à partir de l'ensemble de résultats. Pour ce faire, vous pouvez utiliser l'objet de connexion pyodbc comme indiqué dans l'exemple suivant.

pyodbc (Microsoft SQL Server)

import pyodbc server = 'tcp:myserver.database.windows.net' database = 'exampledb' username = 'exampleusername' password = 'examplepassword' conn = pyodbc.connect('DRIVER={ODBC Driver 17 for SQL Server};SERVER='+server+';DATABASE='+database+';UID='+username+';PWD='+ password) cursor = conn.cursor() cursor.execute("SELECT * FROM ITEMS") row = cursor.fetchone() while row: print(row[0]) row = cursor.fetchone()

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)

import psycopg2 query = "SELECT * FROM ITEMS;" //Initialize variables host=dbname=user=password=port=sslmode=connect_timeout="" connstring = "host='{host}' dbname='{dbname}' user='{user}' \ password='{password}'port='{port}'".format(host=host,dbname=dbname,\ user=user,password=password,port=port) conn = psycopg2.connect(connstring) cursor = conn.cursor() cursor.execute(query) column_names = [column[0] for column in cursor.description] print("Column Names: ", column_names) print("Column values: " for row in cursor: print("itemid :", row[0]) print("itemdescrption :", row[1]) print("itemprice :", row[3]))

SQLAlchemy (Compatible avec Aurora PostgreSQL)

from sqlalchemy import create_engine from pandas import DataFrame conn_string = 'postgresql://core:database@localhost:5432/exampledatabase' engine = create_engine(conn_string) conn = engine.connect() dataid = 1001 result = conn.execute("SELECT * FROM ITEMS") df = DataFrame(result.fetchall()) df.columns = result.keys() df = pd.DataFrame() engine.connect() df = pd.read_sql_query(sql_query, engine, coerce_float=False) print(“df=”, df)
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 (bcpau lieu deCOPY) et des modifications similaires, elle doit être testée avec soin pendant et après la migration de l'application. Vérifiez :

  • Conditions d'erreur et gestion 

  • Toute anomalie d'enregistrement après la migration

  • Enregistrer les mises à jour ou les suppressions

  • Temps nécessaire pour exécuter l'application 

Développeur d’applications

Analyser et mettre à jour votre application — Base de code Python

TâcheDescriptionCompé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 :

  • Identifiez tous les objets de connexion dans le code.

  • Identifiez toutes les requêtes SQL en ligne incompatibles (telles que les instructions T-SQL et les procédures stockées) et analysez les modifications requises.

  • Consultez la documentation de votre code et suivez le flux de contrôle pour comprendre les fonctionnalités du code. Cela vous sera utile ultérieurement lorsque vous testerez l'application pour des comparaisons de performances ou de charge.

  • Comprenez l'objectif de l'application afin de pouvoir la tester efficacement après la conversion de la base de données. La plupart des applications Python susceptibles d'être converties par des migrations de bases de données sont soit des flux qui chargent des données provenant d'autres sources dans des tables de base de données, soit des extracteurs qui extraient les données des tables et les transforment en différents formats de sortie (tels que CSV, JSON ou fichiers plats) adaptés à la création de rapports ou aux appels d'API pour effectuer des validations. 

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.

import pyodbc .... try: conn_string = "Driver=ODBC Driver 17 for SQL Server;UID={};PWD={};Server={};Database={}".format (conn_user, conn_password, conn_server, conn_database) conn = pyodbc.connect(conn_string) cur = conn.cursor() result = cur.execute(query_string) for row in result: print (row) except Exception as e: print(str(e))

Convertissez la connexion à la base de données pour qu'elle prenne en charge PostgreSQL comme suit.

import pyodbc import psycopg2 .... try: conn_string = ‘postgresql+psycopg2://’+ conn_user+’:’+conn_password+’@’+conn_server+’/’+conn_database conn = pyodbc.connect(conn_string, connect_args={‘options’:’-csearch_path=dbo’}) cur = conn.cursor() result = cur.execute(query_string) for row in result: print (row) except Exception as e: print(str(e))
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.

dtype = “type1” stm = ‘“SELECT TOP 1 searchcode FROM TypesTable (NOLOCK) WHERE code=”’ + “’” + str(dtype) + “’” # For Microsoft SQL Server Database Connection engine = create_engine(‘mssql+pyodbc:///?odbc_connect=%s’ % urllib.parse.quote_plus(conn_string), connect_args={‘connect_timeout’:login_timeout}) conn = engine_connect() rs = conn.execute(stm) for row in rs: print(row)

Après la conversion, la requête SQL en ligne compatible avec PostgreSQL se présente comme suit.

dtype = “type1” stm = ‘“SELECT searchcode FROM TypesTable WHERE code=”’ + “’” + str(dtype) + “’ LIMIT 1” # For PostgreSQL Database Connection engine = create_engine(‘postgres+psycopg2://%s’ %conn_string, connect_args={‘connect_timeout’:login_timeout}) conn = engine.connect() rs = conn.execute(stm) for row in rs: print(row)
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.

query = ‘“SELECT id from equity e join issues i on e.permId=i.permId where e.id’” query += get_id_filter(ids) + “ e.id is NOT NULL

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 :

  • Vérifiez la syntaxe globale (par exemple, la syntaxe de l'SELECTinstruction contenant une JOIN clause).

  • Vérifiez toutes les variables ou les noms de colonnes utilisés dans la requête, tels que i etid.

  • Vérifiez les fonctions, les arguments et les valeurs de retour utilisés dans la requête (par exemple, get_id_filter et son argumentids).

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 fetchone() ou fetchall() pour récupérer le jeu de résultats de la base de données. Vous pouvez également utiliser fetchmany(size) et spécifier le nombre d'enregistrements à renvoyer à partir de l'ensemble de résultats. Pour ce faire, vous pouvez utiliser l'objet de connexion pyodbc comme indiqué dans l'exemple suivant.

pyodbc (Microsoft SQL Server)

import pyodbc server = 'tcp:myserver.database.windows.net' database = 'exampledb' username = 'exampleusername' password = 'examplepassword' conn = pyodbc.connect('DRIVER={ODBC Driver 17 for SQL Server};SERVER='+server+';DATABASE='+database+';UID='+username+';PWD='+ password) cursor = conn.cursor() cursor.execute("SELECT * FROM ITEMS") row = cursor.fetchone() while row: print(row[0]) row = cursor.fetchone()

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)

import psycopg2 query = "SELECT * FROM ITEMS;" //Initialize variables host=dbname=user=password=port=sslmode=connect_timeout="" connstring = "host='{host}' dbname='{dbname}' user='{user}' \ password='{password}'port='{port}'".format(host=host,dbname=dbname,\ user=user,password=password,port=port) conn = psycopg2.connect(connstring) cursor = conn.cursor() cursor.execute(query) column_names = [column[0] for column in cursor.description] print("Column Names: ", column_names) print("Column values: " for row in cursor: print("itemid :", row[0]) print("itemdescrption :", row[1]) print("itemprice :", row[3]))

SQLAlchemy (Compatible avec Aurora PostgreSQL)

from sqlalchemy import create_engine from pandas import DataFrame conn_string = 'postgresql://core:database@localhost:5432/exampledatabase' engine = create_engine(conn_string) conn = engine.connect() dataid = 1001 result = conn.execute("SELECT * FROM ITEMS") df = DataFrame(result.fetchall()) df.columns = result.keys() df = pd.DataFrame() engine.connect() df = pd.read_sql_query(sql_query, engine, coerce_float=False) print(“df=”, df)
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 (bcpau lieu deCOPY) et des modifications similaires, elle doit être testée avec soin pendant et après la migration de l'application. Vérifiez :

  • Conditions d'erreur et gestion 

  • Toute anomalie d'enregistrement après la migration

  • Enregistrer les mises à jour ou les suppressions

  • Temps nécessaire pour exécuter l'application 

Développeur d’applications
TâcheDescriptionCompé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 :

  • Tout code INI ou basé sur la configuration

  • Pilotes Perl standard ODBC (Open Database Connectivity) spécifiques à la base de données ou tout autre pilote personnalisé

  • Modifications de code requises pour les requêtes en ligne et T-SQL

  • Interactions entre différents modules Perl (par exemple, un seul objet de connexion ODBC Perl appelé ou utilisé par plusieurs composants fonctionnels)

  • Gestion des ensembles de données et des ensembles de résultats

  • Bibliothèques Perl externes et dépendantes

  • Tous APIs ceux utilisés dans l'application

  • Compatibilité des versions de Perl et compatibilité des pilotes avec Aurora PostgreSQL compatible

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. L'exemple suivant se connecte à Aurora PostgreSQL compatible à l'adresse. exampletest-aurorapg-database.cluster-sampleclusture.us-east.-rds.amazonaws.com

#!/usr/bin/perl use DBI; use strict; my $driver = "Pg"; my $hostname = “exampletest-aurorapg-database-sampleclusture.us-east.rds.amazonaws.com” my $dsn = "DBI:$driver: dbname = $hostname;host = 127.0.0.1;port = 5432"; my $username = "postgres"; my $password = "pass123"; $dbh = DBI->connect("dbi:Pg:dbname=$hostname;host=$host;port=$port;options=$options", $username, $password, {AutoCommit => 0, RaiseError => 1, PrintError => 0} );
Développeur d’applications

Remplacez les requêtes SQL en ligne par PostgreSQL.

Votre application peut comporter des requêtes SQL en ligne avecSELECT, DELETEUPDATE, et des instructions similaires qui incluent des clauses de requête non prises en charge par PostgreSQL. Par exemple, les mots clés de requête tels que TOP et NOLOCK ne sont pas pris en charge dans PostgreSQL. Les exemples suivants montrent comment vous pouvez gérer les variables TOP booléennes et NOLOCK les variables booléennes.

Dans SQL Server :

$sqlStr = $sqlStr . "WHERE a.student_id in (SELECT TOP $numofRecords c_student_id \ FROM active_student_record b WITH (NOLOCK) \ INNER JOIN student_contributor c WITH (NOLOCK) on c.contributor_id = b.c_st)

Pour PostgreSQL, convertissez en :

$sqlStr = $sqlStr . "WHERE a.student_id in (SELECT TOP $numofRecords c_student_id \ FROM active_student_record b INNER JOIN student_contributor c \ on c.contributor_id = b.c_student_contr_id WHERE b_current_1 is true \ LIMIT $numofRecords)"
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 :

  • Si la table existe, ne la créez pas ; effectuez un traitement.

  • Si la table n'existe pas, créez-la et effectuez également un traitement.

Voici un exemple de gestion des variables, suivi des requêtes SQL Server et PostgreSQL pour ce cas d'utilisation.

my $tableexists = db_read( arg 1, $sql_qry, undef, 'writer'); my $table_already_exists = $tableexists->[0]{table_exists}; if ($table_already_exists){ # do some thing } else { # do something else }

Serveur SQL :

my $sql_qry = “SELECT OBJECT_ID('$backendTable', 'U') table_exists", undef, 'writer')";

PostgreSQL :

my $sql_qry = “SELECT TO_REGCLASS('$backendTable', 'U') table_exists", undef, 'writer')";

L'exemple suivant utilise une variable Perl dans le SQL en ligne, qui exécute une SELECT instruction avec un JOIN pour récupérer la clé primaire de la table et la position de la colonne clé.

Serveur SQL :

my $sql_qry = "SELECT column_name', character_maxi mum_length \ FROM INFORMATION_SCHEMA.COLUMNS \ WHERE TABLE_SCHEMA='$example_schemaInfo' \ AND TABLE_NAME='$example_table' \ AND DATA_TYPE IN ('varchar','nvarchar');";

PostgreSQL :

my $sql_qry = "SELECT c1.column_name, c1.ordinal_position \ FROM information_schema.key_column_usage AS c LEFT \ JOIN information_schema.table_constraints AS t1 \ ON t1.constraint_name = c1.constraint_name \ WHERE t1.table_name = $example_schemaInfo'.'$example_table’ \ AND t1.constraint_type = 'PRIMARY KEY' ;";
Développeur d’applications

Analyser et mettre à jour votre application — Base de code Perl

TâcheDescriptionCompé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 :

  • Tout code INI ou basé sur la configuration

  • Pilotes Perl standard ODBC (Open Database Connectivity) spécifiques à la base de données ou tout autre pilote personnalisé

  • Modifications de code requises pour les requêtes en ligne et T-SQL

  • Interactions entre différents modules Perl (par exemple, un seul objet de connexion ODBC Perl appelé ou utilisé par plusieurs composants fonctionnels)

  • Gestion des ensembles de données et des ensembles de résultats

  • Bibliothèques Perl externes et dépendantes

  • Tous APIs ceux utilisés dans l'application

  • Compatibilité des versions de Perl et compatibilité des pilotes avec Aurora PostgreSQL compatible

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. L'exemple suivant se connecte à Aurora PostgreSQL compatible à l'adresse. exampletest-aurorapg-database.cluster-sampleclusture.us-east.-rds.amazonaws.com

#!/usr/bin/perl use DBI; use strict; my $driver = "Pg"; my $hostname = “exampletest-aurorapg-database-sampleclusture.us-east.rds.amazonaws.com” my $dsn = "DBI:$driver: dbname = $hostname;host = 127.0.0.1;port = 5432"; my $username = "postgres"; my $password = "pass123"; $dbh = DBI->connect("dbi:Pg:dbname=$hostname;host=$host;port=$port;options=$options", $username, $password, {AutoCommit => 0, RaiseError => 1, PrintError => 0} );
Développeur d’applications

Remplacez les requêtes SQL en ligne par PostgreSQL.

Votre application peut comporter des requêtes SQL en ligne avecSELECT, DELETEUPDATE, et des instructions similaires qui incluent des clauses de requête non prises en charge par PostgreSQL. Par exemple, les mots clés de requête tels que TOP et NOLOCK ne sont pas pris en charge dans PostgreSQL. Les exemples suivants montrent comment vous pouvez gérer les variables TOP booléennes et NOLOCK les variables booléennes.

Dans SQL Server :

$sqlStr = $sqlStr . "WHERE a.student_id in (SELECT TOP $numofRecords c_student_id \ FROM active_student_record b WITH (NOLOCK) \ INNER JOIN student_contributor c WITH (NOLOCK) on c.contributor_id = b.c_st)

Pour PostgreSQL, convertissez en :

$sqlStr = $sqlStr . "WHERE a.student_id in (SELECT TOP $numofRecords c_student_id \ FROM active_student_record b INNER JOIN student_contributor c \ on c.contributor_id = b.c_student_contr_id WHERE b_current_1 is true \ LIMIT $numofRecords)"
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 :

  • Si la table existe, ne la créez pas ; effectuez un traitement.

  • Si la table n'existe pas, créez-la et effectuez également un traitement.

Voici un exemple de gestion des variables, suivi des requêtes SQL Server et PostgreSQL pour ce cas d'utilisation.

my $tableexists = db_read( arg 1, $sql_qry, undef, 'writer'); my $table_already_exists = $tableexists->[0]{table_exists}; if ($table_already_exists){ # do some thing } else { # do something else }

Serveur SQL :

my $sql_qry = “SELECT OBJECT_ID('$backendTable', 'U') table_exists", undef, 'writer')";

PostgreSQL :

my $sql_qry = “SELECT TO_REGCLASS('$backendTable', 'U') table_exists", undef, 'writer')";

L'exemple suivant utilise une variable Perl dans le SQL en ligne, qui exécute une SELECT instruction avec un JOIN pour récupérer la clé primaire de la table et la position de la colonne clé.

Serveur SQL :

my $sql_qry = "SELECT column_name', character_maxi mum_length \ FROM INFORMATION_SCHEMA.COLUMNS \ WHERE TABLE_SCHEMA='$example_schemaInfo' \ AND TABLE_NAME='$example_table' \ AND DATA_TYPE IN ('varchar','nvarchar');";

PostgreSQL :

my $sql_qry = "SELECT c1.column_name, c1.ordinal_position \ FROM information_schema.key_column_usage AS c LEFT \ JOIN information_schema.table_constraints AS t1 \ ON t1.constraint_name = c1.constraint_name \ WHERE t1.table_name = $example_schemaInfo'.'$example_table’ \ AND t1.constraint_type = 'PRIMARY KEY' ;";
Développeur d’applications
TâcheDescriptionCompé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.

  • Qualifiez les objets de base de données utilisés par votre application avec des noms de schéma nouveaux et appropriés.

  • Gérez les opérateurs LIKE pour une correspondance distinguant majuscules/minuscules avec la fonctionnalité de classement de PostgreSQL.

  • Gérez les fonctions spécifiques à la base de données non prises en chargeDATEDIFF, telles queDATEADD,GETDATE,CONVERT, et CAST les opérateurs. Pour des fonctions compatibles avec PostgreSQL équivalentes, consultez la section Fonctions SQL natives ou intégrées dans la section Informations supplémentaires. 

  • Gérez les valeurs booléennes dans les instructions de comparaison.

  • Gérez les valeurs renvoyées par les fonctions. Il peut s'agir d'ensembles d'enregistrements, de cadres de données, de variables et de valeurs booléennes. Gérez-les conformément aux exigences de votre application et pour prendre en charge PostgreSQL.

  • Gérez les blocs anonymes (tels queBEGIN TRAN) avec de nouvelles fonctions PostgreSQL définies par l'utilisateur.

  • Convertissez les encarts groupés en lignes. L'équivalent pour PostgreSQL de l'utilitaire SQL Server Bulk copy bcp (), qui est appelé depuis l'intérieur de l'application, est. COPY

  • Convertissez les opérateurs de concaténation de colonnes. SQL Server utilise + la concaténation de chaînes, mais PostgreSQL l'utilise. ||

Développeur d’applications

Apportez des modifications supplémentaires à votre application basée sur Perl ou Python pour prendre en charge PostgreSQL

TâcheDescriptionCompé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.

  • Qualifiez les objets de base de données utilisés par votre application avec des noms de schéma nouveaux et appropriés.

  • Gérez les opérateurs LIKE pour une correspondance distinguant majuscules/minuscules avec la fonctionnalité de classement de PostgreSQL.

  • Gérez les fonctions spécifiques à la base de données non prises en chargeDATEDIFF, telles queDATEADD,GETDATE,CONVERT, et CAST les opérateurs. Pour des fonctions compatibles avec PostgreSQL équivalentes, consultez la section Fonctions SQL natives ou intégrées dans la section Informations supplémentaires. 

  • Gérez les valeurs booléennes dans les instructions de comparaison.

  • Gérez les valeurs renvoyées par les fonctions. Il peut s'agir d'ensembles d'enregistrements, de cadres de données, de variables et de valeurs booléennes. Gérez-les conformément aux exigences de votre application et pour prendre en charge PostgreSQL.

  • Gérez les blocs anonymes (tels queBEGIN TRAN) avec de nouvelles fonctions PostgreSQL définies par l'utilisateur.

  • Convertissez les encarts groupés en lignes. L'équivalent pour PostgreSQL de l'utilitaire SQL Server Bulk copy bcp (), qui est appelé depuis l'intérieur de l'application, est. COPY

  • Convertissez les opérateurs de concaténation de colonnes. SQL Server utilise + la concaténation de chaînes, mais PostgreSQL l'utilise. ||

Développeur d’applications
TâcheDescriptionCompé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

Améliorez les performances

TâcheDescriptionCompé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

CAST 

Convertit une valeur d'un type de données en un autre.

PostgreSQL type :: operator

GETDATE()

Renvoie la date et l'heure actuelles du système de base de données, dans un YYYY-MM-DD hh:mm:ss.mmm format.

CLOCK_TIMESTAMP

DATEADD

Ajoute un intervalle heure/date à une date.

INTERVALexpression

CONVERT

Convertit une valeur dans un format de données spécifique.

TO_CHAR

DATEDIFF

Renvoie la différence entre deux dates.

DATE_PART

TOP

Limite le nombre de lignes d'un ensemble SELECT de résultats.

LIMIT/FETCH

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

my $sql_qry1= my $sql_qry2 = my $sqlqry = "BEGIN TRAN $sql_qry1 $sql_qry2 if @\@error !=0 ROLLBACK TRAN else COMIT TRAN";
my $sql_qry1= my $sql_qry2 = my $sql_qry = " DO \$\$ BEGIN $header_sql $content_sql END \$\$";

 

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 SQLAlchemyPynomODB. Cela permettra d'interroger et de manipuler facilement les données d'une base de données en utilisant un paradigme orienté objet.

ConfidentialitéConditions d'utilisation du sitePréférences de cookies
© 2025, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.