En los últimos años estamos viviendo una auténtica revolución en el mundo de la informática gracias, entre otras, a las tecnologías Big Data y a sus posibles aplicaciones en múltiples campos, como la biología, medicina, seguros, finanzas y un largo etcétera.

De hecho, el poder analizar y sacar conclusiones a partir de sus propios datos mediante tecnologías Big Data, como tradicionalmente se ha hecho mediante Business Intelligence, se ha convertido en una de las prioridades de nuestros clientes a la hora de abordar el proceso de Transformación Digital de sus empresas (junto a otros aspectos como la migración hacia metodologías ágiles de trabajo, arquitecturas resilientes y distribuidas, etc).

Sin embargo, cuando iniciamos la implantación de esta auténtica revolución tecnológica - y no sólo tecnológica - hay algo con que nos tenemos que enfrentar: el almacenamiento actual de los datos.

Tradicionalmente, y esto es algo que no ha cambiado demasiado en los últimos años, muchos de nuestros clientes han optado por mantener el core de su negocio en sus sistemas de almacenamiento de toda la vida: grandes bases de datos relacionales (ejemplo: Oracle), ERP’s (ejemplo: SAP) o host. Estos sistemas, a diferencia de otras tecnologías más modernas, plantean ciertas limitaciones a tener en cuenta:

Para solventar estas carencias tenemos en el panorama tecnológico actual un abanico importante de soluciones que podemos adoptar. Algunos ejemplos podrían ser:

Sin embargo, normalmente, no podemos empezar a utilizar estas tecnologías sin más, en la mayoría de nuestros clientes no podemos hacer un proceso de migración puntual y apagar sus sistemas legacy de un día para otro, sino que necesitamos un proceso de convivencia, entre estos y las nuevas tecnologías, que permita:

Por tanto, lo que parece claro es que, mientras que tengamos los dos requerimientos anteriores, vamos a necesitar algún proceso que nos extraiga los datos de los sistemas tradicionales a los nuevos sistemas que queramos implantar. Además, esta extracción de datos deberá ser lo más cercana al tiempo real posible (near real time, en adelante, simplemente, “tiempo real”*)*, para poder cumplir con las necesidades anteriores.

Inicialmente, las primeras soluciones que se nos pueden pasar por la cabeza son:

Idea 1: “Esto no es tan complicado, ejecutamos sobre la base de datos original (sistema original/legacy) las consultas que nos hagan falta y ya lo tenemos…”

Esta aproximación, que puede ser válida en ciertas ocasiones, plantean algunos inconvenientes a tener en cuenta:

  1. Sobrecargamos el sistema original con trabajo “extra”: Esta sobrecarga, a veces, puede resultar siendo un inconveniente bastante grave, sobre todo si nuestro sistema (ejemplo: base de datos) que necesitamos consultar ya está bastante ocupada con su carga habitual.
  2. Aumentamos costes: En el caso de que el acceso a nuestro sistema Legacy conlleve costes asociados, como es el caso del host en los sistemas bancarios (MIPS), esta estrategia no haría más que aumentar los costes que ya tuviéramos en un primer momento.
  3. No disponemos de datos en tiempo real: Es decir, solo disponemos de la información almacenada en nuestros sistemas en el momento de ejecutar las consultas. De hecho, ni siquiera esto es verdad, ya que durante la ejecución de las consultas pueden ocurrir nuevas actualizaciones que no vamos a ser capaces de procesar. Además, a partir de la la extracción de los datos, estos irían quedando obsoletos irremediablemente, dejándonos como única opción la ejecución de nuestras consultas una y otra vez.

Idea 2: “Está bien, podemos escribir dos veces, en nuestro sistema de siempre y en el nuevo sistema que queremos implantar

Esta solución, también conocida como dual-writes, también plantea ciertos inconvenientes a considerar:

  1. Es complicado hacer este cambio de forma transparente a las aplicaciones existentes, incluso si se adapta una aproximación basada en implementar algún tipo de proxy.
  2. El mantenimiento de nuestro sistema se hace más complejo, al necesitar tener en cuenta esta dualidad en todos los casos donde fuera necesario. Además, este aumento de la complejidad también es extensible a la implantación de nuevas funcionalidades.
  3. Es complicado que ambos sistemas contengan exactamente los mismos datos. Es decir, es difícil mantener los datos homogéneos en ambos sistemas, sobre todo teniendo en cuenta que pueden ocurrir fallos de red, bugs, etc. con el paso de tiempo. Este error puede ser dramático, sobre todo si tomamos decisiones importantes en base de los análisis de los datos que podamos realizar, y, por si fuera poco, no vamos a disponer de un sistema de failover, al menos de manera automática, que nos permita corregir esta situación.

Idea 3: “¿Y si hacemos log shipping o mirroring de las bases de datos?”

  1. Log Shipping es el proceso por el cual se consigue una réplica de la base de datos origen en base a la lectura periódica de sus logs transaccionales. El mayor inconveniente de esta técnica, diseñada para aumentar la disponibilidad de las bases de datos, es que no se trata de una solución en tiempo real. Y es que, aunque este proceso se base en la lectura de los logs transaccionales, estos no se leen de forma reactiva, sino que, como hemos comentado, las lecturas se ejecutan de manera periódica. Sistemas gestores de bases de datos (SGBD) como Oracle o SQLServer disponen de herramientas que implementan este mecanismo.
  2. Por otra parte, el mirroring es el proceso por el cual dos bases de datos, arbitrados por un tercer servidor, son capaces de mantener los mismos datos (y sus logs transacciones) de manera sincronizada. Esta técnica, a diferencia del log shipping, sí soluciona nuestro problema del tiempo real. No obstante, deja ciertos inconvenientes a considerar:
  3. Necesitamos un tercer servidor que actúe como árbitro de esta replicación, aumentando los costes de nuestra solución.
  4. El failover no está solucionado de manera automática, necesitando intervenciones manuales para garantizar la integridad de los datos.
  5. Lo que obtenemos es un espejo de nuestra base de datos, por lo que no soluciona nuestro requerimiento de almacenar los datos en sistemas heterogéneos al de origen.

Conclusiones

El problema de la replicación de datos en tiempo real, haciendo posible la convivencia entre los sistemas legacy de nuestros clientes y las nuevas tecnologías emergentes en el panorama tecnológico actual, es algo prioritario e importante a tener en cuenta por todos aquellos interesados en transformar digitalmente sus empresas, debido a todos los beneficios que conlleva:

Sin embargo, hemos visto que las soluciones tradicionales no resuelven de una manera definitiva los problemas de la situación actual, dejando algunos flecos por resolver. Es por esto que, en futuros artículos, introduciremos una posible solución técnica a la replicación de datos en tiempo real, y además plantearemos posibles implementaciones.

Nuevo llamado a la acción

Cuéntanos qué te parece.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.

Suscríbete