Replicando datos en tiempo real: ¿qué vas a hacer con tus datos, si no los usas?

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:

• Costes de operaciones: Sistemas como los hosts bancarios, con sus MIPS, hacen que la manipulación de los datos que contienen supongan sobrecostes a los proyectos.
• Análisis y búsquedas de datos en tiempo real: Normalmente suele ser una carencia, o al menos no suele ser sencillo, disponer de estas funcionalidades en los sistemas comentados.
• Dimensionamiento: No siempre es posible seguir añadiendo recursos a los sistemas que se nos han quedado pequeños con el paso del tiempo, ya sea por meras cuestiones físicas o cuestiones económicas. A veces necesitamos tener otras políticas de escalado, añadiendo máquinas de parecidas capacidades a nuestro sistemas, en lugar de seguir ampliando la que ya tenemos. Esto es conocido como escalado horizontal (vs vertical), y en los sistemas tradicionales no suele ser muy sencillo aplicar este tipo de estrategias.
• Mantenimiento / Adaptación al cambio: Normalmente, al tener cualquier tipo de sistema diseñado e implementado como un monolito, en lugar de tenerlo dividido en pedazos más pequeños e independientes, hace que cualquier cambio que tengamos que aplicar sea más traumático al tener que tocar algo que ya, por definición, es más grande y complejo.
• Time to market: Al hilo del punto anterior, la implementación de nuevas funcionalidades a nuestro sistema, al ser éste más complejo, hace que el tiempo (y coste) de desarrollo de cualquier nueva funcionalidad se vea incrementado, penalizando así una posible salida temprana de nuestro producto.

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

• Sistemas NoSQL, como MongoDB o Couchbase, para mejorar la adaptación al cambio y el time-to-market.
• Sistemas de indexación para la ejecución de búsquedas, como puede ser ElasticSearch, por ejemplo.
• Sistemas distribuidos, para mejorar el dimensionamiento y/o obtener la alta disponibilidad, etc.

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:

• Que las aplicaciones que actualmente ya tienen nuestros clientes sigan funcionando de la misma forma que siempre.
• Y que, por otra parte, tengamos los datos en otros sistemas, más accesibles, más orientados y mejor diseñados para ejecutar todas las nuevas tareas que conlleva el proceso de Transformación Digital de nuestro cliente.

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:

• Reducción de costes de mantenimiento y nuevos desarrollos.
• Mayor disponibilidad de nuestros sistemas**.**
• Mayor flexibilidad y personalización de nuestros servicios.
• Enriquecimiento de la información de la que disponemos para tomar decisiones de negocio, ya que ésta podrá ser obtenida en tiempo real y de fuentes de datos repartidos en sistemas heterogéneos.

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.