Presentando KafkaDB

Hoy queremos llevar a cabo la Presentación KafkaDB, nuestra nueva criatura que acabamos de publicar en bitbucket.

Os mostramos KafkaDB, una herramienta que simplificará la tarea de migrar bases de datos entre versiones de OpenERP, pero también se podría extender para permitir la migración entre versiones entre otras aplicaciones basadas en PostgreSQL.

En la página principal del proyecto, podéis encontrar información detallada sobre el diseño y como utilizarla, pero ahora me gustaría explicaros como hemos llegado hasta aquí.

Los requerimientos

Desde que OpenERP SA anunció que las herramientas de migración no formarían parte del software público empezamos a dar vueltas en cómo podríamos implementarlas de forma reutilizable.

Algunas empresas buscaron soluciones a corto plazo, simplemente mirando de solucionar el problema para uno o dos clientes que querían pasar de la 4.2 o la 5.0 a la 6.0 y posponiendo la búsqueda de una solución real.

Nosotros estábamos convencidos que de la misma manera que la herencia había permitido a OpenERP tener centenares de módulos hechos y liberados por muchos desarrolladores, podríamos conseguir lo mismo con las migraciones.

Así que básicamente teníamos que implementar algo que solucionara los siguientes requerimientos:

• Modular: tenía que proveer un mecanismo mediante el cual se pudieran reutilizar las transformaciones de datos de una base de datos a otra.
• Rápido: dada la medida de las bases de datos de algunos de nuestros clientes, sabíamos que tendríamos que mover la información a nivel de base de datos.
• Fácil de compartir: además de ser modular, queríamos asegurarnos que sería sencillo para todo el mundo compartir sus transformadas. Dado que la información sobre la migración no estaría incluida en los módulos, necesitábamos que fuera sencillo de compartir, así cómo de encontrar qué transformadas había disponibles.

Búsqueda y desarrollo

A continuación, explicaremos el camino hasta alcanzar el diseño actual de KafkaDB.

El proceso empezó con una pequeña prueba de concepto utilizando Python y openetl.

Descartamos esta opción, no tan sólo porqué estaba abandonado, sino también porqué la API no era intuitivo.

Además, a pesar de que no llegamos a hacer pruebas, parecía que podía ser relativamente lento.

La primera alternativa fue buscar otro ETL basado en python. Esta vez el candidato fue el Brewery.

Éste tenía una API bastante mejor pero no disponía de algunas funcionalidades básicas que necesitábamos; y a pesar de que habríamos podido contribuir al proyecto, necesitábamos centrarnos en solucionar los problemas que teníamos, no a implementar un ETL desde cero.

Habríamos querido que fuera en python, especialmente para hacer más sencillo que la gente contribuyera, pero empezamos a buscar alternativas en otros lenguajes.

Scriptella fue el primer candidato y éste basa su configuración en un fichero XML, así que nos pareció atractivo.

Ya sabíamos que el sistema que escogiéramos acabaría teniendo un fichero de configuración, así que a priori parecía que esta podía ser una buena opción porque el sistema ya dependía de uno.

A pesar de esto, no nos convenció el comportamiento por defecto de algunas opciones del sistema. Además del hecho que el XML parecía que podría ser poco práctico puesto que fácilmente podíamos llegar a las 400 tablas.

Así que Àngel, uno de mis socios y nuestro experto en Kettle y grandes migraciones de datos, empezó a jugar con la API de Kettle; y mirar a ver qué se podía hacer con transformadas manuales y algunos automatismos.

Pronto se dió cuenta, que no tan sólo podía cumplir todos los requerimientos que teníamos. Sino que, permitíamos que personas que no fueran desarrolladores también se podían migrar su base de datos.

Por ejemplo, varios de nuestros clientes se lo podrían hacer ellos mismos si lo desearan!

Además, Kettle es probablemente el ETL estándar de facto y especialmente entre la comunidad OpenERP. (Gracias a Terminatooor, un conector para Kettle creado por Akretion, especialmente diseñado para funcionar con OpenERP).

Conclusiones

En resumen, a pesar de que KafkaDB no está acabado del todo todavía, consideramos, que constituye una buena base para el sistema de migraciones flexible que necesitamos.

Por una parte, para migrar información entre versiones de OpenERP, y que además, también lo permita entre aplicaciones diferentes.

Será viable, siempre y cuando se necesite volver a utilizar el proceso para diferentes bases de datos con estructuras parecidas.

Si desea obtener mas información relacionada con el tema de la “Presentación KafkaDB” puede visitar nuestro sitio web haciendo clic aquí.