Captura de datos modificados o CDC

“Bajo mi punto de vista, en sistemas complejos en los que conviven distintas fuentes de datos con arquitecturas de eventos (EDA), el patrón CDC se hace imprescindible”

Hoy en día en nuestros proyectos podemos encontrar distintas fuentes de datos repartidas en distintos y muy dispares lugares. Imaginad que tenemos un racimo de microservicios independientes entre sí, con sus propios repositorios de datos independientes, tal que así:

Y necesitamos añadir un ElasticSearch para indexaciones de datos o añadir una base de datos en la que realizar alguna explotación de información. Podemos intentar crear una nueva base de datos, que sea una réplica de las que ya tenemos, lo que nos llevará a pensar en cómo podemos propagar los cambios en cada una de estas base de datos “fuente”, (Source Data o fuente de la verdad, como la denominan algunos autores) a la base de datos “destino”. 

El patrón de captura de datos modificados, en inglés Change Data Capture o CDC define cómo actuar cuando se ejecutan cambios sobre los datos y cómo propagar éstos a los destinos asignados. Incluso nos permitirá transformarlos y convertirlos en “Derived Data” antes de hacerlos llegar a su destino. En definitiva, el patrón CDC se va a encargar de capturar los cambios escritos en la base de datos que sea la fuente de verdad y extraerlos para replicarlos tal cual o transformados, en los sistemas que los necesiten.

Existen diferentes formas de implementar este patrón, entre las que destacan dos. La basada en lanzar una query de forma constante contra tu base de datos, conocida como Query-Based. Como podéis suponer esta aproximación es bastante sencilla de conseguir, ya que solo precisa de una conexión básica a la base de datos y poco más, pero necesita muchos recursos. Y la basada en logs, o Logs-Based, que utiliza el sistema de logs que ya llevan de serie los SGBD y que éstos utilizan para guardar sus operaciones. Una vez la base de datos ha escrito en sus logs, los sistemas CDC propagan estas operaciones hasta un servicio final, que lo que hará será replicar lo cambios originales o transformados a nuestros destinos. Esta aproximación, basada en logs, es mucho mas liviana que la anterior y no precisa de tantos recursos. Sin embargo, nos obliga a implementar sistemas más resilientes y tolerantes a fallos para evitar desalineamiento de datos entre nuestra fuente y nuestro/s destinos.

Los que tenéis una mente sucia como la mía y no paráis de ver eventos en todo lo que os rodea, habréis imaginado ya las ventajas que supone tener, un sistema de propagación de cambios en base de datos que es capaz incluso de transformarlos, hasta hacerlos llegar a sistemas destino que pueden ser o bien otra base de datos o bien un broker de RabbitMQ o Kafka, favoreciendo así no solo el desacoplamiento de los elementos que conforman el sistema, sino el procesamiento de datos en tiempo real, y que al poderse basar en los logs que los propios SGDB ya manejan, no tiene apenas impacto en el sistema ni en el rendimiento global de las aplicaciones.

Es por esto, que, bajo mi punto de vista, en sistemas complejos en los que conviven distintas fuentes de datos con arquitecturas de eventos (EDA), este concepto se hace imprescindible.

Debezium y Kafka Connect son algunos de los sistemas de código abierto que nos pueden ayudar a implementar CDC en nuestros proyectos.

Espero haberos despertado el gusanillo y una vez más…Gracias por leerme.

Bibliografía:

Tags

Guía de posibilidades profesionales sobre Java
He leído y acepto la política de privacidad
Acepto recibir emails sobre actividades de recruiting NTT DATA