Migrando de Oracle RAC a PostgreSQL

El deseo...🪄

Últimamente hemos recibido mucho interés y consultas respecto de cómo salirse de Oracle. Esta idea mucha veces es un deseo que tiene poco análisis y profundidad.
Oracle tiene más de 1000 productos...¿Cuál de todos? Bueno, típicamente se refieren a la base de datos -que es más que una base de datos-.

La migración de la base de datos es un proyecto factible, pero la segunda pregunta es: ¿Es factible que la aplicación utilice otra Base de Datos? Existen aplicaciones como PeopleSoft o Oracle E-Business Suite en que no es factible reemplazar la BD.

Si la aplicación soporta otro tipo de base de datos, entonces sí sería válido evaluar un proyecto de migración.

¿Porqué salirse de Oracle?

Si bien son varios los factores, el principal suele ser el alto costo de licenciamiento y la dificultad de negociar y encontrar soluciones con el equipo de ventas y soporte. A menudo Oracle se percibe como una empresa rígida, inflexible, y arrogante. Y no quieres hacer negocios con una empresa que te trata así.

Cuando Amazon anunció su interés de migrar y salirse de Oracle, esta fue la respuesta de su CEO Larry Ellison:

"Déjenme decirles quién no se está moviendo de Oracle, una compañía de la que han oído hablar que nos dio otros 50 millones de dólares este último - este trimestre para comprar Oracle Database y otras tecnologías de Oracle. Esa empresa es Amazon. No se están moviendo fuera de Oracle. Salesforce no se está moviendo fuera de Oracle. Nuestros competidores, a los que no tenemos ningún motivo para caerles muy bien, siguen invirtiendo y gestionando todo su negocio con Oracle. No sé quién está dejando Oracle. Tal vez Mark lo haga. Tal vez Safra. Pero Amazon - uno pensaría que Amazon realmente querría moverse".

Por otra parte, las cláusulas y políticas de Licenciamiento son vagas y poco claras. Clientes que han querido disminuir el cobro de licenciamiento reduciendo el número de CPUs (según se basa el modelo de pricing), terminan pagando lo mismo por "ajustes" de precio.

Casos de éxitos 🚀

Y bueno, finalmente llegó el día (2019) en que Amazon pudo migrar todas sus más de 7500 bases de datos de Oracle a Redshift, Aurora y DynamoDB, y el CTO de Amazon Werner Vogels señaló:

Ha sido el día más feliz del año.

Asi como Amazon logró salirse de Oracle, decenas de grandes empresas han logrado lo mismo. Sin duda que no es sencillo, pero la recomensa llega.

¿Hacia donde migrar?

Bueno, dependerá del contexto de la empresa y sus aplicaciones. Ha diferencia de hace 30 años en que Oracle era la única solución de alta disponibilidad, hoy existen decenas de proyectos de código libre como MongoDB, PostgreSQL y MariaDB.

Si bien hay casos de éxito de clientes migrando a soluciones como SQL Server, donde se han visto menos riesgos ha sido a la base de datos PostgreSQL.

¿Porqué migrar a PostgreSQL ? ¿Cuáles son los beneficios?

Antes que nada, si  bien PostgreSQL es una solución de código libre hay que destacar que recibe financiamiento y apoyo de empresas como Microsoft y Google.

Podemos destacar 7 ventajas o beneficios de PostgreSQL:

1. API. Los desarrolladores pueden acceder directamente a cualquier componente de la base de datos a través de la interfaz API.
2. Autenticación. Postgres admite una amplia gama de métodos de autenticación. Esto proporciona una mayor flexibilidad para la autenticación de usuarios y procesos.
3. Extensiones. Al ser de código abierto, existe miles de extensiones por parte de la comunidad que extienden las funcionalides y características de la solución a los más diversos ámbitos.
4. Languaje. Mientras que Oracle tiene un lenguaje de programación integrado llamado PL/SQL, Postgres no sólo tiene PL/pgSQL, sino muchos otros, así como un sistema de extensión que permite a los usuarios crear procedimientos adicionales como plug-ins, además de bindings para aún más lenguajes de programación.
5. Localización. Los servicios del sistema de localización de Postgres están integrados para proporcionar codificación automática de caracteres y métodos de colección.
6. Performance. Dado que PostgreSQL puede crear un número ilimitado de nodos en un clúster de lectura, el costo de cualquier operación de lectura puede reducirse a casi nada. Y por eso, es posible ajustarlo de forma diferente para cada carga de trabajo. En Oracle también se puede hacer esto, pero cada nodo tiene un costo adicional.
7. Escalabilidad. Postgres puede crear un número prácticamente ilimitado de nodos en un cluster de lectura, lo que generalmente es suficiente para soportar una gran cantidad de consultas.

¿Cuales son las fases de una migración?

Bueno, cada proyecto tiene sus características, pero en general hemos agrupado el proceso de migración de Oracle en las siguientes 5 fases:

1. Assessment. Fase de levantamiento y "discovery". Se revisa la compatibilidad de las aplicaciones, se revisa el código y la arquitectura de los distintos servicios que utilizan la base de datos.

Se evalúan los datos, procedimientos almacenados y funciones que puedan existir. Además se levantan la información historica respecto de usabilidad y performance. Esta etapa dimensiona la dificultad y esfuerzos que requerirá el proyecto, además de una estimación de los costos, y el equipo necesario para llevarlo adelante. También se diseña y propone la arquitectura de nueva solución de Postgres.

2. Migración de Schema. Se analiza la conversión de la estructura de datos o schema. Se requiere probar y evaluar las distintas herramientas disponibles para la conversión de la estructuras. Esta fase es larga y compleja por cuanto existen cientos de situaciones en que la transformación de la estructura de datos es sutil y no perceptible. Las relaciones entre tablas y la definiciones de los campos a veces parecen iguales pero no lo son.

3. Testing Funcional. Antes de seguir adelante, es importante probar el schema convertido en un conjunto de datos de muestra. Un enfoque recomendado es cargar algunos datos de muestra en Postgres desde un entorno de desarrollo o prueba  donde haya datos de muestra de producción y, a continuación, configurar una conexión de aplicación utilizando el acceso a datos (controladores) adecuado. Una vez que la aplicación se haya conectado a la base de datos, permítale realizar pruebas funcionales completas en los objetos convertidos con DML.

El testing funcional se itera y repite continuamente con el mismo conjunto de datos de muestra, tanto en la base de datos Oracle como en la Postgres y, hasta asegurarse de que los resultados SQL sean idénticos.

4. Testing de Performance. Las pruebas de rendimiento son importantes en la fase de migración porque algunas de las transacciones incorporadas en Oracle o la funcionalidad de las características pueden ser ligeramente diferentes en Postgres y la aplicación puede ver alguna diferencia. En esta fase, podemos capturar todas esas diferencias y solucionarlas a nivel de aplicación, acceso a datos (controladores) y base de datos con el ajuste adecuado.

5. Migración de Datos. Hay muchos métodos o prácticas respecto de la migración de datos. La más compleja es la "zero downtime" o réplica, en que ambos servicios de base de datos (Oracle y Postgres) están funcionando en paralelo. Pero también existe el "snapshot" en la que los se mueven sólo una vez durante una ventana de mantenimiento o interrupción del servicio.

Aquí se deben analizar los PROS y CONTRAS de cada uno, ya que son estrategias muy distintas.

Conclusión

Afortunadamente existen en el mercado más y más clientes que ha decido migrar desde Oracle a alguna solución de código libre. Estos casos de negocio confirman y validan que en la gran mayoría de los casos la migración son factibles, y que no existe inmedimentos para llevar a cabo la tarea.

En Chile existe pocos casos de migración de Oracle hasta otras bases de datos, principalmente por que muchas veces las empresas no tienen la capacidad de hacerlo, o porque no existen servicios profesionales que tengan las competencias. Afortunadamente en Patagon Labs trabajamos con Ingenieros DBA certificados, tanto en Oracle como en Postgres, profesionales que cuentan con experiencia en este tipo de proyectos.