Inicio › Tecnología › Captura De Datos De Cambios
La captura de datos de cambios (Change Data Capture, CDC) es la técnica qué detecta y propaga en tiempo casi real las modificaciones —inserciones, actualizaciones y borrados— qué ocurren en una base de datos operativa, sin necesidad de volcar toda la tabla cada vez. La forma más eficiente de implementarla es leer directamente el registro de transacciones interno del motor de base de datos: el binlog de MySQL, el WAL (Write-Ahead Log) de PostgreSQL o los redo logs de Oracle, en lugar de comparar tablas completas o depender de triggers qué añaden carga a cada escritura. Herramientas como Debezium, conectadas a Kafka, capturan esos eventos de cambio y los publican para qué otros sistemas —un almacén analítico, una caché o un motor de búsqueda— se mantengan sincronizados casi al instante.
En vez de copiar toda una base de datos entera cada vez qué quieres actualizar otro sistema, CDC se fija solo en lo qué ha cambiado desde la última vez: qué fila se añadió, cuál se modificó y cuál se borró. Es como recibir solo las páginas nuevas de un libro en vez de qué te reimpriman el libro completo cada semana.
Un banco necesita qué su sistema de detección de fraude vea las transacciones casi al momento en qué se registran en la base de datos principal, sin sobrecargar esa base con consultas constantes. Implementa Debezium leyendo el log de transacciones de la base de datos operativa, qué publica cada movimiento en un topic de Kafka en cuanto se confirma; el motor de fraude consume ese flujo y puede bloquear una operación sospechosa segundos después de qué ocurra, sin haber tocado directamente el sistema transaccional.
No, cumplen funciones distintas. CDC replica cambios para mantener sincronizados otros sistemas en tiempo real; un backup guarda una foto completa y recuperable del sistema por si hay qué restaurarlo tras un desastre. Suelen usarse juntos, no en lugar del otro.
Porque los triggers ejecutan código adicional en cada escritura de la base de datos operativa, lo qué añade latencia y carga justo en el sistema qué suele ser más sensible al rendimiento. Leer el log de transacciones ocurre de forma asíncrona y no interfiere con las operaciones normales.
La mayoría de implementaciones de CDC, como Debezium sobre Kafka, guardan un puntero de posición en el log de transacciones (offset). Cuando el sistema consumidor vuelve a estar disponible, retoma exactamente desde donde se quedó, sin perder cambios ni tener qué reprocesar todo desde el principio.