CDC, más allá de la modernización.

En los últimos meses, hemos tratado en detalle el funcionamiento de CDC, qué técnicas utilizar, qué motores de bases de datos lo soportan y el funcionamiento de algunas de las herramientas más utilizadas.

En ellos hemos visto algunos casos de uso, como pueden ser la modernización de aplicaciones (tanto para el propio proceso de migración como para facilitar las etapas de convivencia entre aplicación nueva y antigua) o el acceso al dato en tiempo real sin la necesidad de cambios sobre la aplicación original.

En este post vamos a ver un caso de uso ligeramente diferente, pero igualmente común, que puede aportar otra visión a la utilización de esta tecnología.

Desnormalización de BD usando CDC

En múltiples ocasiones nos encontramos con la necesidad de tener una visión desnormalizada de nuestra base de datos. Por lo general, suele venir asociado a la búsqueda de mejora de rendimiento a la hora de acceder a la información.

En estos casos, la desnormalización nos permite “ahorrarnos” joins. Pueden resultar costosos e incluso repetidos a costa de almacenar datos en un formato poco óptimo, aunque desde el punto de vista de la lectura o del tratamiento sea más adecuado.

¿Cuándo usar CDC para la desnormalización?

Existen múltiples formas de realizar la desnormalización de los datos. Por tanto, ¿en qué caso creemos conveniente utilizar CDC?

• Se busca un dato desnormalizado en tiempo real.

Como hemos visto, una de las cualidades de CDC es que nos permite acceder a la información en tiempo “real” (en realidad es semi-real, como ya sabéis). Si la información se utiliza para entornos analíticos en el que sea aceptable un dato en D+1, podemos utilizar otro tipo de procesos para la desnormalización.

• El sistema de almacenamiento destino es distinto al original.

Cuando pensamos en reaccionar ante un cambio en la base de datos, probablemente lo primero que nos venga a la cabeza sea el uso de triggers.

Un trigger puede ser un mecanismo perfectamente válido para estas casuísticas, siempre que el sistema origen y destino sea el mismo. Es decir, el dato en esta situación no saldría del sistema y, siempre que no requiera de un procesamiento pesado para la desnormalización, es muy posible que sea el mecanismo más óptimo.

Intentar forzar el uso de CDC en esta situación (el origen y el destino son el mismo sistema) obligaría a sacar el dato fuera del sistema de almacenamiento para luego volver a incorporarlo, lo que en la mayoría de los casos no tendría sentido.

La situación cambia cuando el sistema destino es distinto al de origen. En esta situación, forzar el uso de triggers para esta tarea (aún cuando es posible) podría no ser adecuado, ya que sería el propio sistema de almacenamiento el que sufriría la carga del procesamiento y envío de la información. Al usar CDC, evitamos esa carga ‘extra’ y trasladamos a un entorno que sea más ‘amigable’ para el procesamiento y envío de esa información.

• Procesamiento o enriquecimiento complejo.

La desnormalización puede conllevar fases de procesamiento costosas (a nivel computación), lo que podría afectar al rendimiento del origen de datos siendo, por lo tanto, no aconsejable.

Igualmente, en determinadas ocasiones nos encontraremos con la necesidad de enriquecer la información desde fuentes externas.

En estos casos, es aconsejable volcar los cambios obtenidos a través de CDC sobre un sistema externo a la infraestructura del sistema origen que permita implementar cómodamente estos flujos de enriquecimiento.

Implementación

Evidentemente, existen muchas formas de realizar la implementación de un sistema como este. La mejor aproximación dependerá siempre del caso de uso, por lo que únicamente indico aquí una de las múltiples posibilidades.

Definimos un pequeño modelo de datos que nos sirva de ejemplo:

Y planteamos un caso de uso sencillo: buscamos la desnormalización de datos de forma que podamos trabajar cómodamente con la información de la relación entre las ventas de los clientes por proveedor y categoría.

Vamos a plantear, además, los siguientes requisitos para esta tarea de desnormalización:

• Es crítico introducir la menor carga posible al sistema origen (el operacional).
• No es necesario realizar ningún tipo de enriquecimiento con datos externos a los que el propio sistema origen ya posee.
• El destino de los datos es otro sistema y con distinta tecnología, en este caso uno más adecuado a la explotación que se va a realizar.

Desde el punto de vista de arquitectura, el esquema de funcionamiento es sencillo:

NOTA: El diagrama indica el sistema de enriquecimiento como una única pieza, pero en la realidad es muy posible que no sea tan sencillo: distintas fases de enriquecimiento, varios componentes en función del dato que deba desnormalizarse…

El flujo sería: cada vez que se produzca una nueva venta, necesitamos obtener la información del cliente que la ha realizado, junto con la información del proveedor y la categoría del producto para almacenarlo en nuestro sistema destino.

Nos pueden surgir varias dudas en la implementación de este caso de uso que tienen distintas alternativas para su resolución. Vamos a tratarlas de forma aislada para que nos permita ejemplificar las distintas casuísticas (aunque en la mayoría de los casos deberán tratarse de forma conjunta).

Trabajo con datos estáticos

Indican que el sistema origen no se puede sobrecargar, por lo que no podemos hacer uso siquiera para ciertos datos ‘estáticos’, como puedan ser datos maestros o similares.

En nuestro sistema de datos, estaríamos hablando de la información de las categorías de productos. Necesitamos, por lo tanto, poder recuperarlos de otro sistema, donde a su vez podríamos tener distintas alternativas:

• Consideramos estos datos como inmutables y los cargamos directamente (con un proceso diferente o a mano) sobre el sistema destino y usándolo para el proceso de enriquecimiento.

• Podemos, por otro lado, incluirlos dentro del propio flujo de CDC (evitaríamos de esta forma la carga manual) para volcarlos sobre el sistema destino e igualmente usarlo para el enriquecimiento.

Podemos encontrarnos situaciones en las que el sistema destino no sea el más adecuado para el almacenamiento de este tipo de información de enriquecimiento. Esto nos llevaría a necesitar un tercer sistema para este almacenamiento (complicando ligeramente la arquitectura).

Trabajo con datos dinámicos

Nuevamente, nos encontramos con la restricción principal de no poder usar el sistema de origen para las etapas de enriquecimiento y, puesto que en este caso estamos hablando de datos cambiantes (los clientes o los proveedores en nuestro ejemplo), utilizaremos el flujo de CDC para obtener las actualizaciones de estos datos.

En esta situación, hemos utilizado un sistema externo para almacenar esa información temporalmente y mantenerla actualizada (de forma unidireccional, del sistema origen al almacenamiento temporal).

Generamos, por lo tanto, distintos flujos de trabajo sobre los datos extraídos a través de CDC, pudiendo incluso, si fuera necesario, incorporar etapas de enriquecimiento en el propio proceso de almacenamiento en el sistema externo si eso nos facilita / simplifica el proceso global.

Coherencia temporal sobre los datos dinámicos

La desnormalización que estamos creando genera una foto condicionada ‘temporalmente’ al momento en el que se realiza. Es decir, ¿qué sucede si en un momento determinado un proveedor cambia de nombre?

Nuestra tabla desnormalizada va a contener el dato ‘antiguo’ hasta el momento en el que se actualiza el nombre del proveedor, a partir del cual se comenzará a almacenar la nueva información, generando por lo tanto una incoherencia en nuestra visión desnormalizada.

Esta incoherencia no ocurriría si siempre utilizáramos el sistema origen como fuente de datos y habrá situaciones en la que no sea aceptable, siendo, por lo tanto, necesario corregirlo.

CDC nos aporta información de cualquier modificación (insert, update o delete), por lo que vamos a hacer uso de esta capacidad para solventar esta situación.

Creamos un flujo que únicamente atienda a las actualizaciones sobre la información ‘extra’ utilizada para el enriquecimiento. Este flujo procesará estos cambios y realizará las alteraciones necesarias sobre nuestro sistema destino para mantener la coherencia en la información.

Conclusión

En este post hemos visto un uso un poco distinto de CDC al que generalmente se podría aplicar, pero que, bajo ciertas condiciones, puede ser realmente útil si tenemos esa necesidad de datos en tiempo real sin alterar el sistema original.

Como vemos la solución tiene cierta complejidad, hay un cierto volumen de infraestructura que se debe aprovisionar, código para transformar y enriquecer que debe ser implementado y mantenido… es por ello que este tipo de soluciones deben aplicarse sólo en ciertas situaciones y, por supuesto, nunca como norma general.

Cuando llegamos al mundo real (más allá de las versiones simplificadas que pueda haber en un post como este) las necesidades varían radicalmente, pero las ideas de cómo acometer la solución pueden servir de inspiración para encontrar la forma de mejor encaje.

¡Espero que este post os pueda ser de ayuda para vuestro próximo proyecto!