La migración de la lógica empresarial es más rápida que las preparaciones de café

Cómo automatizamos la migración de SQL Server a Java y la aceleramos 4 veces

Este artículo está dedicado a la modernización de Microsoft SQL Server a partir de un proyecto realizado por Ispirer para una gran empresa del sector de consultoría financiera. El cliente aprovechó el poder de una base de datos SQL Server para manejar, procesar, acceder y supervisar de manera eficiente la información financiera de sus clientes. El cliente tenía como objetivo migrar SQL Server a una nube y al mismo tiempo optimizar la arquitectura del sistema y los costos de mantenimiento.

El equipo de Ispirer se ofreció a transferir la lógica empresarial a Java porque la base de datos se utiliza en modo OLTP. Analizaremos cuidadosamente el tema y revisaremos el proyecto del cliente, que implica convertir las reglas comerciales de SQL Server a Java. Además, investigaremos las razones por las que las empresas optan por migrar el código SQL a una capa de aplicación. Esto implicará un examen exhaustivo de todo el proceso.

Para optimizar los costos de la infraestructura de la nube, el cliente decidió migrar tablas y datos a PostgreSQL. Dado que nos especializamos en migración de bases de datos y aplicaciones, el cliente recurrió a nosotros con las siguientes tareas:

• Mover 815000 LOC de lógica empresarial a la capa de aplicación en Java.
• Migrando 300 GB de datos y 3000 tablas de Microsoft SQL Server a PostgreSQL.

Debido a la importante escala del proyecto, el cliente se esforzó por minimizar los gastos de migración mediante la implementación de la automatización. Para optimizar la eficiencia del Ispirer Toolkit, determinamos que su personalización debe realizarse con anticipación. Este enfoque nos permitió entregar una herramienta al equipo del cliente, con una tasa de conversión de T-SCL a Java de aproximadamente el 90%.

Ahora profundicemos en la migración de tablas y datos.

De SQL Server a PostgreSQL: migración de datos y tablas

Consideremos las razones por las que el cliente decidió migrar de un SQL Server local a la nube. Esta transición incluye una serie de ventajas innegables:

1. Ahorro de costes. Uno de los principales factores que impulsan la migración de SQL Server a PostgreSQL en la nube es el ahorro de costos. Al cliente le resultaba caro mantener las bases de datos de SQL Server en el sitio. Esto se debió a la necesidad de equipos especiales, licencias de software y administradores de bases de datos capacitados. PostgreSQL, al ser una base de datos de código abierto, ofrece una alternativa rentable. Los clientes pueden ahorrar dinero utilizando la nube. Sólo tienen que pagar por lo que utilizan, en lugar de realizar grandes pagos por adelantado. Además, pueden gastar menos en operaciones.

   
   

2. Escalabilidad. La computación en la nube puede escalarse más fácilmente que la infraestructura local para atender mayores cargas de trabajo y más usuarios. Para que un sistema local se adaptara a las necesidades de una empresa, las organizaciones tenían que adquirir e instalar servidores físicos, licencias de software, almacenamiento y equipos de red para ampliar los servicios empresariales en entornos de TI convencionales. En la nube, la mayoría de estos recursos están disponibles instantáneamente con unos pocos clics y pueden ampliarse o reducirse automáticamente según los recursos necesarios. PostgreSQL en la nube proporciona un alto nivel de escalabilidad, lo que permite a nuestro cliente ajustar fácilmente los recursos según la demanda.

   
   

3. Seguridad. Adoptar la tecnología de la nube ofrece notables ventajas de seguridad gracias a los controles de identidad avanzados, la gestión de acceso y los sistemas de autenticación proporcionados por los proveedores de la nube. A menudo, los proveedores de la nube tienen mejores estándares de seguridad que los equipos de TI internos o los sistemas locales, lo que hace que el entorno de datos sea más seguro.

   Un cifrado sólido en la nube reduce la posibilidad de violaciones de datos. Incluye seguridad en capas, buena gestión de claves y controles de acceso seguros, que ayudan a las empresas a controlar el acceso de los usuarios de forma eficaz. Además, los proveedores de la nube supervisan rigurosamente el acceso físico, implementando medidas como el anonimato, la replicación y el cifrado para fortalecer la protección de los datos. Para 2025, se prevé que aproximadamente el 80 % de las empresas harán la transición de los centros de datos físicos a los servicios en la nube. Este cambio está impulsado por los beneficios de seguridad mejorados que proporciona la nube.

Pasar de SQL Server a PostgreSQL en la nube requiere una planificación y ejecución cuidadosas, con consideraciones específicas en mente. Basado en el proyecto del cliente, nuestro equipo ha destacado los siguientes pasos para modernizar SQL Server:

1. Transformación de esquemas y datos. Los datos deben transformarse con precisión para cumplir con los requisitos de PostgreSQL. Esto puede implicar el manejo de matices como formatos de fecha y codificación de caracteres.

   
   

2. Restricciones y desencadenantes. Es crucial comprender las distinciones en el uso de restricciones y desencadenantes en las dos bases de datos. Es necesario realizar las modificaciones necesarias en consecuencia. Además, la funcionalidad de los activadores se puede trasladar a la aplicación. Sin embargo, esta tarea no es nada sencilla, por lo que es fundamental sopesar los pros y los contras.

   
   

3. Optimización del rendimiento. La optimización del proceso de migración permite minimizar el tiempo de inactividad y el tiempo de transferencia de datos. Es importante utilizar la paralelización, optimizar el ancho de banda de la red e invertir en hardware potente para una migración eficiente.

   
   

4. Validación y prueba de datos. Se requiere una validación rigurosa de los datos migrados para garantizar la integridad y funcionalidad de los datos. Las pruebas exhaustivas garantizan que las aplicaciones funcionen perfectamente con la nueva base de datos PostgreSQL.

   
   

5. Seguridad y Permisos. Las configuraciones de seguridad, las cuentas de usuario y los permisos en PostgreSQL deben configurarse para que coincidan con la configuración original de SQL Server, lo que garantiza una transición perfecta.

¿Por qué trasladar la lógica empresarial a la capa de aplicación?

En el pasado, nuestros clientes utilizaban procedimientos almacenados para su lógica empresarial, pensando que mejorarían el rendimiento. Pero seamos honestos, el lenguaje SQL puede no ser la opción óptima para albergar la lógica empresarial en comparación con la capa de aplicación.

De hecho, SQL sólo consulta o modifica los datos de una base de datos. Aquí muchos pueden arrojarnos tomates podridos, porque el lenguaje SQL es bueno para realizar uniones complejas, filtrar y ordenar para obtener exactamente los datos que necesita de una consulta y nada más. Entonces, ¿por qué cambiar algo y llevar la lógica empresarial al nivel de la aplicación?

La pregunta parece lógica. Respondamos con más detalle. A continuación, describimos 4 razones principales por las que debería pensar seriamente en transferir la lógica empresarial a la aplicación. La decisión del cliente de trasladar la lógica empresarial a la capa de aplicación se debió a los siguientes motivos:

Escalabilidad

Para lograr escalabilidad, la mejor opción es almacenar la lógica empresarial a nivel de aplicación. ¿Por qué? Porque, en general, es mucho más fácil escalar los recursos del servidor de aplicaciones que escalar los recursos del servidor de bases de datos. Esto es casi universalmente reconocido. Para la mayoría de las aplicaciones web, agregar más servidores suele ser fácil cuando hay mucho tráfico que manejar. Sin embargo, el valor de los servidores de aplicaciones adicionales disminuye a menos que su base de datos también pueda escalarse para adaptarse a la mayor demanda. Escalar un servidor de base de datos es considerablemente más desafiante que simplemente agregar servidores de aplicaciones.

Mantenibilidad

Almacenar la lógica empresarial en una base de datos puede crear desafíos de mantenimiento. La modificación de los procedimientos almacenados puede interrumpir muchas aplicaciones, limitar la extensibilidad y dificultar el cumplimiento del principio "No repetirse" (DRY). El código SQL que supera las 100 líneas a menudo plantea complejidades y dificultades para solucionar problemas. Separar la lógica empresarial en el nivel de aplicación puede facilitar la entrada de nuevos miembros al equipo y proporciona una plataforma más intuitiva para la refactorización.

Facilidad de desarrollo

SQL es una mala elección para codificar las reglas comerciales de su sistema. No es flexible y no podemos depender de él para representar modelos complejos porque no puede crear abstracciones adecuadas. Esta limitación es la razón clave para evitar su uso en lógica empresarial. No se trata de herramientas o soporte, se trata de la incapacidad de SQL para crear un modelo de dominio simple y expresivo, en contraste con el diseño funcional y orientado a objetos, que ofrece más oportunidades.

Reutilizabilidad

En el desarrollo de software, reutilizar código es una forma eficaz de ahorrar tiempo y costes al adaptar el código existente para nuevas tareas. La Programación Orientada a Objetos (POO) es un método que facilita el reciclaje de código, haciéndolo adecuado para diversas aplicaciones. Sin embargo, SQL, comúnmente utilizado en bases de datos, ofrece una flexibilidad limitada para la reutilización de código. Las opciones incluyen el uso de "vistas" y "procedimientos almacenados", aunque estos últimos pueden generar una gran cantidad de parámetros. Para garantizar la elección correcta para su proyecto, es esencial explorar cada método a fondo.

Conversión de Transact-SQL a Java

La conversión de Transact-SQL a Java implica varias consideraciones esenciales. El proceso incluye mapear tipos de datos SQL a sus equivalentes Java, asegurando una representación precisa de los datos. También abarca la traducción de consultas SQL a código Java, donde Java se basa en bibliotecas como JDBC o Hibernate para manejar las interacciones de la base de datos. Además, ciertas características de ESQL carecen de equivalentes directos en Java, lo que podría dar la impresión de que la conversión automática es ineficiente.

Durante la fase de personalización de nuestro proyecto, pudimos crear una serie de soluciones de conversión que mejoraron la tasa de automatización. Estas soluciones, que inicialmente se creían imposibles de automatizar, finalmente resultaron exitosas. Profundicemos en los detalles de algunos de ellos.

1. Convertir una declaración INSERT en combinación con SCOPE_IDENTITY() para obtener el último valor de identidad insertado en una columna de identidad.

   Fuente:

 ALTER PROCEDURE example1 AS BEGIN Declare @idBit int Declare @c int Insert Into tab (c) Values (@c) Set @idBit = SCOPE_IDENTITY() End

Objetivo:

 @Service public class Example1 implements IExample1 { @Autowired private JdbcTemplate jdbcTemplate; private static final org.slf4j.Logger LOGGER = org.slf4j.LoggerFactory.getLogger(Example1.class); @Override public Integer spExample1() throws SQLException, Exception { Integer mStatus = 0; KeyHolder keyHolder = new GeneratedKeyHolder(); try { Integer idBit = null; Integer c = null; { final Integer tmpC = c; jdbcTemplate.update(connection-> { PreparedStatement ps = connection.prepareStatement("Insert Into tab(c) \r\n" + " Values(?)", new String[] { "" }); ps.setInt( 1, tmpC); return ps; }, keyHolder); } idBit = Tsqlutils.<Integer > strToNum(keyHolder.getKey().toString(), Integer.class); return mStatus; } catch (Exception e) { LOGGER.error(String.valueOf(e)); mStatus = -1; return mStatus; } } }

2. Conversión de procedimiento con múltiples conjuntos de resultados.

Fuente:

 ALTER PROCEDURE [returnSeveralResultSet] @p1 int, @p2 varchar(50) AS Begin select cob_ft, lower(buzon) from tab1 where cob_id = @p1 and cob_ft = @p2 select dep_ft, lower(fiton) from tab2 END

Objetivo:

 @Service public class Returnseveralresultset implements IReturnseveralresultset { @Autowired private JdbcTemplate jdbcTemplate; private static final org.slf4j.Logger LOGGER = org.slf4j.LoggerFactory.getLogger(Returnseveralresultset.class); private Integer errorCode = 0; private String sqlState = ""; @Override public Map<String, Object> spReturnseveralresultset(Integer p1, String p2) throws Exception { Integer mStatus = 0; Map<String, Object> outData = new HashMap<>(); List<SqlRowSet> outRsList = new ArrayList<>(); SqlRowSet rowSet; try { rowSet = jdbcTemplate.queryForRowSet("select cob_ft, lower(buzon) from tab1 \r\n" + " where cob_id = ? and cob_ft = ?", p1, p2); outRsList.add(rowSet); rowSet = jdbcTemplate.queryForRowSet("select dep_ft, lower(fiton) from tab2"); outRsList.add(rowSet); return outData; } catch (Exception e) { LOGGER.error(String.valueOf(e)); mStatus = -1; return outData; } finally { outData.put("status", mStatus); outData.put("rsList", outRsList); } } }

3. Conversión del método DATEDIFF. Dado que Java no tiene equivalentes directos, el equipo de Ispirer desarrolló un equivalente a este método que convierte una cadena en una marca de tiempo sin un formato especificado explícitamente. Hace que el código resulte ordenado y más fácil de leer. El siguiente ejemplo demuestra cómo se utiliza.

Fuente:

 create procedure datediffFn as declare @var1 int set @var1 = DATEDIFF(dd, '1999-01-01', '2000-02-01') set @var1 = DATEDIFF(mm, getdate(), '2000-02-01') set @var1 = DATEDIFF(week, '2005-12-31 23:59:59.9999999', '2006-01-01 00:00:00.0000000');

Objetivo:

 public Integer spDatedifffn() throws Exception { Integer mStatus = 0; try { Integer var1 = null; var1 = Tsqlutils.datediff("dd", Tsqlutils.toTimestamp("1999-01-01"), Tsqlutils.toTimestamp("2000-02-01")); var1 = Tsqlutils.datediff("mm", new Timestamp(new java.util.Date().getTime()), Tsqlutils.toTimestamp("2000-02-01")); var1 = Tsqlutils.datediff("week", Tsqlutils.toTimestamp("2005-12-31 23:59:59.9999999"), Tsqlutils.toTimestamp("2006-01-01 00:00:00.0000000")); return mStatus; } catch (Exception e) { LOGGER.error(String.valueOf(e)); mStatus = -1; return mStatus; } }

4. Conversión del método sp_send_dbmail que envía un mensaje de correo electrónico a los destinatarios especificados. Para ello se desarrolló una clase llamada MailService. Este método permite enviar correos electrónicos con especificaciones detalladas, incluidos destinatarios (TO), destinatarios de una copia (CC), destinatarios en copia oculta (BCC), el asunto de la carta, el texto principal, archivos adjuntos y más. . Para mantener el código principal ordenado, nuestro equipo colocó el método en una clase separada.

Fuente:

 create PROCEDURE spSendDbmail AS BEGIN EXEC msdb.dbo.sp_send_dbmail @profile_name = 'New DB Ispirer Profile', @recipients = '[email protected]', @body = '<h1>This is actual message embedded in HTML tags</h1>', @subject = 'Automated Success Message' , @file_attachments = 'C:\Temp\Attached.txt', @body_format='HTML', @copy_recipients = '[email protected]', @blind_copy_recipients = '[email protected]'; END

Objetivo:

 import java.util.*; import com.ispirer.mssql.mail.MailService; public class Spsenddbmail { private static final org.slf4j.Logger LOGGER = org.slf4j.LoggerFactory.getLogger(Spsenddbmail.class); public Integer spSpsenddbmail() throws Exception { Integer mStatus = 0; try { MailService.send("New DB Ispirer Profile", "Automated Success Message", "<h1>This is actual message embedded in HTML tags</h1>", "[email protected]", "[email protected]", "[email protected]", "C:\\Temp\\Attached.txt", "HTML"); return mStatus; } catch (Exception e) { LOGGER.error(String.valueOf(e)); mStatus = -1; return mStatus; } } }

5. El equipo de Ispirer ha desarrollado una clase XMLUtils para convertir el tipo de datos xml y sus métodos, que se utilizan para obtener cualquier información de los datos XML almacenados en una variable XML. Un ejemplo de implementación del método:

Fuente:

 create procedure workWithXml AS begin declare @result bit, @myDoc XML, @myStr varchar(1000), @ProdID INT SET @myDoc = '<Root> <ProductDescription ProductID="1" ProductName="Road Bike"> <Features> <Warranty>1 year parts and labor</Warranty> <Maintenance>3 year parts and labor extended maintenance is available</Maintenance> </Features> </ProductDescription> </Root>' SET @result = @myDoc.exist('(/Root/ProductDescription/@ProductID)[1]') SET @myStr = cast(@myDoc.query('/Root/ProductDescription/Features') as varchar(max)) SET @ProdID = @myDoc.value('(/Root/ProductDescription/@ProductID)[1]', 'int' ) end;

Objetivo:

 import java.util.*; import com.ispirer.mssql.xml.XMLUtils; public class Workwithxml { private static final org.slf4j.Logger LOGGER = org.slf4j.LoggerFactory.getLogger(Workwithxml.class); public Integer spWorkwithxml() throws Exception { Integer mStatus = 0; try { Boolean result = null; String myDoc = null; String myStr = null; Integer prodID = null; myDoc = "<Root> " + "<ProductDescription ProductID=\"1\" ProductName=\"Road Bike\"> " + "<Features> " + "<Warranty>1 year parts and labor</Warranty> " + "<Maintenance>3 year parts and labor extended maintenance is available</Maintenance> " + "</Features> " + "</ProductDescription> " + " </Root>"; result = XMLUtils.exist(myDoc, "(/Root/ProductDescription/@ProductID)[1]"); myStr = XMLUtils.query(myDoc, "/Root/ProductDescription/Features"); prodID = XMLUtils.<Integer > value(myDoc, "(/Root/ProductDescription/@ProductID)[1]", Integer.class); return mStatus; } catch (Exception e) { LOGGER.error(String.valueOf(e)); mStatus = -1; return mStatus; } } }

Gracias a nuestros esfuerzos de personalización, nuestro equipo ha desarrollado con éxito una variedad de técnicas para automatizar la transición de T-SQL a Java. Esto ha reducido significativamente el tiempo total de migración de todo el proyecto, lo que nos permite acelerar la migración 4 veces en comparación con la posible migración manual. La personalización de nuestro kit de herramientas no solo aceleró la transición sino que también mejoró la eficiencia general del proyecto, mostrando el valioso impacto de nuestras iniciativas de personalización. Los métodos especificados en los ejemplos se proporcionan al cliente junto con los resultados de la conversión.

Conclusión

En conclusión, la transición de la lógica empresarial de Transact-SQL a Java es un proceso multifacético que requiere una comprensión integral de ambos lenguajes y sus características distintivas.

En este artículo exploramos a fondo la migración de la lógica empresarial a una capa de aplicación y brindamos información valiosa para quienes están planificando dicha transición. El caso de nuestro cliente demuestra que estos proyectos de modernización se pueden automatizar, lo que ahorra significativamente tiempo y esfuerzo durante la migración. El proyecto de nuestro cliente es un testimonio convincente del notable potencial de la automatización. Demuestra que existen facetas de la modernización en las que la automatización puede optimizar con éxito procesos que inicialmente pueden parecer más allá de sus capacidades.

En última instancia, adoptar la migración de Transact-SQL a Java es un movimiento estratégico para las organizaciones que buscan mayor flexibilidad, compatibilidad multiplataforma y escalabilidad. Si bien presenta sus desafíos, los beneficios en términos de portabilidad, rendimiento y adaptabilidad a las arquitecturas de software modernas hacen que esta transición sea un esfuerzo que valga la pena para quienes buscan modernizar sus sistemas y aplicaciones de bases de datos.