Seleccione sus preferencias de cookies

Usamos cookies esenciales y herramientas similares que son necesarias para proporcionar nuestro sitio y nuestros servicios. Usamos cookies de rendimiento para recopilar estadísticas anónimas para que podamos entender cómo los clientes usan nuestro sitio y hacer mejoras. Las cookies esenciales no se pueden desactivar, pero puede hacer clic en “Personalizar” o “Rechazar” para rechazar las cookies de rendimiento.

Si está de acuerdo, AWS y los terceros aprobados también utilizarán cookies para proporcionar características útiles del sitio, recordar sus preferencias y mostrar contenido relevante, incluida publicidad relevante. Para aceptar o rechazar todas las cookies no esenciales, haga clic en “Aceptar” o “Rechazar”. Para elegir opciones más detalladas, haga clic en “Personalizar”.

Cambie las aplicaciones de Python y Perl para que admitan la migración de bases de datos de Microsoft SQL Server a una edición compatible con PostgreSQL de Amazon Aurora - Recomendaciones de AWS

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Cambie las aplicaciones de Python y Perl para que admitan la migración de bases de datos de Microsoft SQL Server a una edición compatible con PostgreSQL de Amazon Aurora

Creado por Dwarika Patra (AWS) y Deepesh Jayaprakash (AWS)

Resumen

Este patrón describe los cambios en los repositorios de aplicaciones que pueden ser necesarios al migrar bases de datos de Microsoft SQL Server a una edición compatible con Amazon Aurora PostgreSQL. El patrón asume que estas aplicaciones están basadas en Python o en Perl, y proporciona instrucciones independientes para estos lenguajes de secuencias de comandos.

La migración de bases de datos de SQL Server a una versión compatible con Aurora PostgreSQL implica la conversión de esquemas, la conversión de objetos de base de datos, la migración de datos y la carga de datos. Debido a las diferencias entre PostgreSQL y SQL Server (en relación con los tipos de datos, los objetos de conexión, la sintaxis y la lógica), la tarea de migración más difícil consiste en realizar los cambios necesarios en la base de código para que funcione correctamente con PostgreSQL.

Para una aplicación basada en Python, los objetos y clases de conexión están dispersos por todo el sistema. Además, la base de código de Python puede usar varias bibliotecas para conectarse a la base de datos. Si la interfaz de conexión a la base de datos cambia, los objetos que ejecutan las consultas en línea de la aplicación también requieren cambios.

En el caso de una aplicación basada en Perl, los cambios se refieren a los objetos de conexión, los controladores de conexión a la base de datos, las sentencias SQL integradas estáticas y dinámicas y la forma en que la aplicación gestiona las consultas DML dinámicas y complejas y los conjuntos de resultados.

Al migrar la aplicación, también puede considerar posibles mejoras en AWS, como reemplazar el servidor FTP por el acceso a Amazon Simple Storage Service (Amazon S3).

El proceso de migración de la aplicación implica los siguientes desafíos:

  • Objetos de conexión. Si los objetos de conexión están dispersos en el código con varias bibliotecas y llamadas a funciones, es posible que tenga que encontrar una forma generalizada de cambiarlos para que sean compatibles con PostgreSQL.

  • Gestión de errores o excepciones durante la recuperación o actualización de registros. Si tiene operaciones condicionales de creación, lectura, actualización y eliminación (CRUD) en la base de datos que devuelven variables, conjuntos de resultados o marcos de datos, cualquier error o excepción puede provocar errores de aplicación con efectos en cascada. Estas deben gestionarse con cuidado, con las validaciones adecuadas y ahorrándose puntos. Uno de estos puntos de ahorro es llamar a consultas SQL integradas de gran tamaño o a objetos de bases de datos dentro de bloques BEGIN...EXCEPTION...END.

  • Controlar las transacciones y su validación. Esto incluye las confirmaciones y anulaciones manuales y automáticas. El controlador PostgreSQL para Perl requiere que siempre se establezca de forma explícita el atributo autocommit.

  • Manejo de consultas SQL dinámicas. Esto requiere una sólida comprensión de la lógica de consultas y pruebas iterativas para garantizar que las consultas funcionen según lo esperado.

  • Desempeño. Debe asegurarse de que los cambios en el código no reduzcan el rendimiento de la aplicación.

Este patrón explica el proceso de conversión en detalle.

Requisitos previos y limitaciones

Requisitos previos 

  • Conocimientos prácticos de la sintaxis de Python y Perl.

  • Conocimientos básicos de SQL Server y PostgreSQL.

  • Comprensión de la arquitectura de aplicaciones existente.

  • Acceda al código de su aplicación, a la base de datos de SQL Server y a la base de datos PostgreSQL.

  • Acceda al entorno de desarrollo Windows o Linux (u otro tipo de Unix) con credenciales para desarrollar, probar y validar los cambios en las aplicaciones.

  • Para una aplicación basada en Python, las bibliotecas de Python estándar que pueda necesitar la aplicación, como Pandas para gestionar marcos de datos y psycopg2 o para conexiones a bases de datos. SQLAlchemy

  • Para una aplicación basada en Perl, se requieren paquetes de Perl con bibliotecas o módulos dependientes. El módulo Comprehensive Perl Archive Network (CPAN) es compatible con la mayoría de los requisitos de las aplicaciones.

  • Todas las bibliotecas o módulos personalizados dependientes necesarios. 

  • Credenciales de bases de datos para acceso de lectura a SQL Server y acceso de lectura y escritura a Aurora.

  • PostgreSQL para validar y depurar los cambios en las aplicaciones con los servicios y los usuarios.

  • Acceso a herramientas de desarrollo durante la migración de aplicaciones, como Visual Studio Code, Sublime Text o pgAdmin.

Limitaciones

  • Algunas versiones, módulos, bibliotecas y paquetes de Python o Perl no son compatibles con el entorno de nube.

  • Algunas bibliotecas y marcos de terceros utilizados para SQL Server no se pueden reemplazar para admitir la migración a PostgreSQL. 

  • Las variaciones de rendimiento pueden requerir cambios en la aplicación, en las consultas de Transact-SQL (T-SQL) integradas, en las funciones de las bases de datos y en los procedimientos almacenados.

  • PostgreSQL admite nombres en minúsculas para nombres de tablas, nombres de columnas y otros objetos de bases de datos. 

  • Algunos tipos de datos, como las columnas UUID, se almacenan únicamente en minúsculas. Las aplicaciones Python y Perl deben gestionar estas diferencias entre mayúsculas y minúsculas. 

  • Las diferencias de codificación de caracteres deben gestionarse con el tipo de datos correcto para las columnas de texto correspondientes de la base de datos PostgreSQL.                                

Versiones de producto

  • Python 3.6 o posterior (usa la versión compatible con su sistema operativo)

  • Perl 5.8.3 o posterior (utilice la versión compatible con su sistema operativo)

  • Aurora, compatible con PostgreSQL, edición 4.2 o posterior (consulte los detalles)

Arquitectura

Pila de tecnología de origen

  • Lenguaje de secuencias de comandos (programación de aplicaciones): Python 2.7 o posterior, o Perl 5.8 

  • Base de datos: Microsoft SQL Server versión 13

  • Sistema operativo: Red Hat Enterprise Linux (RHEL) 7 

Pila de tecnología de destino

  • Lenguaje de secuencias de comandos (programación de aplicaciones): Python 3.6 o posterior de Perl 

  • Base de datos: Compatible con Aurora PostgreSQL

  • Sistema operativo: RHEL 7 

Arquitectura de migración

Migración de una aplicación de Perl o Python con SQL Server a una aplicación compatible con Aurora PostgreSQL

Herramientas

Servicios y herramientas de AWS

  • La edición de Amazon Aurora compatible con PostgreSQL es un motor de bases de datos relacionales, completamente administrado, compatible con PostgreSQL y conforme a ACID, que combina la velocidad y la fiabilidad de las bases de datos comerciales de tecnología avanzada con la sencillez y la rentabilidad de las bases de datos de código abierto. Aurora PostgreSQL es un reemplazo instántaneo para PostgreSQL que simplifica y hace más rentable configurar, usar y escalar las implementaciones de PostgreSQL nuevas y existentes.

  • La interfaz de la línea de comandos de AWS (AWS CLI) es una herramienta de código abierto que le permite interactuar con los servicios de AWS mediante comandos en su intérprete de comandos de línea de comandos.

Otras herramientas

Epics

TareaDescripciónHabilidades requeridas

Siga estos pasos de conversión de código para migrar su aplicación a PostgreSQL.

  1. Configure bibliotecas y controladores ODBC específicos de la base de datos para PostgreSQL. Por ejemplo, puede usar uno de los módulos CPAN para Perl y pyodbc, psycopg2 o Python. SQLAlchemy

  2. Convierta los objetos de la base de datos mediante estas bibliotecas para conectarse a Aurora compatible con PostgreSQL.

  3. Aplique los cambios de código en los módulos de aplicación existentes para obtener sentencias T-SQL compatibles.

  4. Reescriba las llamadas a funciones específicas de la base de datos y los procedimientos almacenados en el código de la aplicación.

  5. Controle los cambios en las variables de la aplicación y sus tipos de datos que se utilizan para las consultas SQL en línea.

  6. Gestione funciones específicas de bases de datos incompatibles.

  7. end-to-endPruebas completas del código de aplicación convertido para la migración de bases de datos.

  8. Compare los resultados de Microsoft SQL Server con los de la aplicación que migró a PostgreSQL.

  9. Realice una evaluación comparativa del rendimiento de las aplicaciones entre Microsoft SQL Server y PostgreSQL.

  10. Revise los procedimientos almacenados o las sentencias T-SQL en línea solicitadas por la aplicación para mejorar el rendimiento.

Las siguientes epics proporcionan instrucciones detalladas para algunas de estas tareas de conversión para aplicaciones de Python y Perl.

Desarrollador de aplicaciones

Use una lista de verificación para cada paso de la migración.

Añada lo siguiente a la lista de verificación para cada paso de la migración de la aplicación, incluido el paso final:

  • Revise la documentación de PostgreSQL para asegurarse de que todos los cambios son compatibles con el estándar PostgreSQL.

  • Compruebe si hay valores enteros y flotantes en las columnas.

  • Identifique el número de filas insertadas, actualizadas y extraídas, junto con los nombres de las columnas y las marcas de fecha y hora. Puede utilizar una utilidad de diferencias o escribir un script para automatizar estas comprobaciones.

  • Realice las comprobaciones de rendimiento de las sentencias SQL integradas de gran tamaño y compruebe el rendimiento general de la aplicación.

  • Compruebe la correcta gestión de los errores en las operaciones de la base de datos y la correcta salida del programa mediante el uso de varios bloques try/catch.

  • Asegúrese de que se hayan implementado los procesos de registro adecuados.

Desarrollador de aplicaciones

Migración de su repositorio de aplicaciones a PostgreSQL: pasos de alto nivel

TareaDescripciónHabilidades requeridas

Siga estos pasos de conversión de código para migrar su aplicación a PostgreSQL.

  1. Configure bibliotecas y controladores ODBC específicos de la base de datos para PostgreSQL. Por ejemplo, puede usar uno de los módulos CPAN para Perl y pyodbc, psycopg2 o Python. SQLAlchemy

  2. Convierta los objetos de la base de datos mediante estas bibliotecas para conectarse a Aurora compatible con PostgreSQL.

  3. Aplique los cambios de código en los módulos de aplicación existentes para obtener sentencias T-SQL compatibles.

  4. Reescriba las llamadas a funciones específicas de la base de datos y los procedimientos almacenados en el código de la aplicación.

  5. Controle los cambios en las variables de la aplicación y sus tipos de datos que se utilizan para las consultas SQL en línea.

  6. Gestione funciones específicas de bases de datos incompatibles.

  7. end-to-endPruebas completas del código de aplicación convertido para la migración de bases de datos.

  8. Compare los resultados de Microsoft SQL Server con los de la aplicación que migró a PostgreSQL.

  9. Realice una evaluación comparativa del rendimiento de las aplicaciones entre Microsoft SQL Server y PostgreSQL.

  10. Revise los procedimientos almacenados o las sentencias T-SQL en línea solicitadas por la aplicación para mejorar el rendimiento.

Las siguientes epics proporcionan instrucciones detalladas para algunas de estas tareas de conversión para aplicaciones de Python y Perl.

Desarrollador de aplicaciones

Use una lista de verificación para cada paso de la migración.

Añada lo siguiente a la lista de verificación para cada paso de la migración de la aplicación, incluido el paso final:

  • Revise la documentación de PostgreSQL para asegurarse de que todos los cambios son compatibles con el estándar PostgreSQL.

  • Compruebe si hay valores enteros y flotantes en las columnas.

  • Identifique el número de filas insertadas, actualizadas y extraídas, junto con los nombres de las columnas y las marcas de fecha y hora. Puede utilizar una utilidad de diferencias o escribir un script para automatizar estas comprobaciones.

  • Realice las comprobaciones de rendimiento de las sentencias SQL integradas de gran tamaño y compruebe el rendimiento general de la aplicación.

  • Compruebe la correcta gestión de los errores en las operaciones de la base de datos y la correcta salida del programa mediante el uso de varios bloques try/catch.

  • Asegúrese de que se hayan implementado los procesos de registro adecuados.

Desarrollador de aplicaciones
TareaDescripciónHabilidades requeridas

Analice su base de código Python existente.

Su análisis debe incluir lo siguiente para facilitar el proceso de migración de la aplicación:

  • Identifique todos los objetos de conexión en el código.

  • Identifique todas las consultas SQL en línea incompatibles (como las sentencias T-SQL y los procedimientos almacenados) y analice los cambios necesarios.

  • Revise la documentación del código y realice un seguimiento del flujo de control para comprender la funcionalidad del código. Esto será útil más adelante, cuando pruebes la aplicación para comparar el rendimiento o la carga.

  • Comprenda el propósito de la aplicación para poder probarla eficazmente después de la conversión de la base de datos. La mayoría de las aplicaciones de Python que son aptas para la conversión con migraciones de bases de datos son fuentes que cargan datos de otras fuentes en tablas de bases de datos o extractores que recuperan datos de las tablas y los transforman en diferentes formatos de salida (como CSV, JSON o archivos planos) que son adecuados para crear informes o realizar llamadas a la API para realizar validaciones. 

Desarrollador de aplicaciones

Convierta sus conexiones de bases de datos para que sean compatibles con PostgreSQL.

La mayoría de las aplicaciones de Python utilizan la biblioteca pyodbc para conectarse con las bases de datos de SQL Server de la siguiente manera.

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))

Convierta la conexión de base de datos para que sea compatible con PostgreSQL de la siguiente manera.

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))
Desarrollador de aplicaciones

Cambie las consultas SQL en línea a PostgreSQL.

Convierta sus consultas SQL en línea a un formato compatible con PostgreSQL. Por ejemplo, la siguiente consulta de SQL Server recupera una cadena de una tabla.

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)

Tras la conversión, la consulta SQL en línea compatible con PostgreSQL tiene el siguiente aspecto.

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)
Desarrollador de aplicaciones

Gestione consultas SQL dinámicas.

El SQL dinámico puede estar presente en un script o en varios scripts de Python. Los ejemplos anteriores mostraron cómo utilizar la función de reemplazo de cadenas de Python para insertar variables con el fin de crear consultas SQL dinámicas. Un enfoque alternativo consiste en añadir variables a la cadena de consulta siempre que sea aplicable. 

En el ejemplo siguiente, la cadena de consulta se construye sobre la marcha en función de los valores devueltos por una función.

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

Estos tipos de consultas dinámicas son muy comunes durante la migración de aplicaciones. Siga estos pasos para gestionar consultas dinámicas:

  • Compruebe la sintaxis general (por ejemplo, la sintaxis de la sentencia SELECT con una cláusula JOIN).

  • Compruebe todos los nombres de variables o columnas utilizados en la consulta, como i y id.

  • Compruebe las funciones, los argumentos y los valores devueltos utilizados en la consulta (por ejemplo, get_id_filter y su argumento ids).

Desarrollador de aplicaciones

Gestione los conjuntos de resultados, las variables y los marcos de datos.

Para Microsoft SQL Server, se utilizan métodos de Python como fetchone() o fetchall() para recuperar el conjunto de resultados de la base de datos. También puede usar fetchmany(size) y especificar el número de registros que se van a devolver del conjunto de resultados. Para ello, puede utilizar el objeto de conexión pyodbc como se muestra en el siguiente ejemplo.

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()

En Aurora, para realizar tareas similares, como conectarse a PostgreSQL y obtener conjuntos de resultados, puede usar psycopg2 o. SQLAlchemy Estas bibliotecas de Python proporcionan el módulo de conexión y el objeto de cursor para recorrer los registros de la base de datos PostgreSQL, como se muestra en el siguiente ejemplo.

psycopg2 (Aurora compatible con 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 con 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)
Desarrollador de aplicaciones

Pruebe la aplicación durante y después de la migración.

La prueba de la aplicación Python migrada es un proceso continuo. Como la migración incluye cambios en los objetos de conexión (psycopg2 o SQLAlchemy), la gestión de errores, nuevas funciones (marcos de datos), cambios en el SQL en línea, funcionalidades de copia masiva (bcpen lugar deCOPY) y cambios similares, debe probarse detenidamente durante y después de la migración de la aplicación. Consultar si:

  • Condiciones y manejo del error 

  • Algún desajuste en los registros tras la migración

  • Actualizaciones o eliminaciones de registros

  • Tiempo necesario para poder ejecutar la aplicación 

Desarrollador de aplicaciones

Analice y actualice su aplicación: Base de código Python

TareaDescripciónHabilidades requeridas

Analice su base de código Python existente.

Su análisis debe incluir lo siguiente para facilitar el proceso de migración de la aplicación:

  • Identifique todos los objetos de conexión en el código.

  • Identifique todas las consultas SQL en línea incompatibles (como las sentencias T-SQL y los procedimientos almacenados) y analice los cambios necesarios.

  • Revise la documentación del código y realice un seguimiento del flujo de control para comprender la funcionalidad del código. Esto será útil más adelante, cuando pruebes la aplicación para comparar el rendimiento o la carga.

  • Comprenda el propósito de la aplicación para poder probarla eficazmente después de la conversión de la base de datos. La mayoría de las aplicaciones de Python que son aptas para la conversión con migraciones de bases de datos son fuentes que cargan datos de otras fuentes en tablas de bases de datos o extractores que recuperan datos de las tablas y los transforman en diferentes formatos de salida (como CSV, JSON o archivos planos) que son adecuados para crear informes o realizar llamadas a la API para realizar validaciones. 

Desarrollador de aplicaciones

Convierta sus conexiones de bases de datos para que sean compatibles con PostgreSQL.

La mayoría de las aplicaciones de Python utilizan la biblioteca pyodbc para conectarse con las bases de datos de SQL Server de la siguiente manera.

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))

Convierta la conexión de base de datos para que sea compatible con PostgreSQL de la siguiente manera.

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))
Desarrollador de aplicaciones

Cambie las consultas SQL en línea a PostgreSQL.

Convierta sus consultas SQL en línea a un formato compatible con PostgreSQL. Por ejemplo, la siguiente consulta de SQL Server recupera una cadena de una tabla.

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)

Tras la conversión, la consulta SQL en línea compatible con PostgreSQL tiene el siguiente aspecto.

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)
Desarrollador de aplicaciones

Gestione consultas SQL dinámicas.

El SQL dinámico puede estar presente en un script o en varios scripts de Python. Los ejemplos anteriores mostraron cómo utilizar la función de reemplazo de cadenas de Python para insertar variables con el fin de crear consultas SQL dinámicas. Un enfoque alternativo consiste en añadir variables a la cadena de consulta siempre que sea aplicable. 

En el ejemplo siguiente, la cadena de consulta se construye sobre la marcha en función de los valores devueltos por una función.

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

Estos tipos de consultas dinámicas son muy comunes durante la migración de aplicaciones. Siga estos pasos para gestionar consultas dinámicas:

  • Compruebe la sintaxis general (por ejemplo, la sintaxis de la sentencia SELECT con una cláusula JOIN).

  • Compruebe todos los nombres de variables o columnas utilizados en la consulta, como i y id.

  • Compruebe las funciones, los argumentos y los valores devueltos utilizados en la consulta (por ejemplo, get_id_filter y su argumento ids).

Desarrollador de aplicaciones

Gestione los conjuntos de resultados, las variables y los marcos de datos.

Para Microsoft SQL Server, se utilizan métodos de Python como fetchone() o fetchall() para recuperar el conjunto de resultados de la base de datos. También puede usar fetchmany(size) y especificar el número de registros que se van a devolver del conjunto de resultados. Para ello, puede utilizar el objeto de conexión pyodbc como se muestra en el siguiente ejemplo.

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()

En Aurora, para realizar tareas similares, como conectarse a PostgreSQL y obtener conjuntos de resultados, puede usar psycopg2 o. SQLAlchemy Estas bibliotecas de Python proporcionan el módulo de conexión y el objeto de cursor para recorrer los registros de la base de datos PostgreSQL, como se muestra en el siguiente ejemplo.

psycopg2 (Aurora compatible con 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 con 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)
Desarrollador de aplicaciones

Pruebe la aplicación durante y después de la migración.

La prueba de la aplicación Python migrada es un proceso continuo. Como la migración incluye cambios en los objetos de conexión (psycopg2 o SQLAlchemy), la gestión de errores, nuevas funciones (marcos de datos), cambios en el SQL en línea, funcionalidades de copia masiva (bcpen lugar deCOPY) y cambios similares, debe probarse detenidamente durante y después de la migración de la aplicación. Consultar si:

  • Condiciones y manejo del error 

  • Algún desajuste en los registros tras la migración

  • Actualizaciones o eliminaciones de registros

  • Tiempo necesario para poder ejecutar la aplicación 

Desarrollador de aplicaciones
TareaDescripciónHabilidades requeridas

Analice su base de código Perl existente.

Su análisis debe incluir lo siguiente para facilitar el proceso de migración de la aplicación. Debe identificar:

  • Cualquier código INI o basado en la configuración

  • Controladores Perl de Open Database Connectivity (ODBC) estándar para bases de datos específicos de bases de datos o cualquier controlador personalizado

  • Se requieren cambios de código para las consultas en línea y T-SQL

  • Interacciones entre varios módulos de Perl (por ejemplo, un único objeto de conexión ODBC de Perl al que varios componentes funcionales llaman o utilizan)

  • Manejo de conjuntos de datos y conjuntos de resultados

  • Bibliotecas de Perl externas y dependientes

  • Todas las APIs que se utilicen en la aplicación

  • Compatibilidad de versiones de Perl y compatibilidad de controladores con Aurora compatible con PostgreSQL

Desarrollador de aplicaciones

Convierta las conexiones de la aplicación Perl y el módulo DBI para que sean compatibles con PostgreSQL.

Las aplicaciones basadas en Perl suelen utilizar el módulo DBI de Perl, que es un módulo de acceso a bases de datos estándar para el lenguaje de programación Perl. Puede usar el mismo módulo DBI con controladores diferentes para SQL Server y PostgreSQL.

Para obtener más información sobre los módulos de Perl necesarios, las instalaciones y otras instrucciones, consulte la documentación de DBD::Pg. El siguiente ejemplo se conecta a Aurora compatible con PostgreSQL en 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} );
Desarrollador de aplicaciones

Cambie las consultas SQL en línea a PostgreSQL.

Es posible que su aplicación tenga consultas SQL en línea con SELECT, DELETE, UPDATE y sentencias similares que incluyan cláusulas de consulta que PostgreSQL no admite. Por ejemplo, consulte palabras clave como TOP y NOLOCK no se admiten en PostgreSQL. En los siguientes ejemplos, se muestra cómo se pueden gestionar TOP, NOLOCK y variables booleanas.

En 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)

Para PostgreSQL, conviértalo a:

$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)"
Desarrollador de aplicaciones

Gestione consultas SQL dinámicas y variables de Perl.

Las consultas SQL dinámicas son sentencias SQL que se crean durante el tiempo de ejecución de la aplicación. Estas consultas se crean de forma dinámica cuando la aplicación está en ejecución, en función de determinadas condiciones, por lo que el texto completo de la consulta no se conoce hasta el tiempo de ejecución. Un ejemplo es una aplicación de análisis financiero que analiza las 10 principales acciones a diario, y estas acciones cambian todos los días. Las tablas SQL se crean en función de los mejores resultados y los valores no se conocen hasta el tiempo de ejecución.

Supongamos que las consultas SQL en línea de este ejemplo se pasan a una función contenedora para obtener los resultados establecidos en una variable y, a continuación, una variable utiliza una condición para determinar si la tabla existe:

  • Si la tabla existe, no la cree; procésela.

  • Si la tabla no existe, créela y, a continuación, procésela.

A continuación, se muestra un ejemplo de gestión de variables, seguido de las consultas de SQL Server y PostgreSQL para este caso de uso.

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 }

SQL Server:

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')";

En el siguiente ejemplo, se utiliza una variable de Perl en SQL en línea, que ejecuta una sentencia SELECT con un JOIN para obtener la clave principal de la tabla y la posición de la columna clave.

SQL Server:

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' ;";
Desarrollador de aplicaciones

Analice y actualice su aplicación: base de código Perl

TareaDescripciónHabilidades requeridas

Analice su base de código Perl existente.

Su análisis debe incluir lo siguiente para facilitar el proceso de migración de la aplicación. Debe identificar:

  • Cualquier código INI o basado en la configuración

  • Controladores Perl de Open Database Connectivity (ODBC) estándar para bases de datos específicos de bases de datos o cualquier controlador personalizado

  • Se requieren cambios de código para las consultas en línea y T-SQL

  • Interacciones entre varios módulos de Perl (por ejemplo, un único objeto de conexión ODBC de Perl al que varios componentes funcionales llaman o utilizan)

  • Manejo de conjuntos de datos y conjuntos de resultados

  • Bibliotecas de Perl externas y dependientes

  • Todas las APIs que se utilicen en la aplicación

  • Compatibilidad de versiones de Perl y compatibilidad de controladores con Aurora compatible con PostgreSQL

Desarrollador de aplicaciones

Convierta las conexiones de la aplicación Perl y el módulo DBI para que sean compatibles con PostgreSQL.

Las aplicaciones basadas en Perl suelen utilizar el módulo DBI de Perl, que es un módulo de acceso a bases de datos estándar para el lenguaje de programación Perl. Puede usar el mismo módulo DBI con controladores diferentes para SQL Server y PostgreSQL.

Para obtener más información sobre los módulos de Perl necesarios, las instalaciones y otras instrucciones, consulte la documentación de DBD::Pg. El siguiente ejemplo se conecta a Aurora compatible con PostgreSQL en 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} );
Desarrollador de aplicaciones

Cambie las consultas SQL en línea a PostgreSQL.

Es posible que su aplicación tenga consultas SQL en línea con SELECT, DELETE, UPDATE y sentencias similares que incluyan cláusulas de consulta que PostgreSQL no admite. Por ejemplo, consulte palabras clave como TOP y NOLOCK no se admiten en PostgreSQL. En los siguientes ejemplos, se muestra cómo se pueden gestionar TOP, NOLOCK y variables booleanas.

En 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)

Para PostgreSQL, conviértalo a:

$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)"
Desarrollador de aplicaciones

Gestione consultas SQL dinámicas y variables de Perl.

Las consultas SQL dinámicas son sentencias SQL que se crean durante el tiempo de ejecución de la aplicación. Estas consultas se crean de forma dinámica cuando la aplicación está en ejecución, en función de determinadas condiciones, por lo que el texto completo de la consulta no se conoce hasta el tiempo de ejecución. Un ejemplo es una aplicación de análisis financiero que analiza las 10 principales acciones a diario, y estas acciones cambian todos los días. Las tablas SQL se crean en función de los mejores resultados y los valores no se conocen hasta el tiempo de ejecución.

Supongamos que las consultas SQL en línea de este ejemplo se pasan a una función contenedora para obtener los resultados establecidos en una variable y, a continuación, una variable utiliza una condición para determinar si la tabla existe:

  • Si la tabla existe, no la cree; procésela.

  • Si la tabla no existe, créela y, a continuación, procésela.

A continuación, se muestra un ejemplo de gestión de variables, seguido de las consultas de SQL Server y PostgreSQL para este caso de uso.

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 }

SQL Server:

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')";

En el siguiente ejemplo, se utiliza una variable de Perl en SQL en línea, que ejecuta una sentencia SELECT con un JOIN para obtener la clave principal de la tabla y la posición de la columna clave.

SQL Server:

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' ;";
Desarrollador de aplicaciones
TareaDescripciónHabilidades requeridas

Convierta construcciones adicionales de SQL Server a PostgreSQL.

Los siguientes cambios se aplican a todas las aplicaciones, independientemente del lenguaje de programación.

  • Califique los objetos de base de datos que utiliza su aplicación con nombres de esquema nuevos y adecuados.

  • Gestione los operadores LIKE para hacer coincidir mayúsculas de minúsculas con la característica de intercalación de PostgreSQL.

  • Gestione funciones específicas de bases de datos no compatibles, como DATEDIFF, DATEADD, GETDATE, CONVERT y los operadores CAST. Para ver funciones equivalentes compatibles con PostgreSQL, consulte Funciones SQL nativas o integradas en la sección Información adicional

  • Maneje los valores booleanos en las declaraciones comparativas.

  • Maneje los valores de retorno de las funciones. Pueden ser conjuntos de registros, marcos de datos, variables y valores booleanos. Gestiónelos de acuerdo con los requisitos de su aplicación y para admitir PostgreSQL.

  • Gestione bloques anónimos (por ejemplo, BEGIN TRAN) con nuevas funciones de PostgreSQL definidas por el usuario.

  • Convierta inserciones masivas en filas. El equivalente en PostgreSQL de la utilidad Copia masiva (bcp) de SQL Server, a la que se llama desde dentro de la aplicación, es COPY.

  • Convierta los operadores de concatenación de columnas. SQL Server usa + para la concatenación de cadenas, pero PostgreSQL usa ||.

Desarrollador de aplicaciones

Realice cambios adicionales en su aplicación basada en Perl o Python para admitir PostgreSQL

TareaDescripciónHabilidades requeridas

Convierta construcciones adicionales de SQL Server a PostgreSQL.

Los siguientes cambios se aplican a todas las aplicaciones, independientemente del lenguaje de programación.

  • Califique los objetos de base de datos que utiliza su aplicación con nombres de esquema nuevos y adecuados.

  • Gestione los operadores LIKE para hacer coincidir mayúsculas de minúsculas con la característica de intercalación de PostgreSQL.

  • Gestione funciones específicas de bases de datos no compatibles, como DATEDIFF, DATEADD, GETDATE, CONVERT y los operadores CAST. Para ver funciones equivalentes compatibles con PostgreSQL, consulte Funciones SQL nativas o integradas en la sección Información adicional

  • Maneje los valores booleanos en las declaraciones comparativas.

  • Maneje los valores de retorno de las funciones. Pueden ser conjuntos de registros, marcos de datos, variables y valores booleanos. Gestiónelos de acuerdo con los requisitos de su aplicación y para admitir PostgreSQL.

  • Gestione bloques anónimos (por ejemplo, BEGIN TRAN) con nuevas funciones de PostgreSQL definidas por el usuario.

  • Convierta inserciones masivas en filas. El equivalente en PostgreSQL de la utilidad Copia masiva (bcp) de SQL Server, a la que se llama desde dentro de la aplicación, es COPY.

  • Convierta los operadores de concatenación de columnas. SQL Server usa + para la concatenación de cadenas, pero PostgreSQL usa ||.

Desarrollador de aplicaciones
TareaDescripciónHabilidades requeridas

Aproveche los servicios de AWS para mejorar el rendimiento.

Al migrar a la nube de AWS, puede refinar el diseño de sus aplicaciones y bases de datos para aprovechar los servicios de AWS. Por ejemplo, si las consultas de su aplicación Python, que está conectada a un servidor de bases de datos compatible con Aurora PostgreSQL, tardan más que las consultas originales de Microsoft SQL Server, podría considerar la posibilidad de crear una fuente de datos históricos directamente a un bucket de Amazon Simple Storage Service (Amazon S3) desde el servidor Aurora y utilizar consultas SQL basadas en Amazon Athena para generar informes y consultas de datos analíticos para sus usuarios. cuadros de mando.

Desarrollador de aplicaciones, arquitecto de la nube

Mejoró el desempeño

TareaDescripciónHabilidades requeridas

Aproveche los servicios de AWS para mejorar el rendimiento.

Al migrar a la nube de AWS, puede refinar el diseño de sus aplicaciones y bases de datos para aprovechar los servicios de AWS. Por ejemplo, si las consultas de su aplicación Python, que está conectada a un servidor de bases de datos compatible con Aurora PostgreSQL, tardan más que las consultas originales de Microsoft SQL Server, podría considerar la posibilidad de crear una fuente de datos históricos directamente a un bucket de Amazon Simple Storage Service (Amazon S3) desde el servidor Aurora y utilizar consultas SQL basadas en Amazon Athena para generar informes y consultas de datos analíticos para sus usuarios. cuadros de mando.

Desarrollador de aplicaciones, arquitecto de la nube

Recursos relacionados

Información adicional

Tanto Microsoft SQL Server como Aurora PostgreSQL son compatibles con ANSI SQL. Sin embargo, debe tener en cuenta cualquier incompatibilidad en la sintaxis, los tipos de datos de columnas, las funciones nativas específicas de las bases de datos, las inserciones masivas y la distinción entre mayúsculas y minúsculas cuando migre su aplicación de Python o Perl de SQL Server a PostgreSQL.

Las siguientes secciones brindan más información sobre posibles inconsistencias.

Comparación de tipos de datos

Los cambios en el tipo de datos de SQL Server a PostgreSQL pueden provocar diferencias significativas en los datos resultantes en los que funcionan las aplicaciones. Para ver una comparación de los tipos de datos, consulte la tabla del sitio web de Sqlines.

Funciones SQL nativas o integradas

El comportamiento de algunas funciones difiere entre las bases de datos de SQL Server y PostgreSQL. La siguiente tabla muestra una comparación.

Microsoft SQL Server

Descripción

PostgreSQL

CAST 

Convierte un valor de un tipo de datos a otro tipo.

PostgreSQL type :: operator

GETDATE()

Devuelve la fecha y la hora del sistema de base de datos actual, en un formato YYYY-MM-DD hh:mm:ss.mmm.

CLOCK_TIMESTAMP

DATEADD

Añade un intervalo de fecha y hora a una fecha.

INTERVAL expression

CONVERT

Convierte un valor en un formato de datos específico.

TO_CHAR

DATEDIFF

Devuelve la diferencia entre dos campos de fecha.

DATE_PART

TOP

Limita el número de filas de un conjunto de resultados de SELECT.

LIMIT/FETCH

Bloques anónimos

Una consulta SQL estructurada se organiza en secciones como la declaración, los ejecutables y el manejo de excepciones. En la siguiente tabla se comparan las versiones Microsoft SQL Server y PostgreSQL de un bloque anónimo simple. En el caso de bloques anónimos complejos, le recomendamos que llame una función de base de datos personalizada en su aplicación.

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 \$\$";

 

Otras diferencias

  • Inserciones masivas de filas: el equivalente en PostgreSQL de la utilidad bcp de Microsoft SQL Server es COPY.

  • Distinción entre mayúsculas y minúsculas: los nombres de las columnas distinguen entre mayúsculas y minúsculas en PostgreSQL, por lo que debe convertir los nombres de las columnas de SQL Server a minúsculas o mayúsculas. Esto se convierte en un factor al extraer o comparar datos, o al colocar los nombres de las columnas en los conjuntos de resultados o las variables. El siguiente ejemplo identifica las columnas en las que los valores se pueden almacenar en mayúsculas o minúsculas.

my $sql_qry = "SELECT $record_id FROM $exampleTable WHERE LOWER($record_name) = \'failed transaction\'";
  • Concatenación: SQL Server usa + como operador para la concatenación de cadenas, mientras que PostgreSQL usa ||.

  • Validación: debe probar y validar las consultas y funciones de SQL en línea antes de usarlas en el código de la aplicación para PostgreSQL.

  • Inclusión de la biblioteca ORM: también puede buscar incluir o reemplazar la biblioteca de conexiones de bases de datos existente con bibliotecas ORM de Python, como SQLAlchemyPynomoDB. Esto ayudará a consultar y manipular fácilmente los datos de una base de datos utilizando un paradigma orientado a objetos.

PrivacidadTérminos del sitioPreferencias de cookies
© 2025, Amazon Web Services, Inc o sus afiliados. Todos los derechos reservados.