Inicio
Noticias Profesionales
Los Costos Ocultos de Change Data Capture: Entendiendo los Trade-offs de CDC en Soluciones Proxy como DataSunrise

Los Costos Ocultos de Change Data Capture: Entendiendo los Trade-offs de CDC en Soluciones Proxy como DataSunrise

Change Data Capture (CDC) es un enfoque ampliamente utilizado en empresas orientadas a datos para rastrear cambios en una base de datos. CDC permite a las organizaciones monitorear las modificaciones de datos (como inserciones, actualizaciones y eliminaciones) y propagar eficientemente estos cambios a sistemas downstream. Aunque CDC puede aportar valor al mantener la consistencia de los datos a través de múltiples sistemas, implementar CDC utilizando soluciones proxy, como DataSunrise, puede conducir a problemas significativos de rendimiento y dolores de cabeza operativos.

En este artículo, exploraremos qué es CDC, los desafíos involucrados en su implementación usando soluciones proxy como DataSunrise y por qué esta práctica se considera ineficiente. También incluiremos ejemplos detallados para ilustrar los problemas y el impacto en el rendimiento asociados con este enfoque.

¿Qué es Change Data Capture (CDC)?

Change Data Capture (CDC) es un mecanismo para identificar y rastrear cambios en una base de datos en tiempo real o casi en tiempo real. Al capturar operaciones de inserción, actualización y eliminación, CDC asegura que los cambios de datos estén disponibles para análisis, almacenamiento de datos, procesos ETL y fines de replicación de datos. CDC se ha vuelto crucial para casos de uso como:

Replicación de datos para mantener la sincronización entre diferentes bases de datos.
Alimentar los datos en sistemas de streaming para análisis en tiempo real.
Monitoreo de auditorías y cumplimiento normativo.

CDC se puede implementar de diversas maneras, tales como:

CDC Basado en Logs. Lee directamente de los logs de transacciones de la base de datos.
CDC Basado en Triggers. Utiliza triggers en la base de datos para capturar cambios.
CDC Basado en Polling. Consulta las tablas periódicamente para detectar cambios.
CDC Basado en Proxy. Utiliza un proxy middleware para interceptar y registrar los cambios de datos.

En este artículo, nos enfocamos específicamente en CDC basado en proxy y los problemas que introduce, particularmente en el contexto de soluciones como DataSunrise.

Cómo Funciona CDC con Soluciones Proxy como DataSunrise

DataSunrise actúa como un proxy middleware que se sitúa entre la aplicación y la base de datos, interceptando todas las consultas SQL entrantes. Su objetivo es proporcionar funcionalidades de seguridad, auditoría y CDC, lo que significa que debe capturar cada cambio realizado en los datos.

Para implementar CDC, DataSunrise necesita determinar las modificaciones exactas para cada operación de actualización. Este proceso típicamente requiere que:

Ejecute una instrucción SELECT antes de una actualización, utilizando las mismas condiciones que la instrucción UPDATE para capturar el estado actual de los datos.
Ejecute otra instrucción SELECT después de la actualización (o utilice características de la base de datos como RETURNING) para capturar los valores actualizados.

Estos pasos adicionales aumentan significativamente la cantidad de consultas ejecutadas en la base de datos, lo que conduce a una degradación del rendimiento.

Implicaciones en el Rendimiento del CDC a través de Soluciones Proxy

Aumento en el Número de Consultas

Uno de los mayores inconvenientes de implementar CDC mediante un proxy es la necesidad de consultas SELECT adicionales requeridas para capturar los estados “antes” y “después” de los datos. Consideremos el siguiente escenario:

Escenario de Ejemplo. Operación de Actualización

Supongamos que una aplicación ejecuta una consulta UPDATE para modificar datos de un cliente:

UPDATE customers SET balance = balance + 100 WHERE customer_id = 12345;

Para implementar CDC, DataSunrise necesita capturar tanto el estado anterior como el nuevo de los datos. Esto involucra los siguientes pasos:

Instantánea Pre-Actualización. DataSunrise emite una instrucción SELECT para capturar los valores actuales:

SELECT * FROM customers WHERE customer_id = 12345;

Esta consulta captura el estado “antes”, incluyendo el valor de balance antes de que se aplique la actualización.

Aplicar la Actualización. Se ejecuta la consulta UPDATE original:

UPDATE customers SET balance = balance + 100 WHERE customer_id = 12345;

Instantánea Post-Actualización. DataSunrise luego emite otra consulta para capturar el estado “después”:

SELECT * FROM customers WHERE customer_id = 12345;

Alternativamente, si es soportado, podría usar la cláusula RETURNING:

UPDATE customers SET balance = balance + 100 WHERE customer_id = 12345 RETURNING *;

Impacto. Por cada consulta UPDATE, ahora existen dos consultas SELECT adicionales (o un mecanismo RETURNING equivalente). Este enfoque triplica el número de consultas ejecutadas en la base de datos, resultando en:

Aumento de la Carga en la Base de Datos. La base de datos debe manejar un número significativamente mayor de consultas.
Aumento del Tráfico de Red. Se transfiere más datos entre el proxy y la base de datos.
Problemas de Latencia. Los viajes de ida y vuelta de las consultas adicionales introducen latencia, lo que puede llevar a tiempos de respuesta más lentos para la aplicación.

Bloqueo y Posibles Deadlocks

Otro problema importante al ejecutar consultas SELECT adicionales es el impacto en los bloqueos de la base de datos y el riesgo de deadlocks.

Escenario de Ejemplo. Bloqueo de Datos y Deadlocks

Considere el siguiente ejemplo en el que múltiples transacciones concurrentes están actualizando el mismo conjunto de registros:

La Transacción A intenta actualizar el balance para customer_id = 12345.
Al mismo tiempo, la Transacción B intenta actualizar otro campo, como el correo electrónico, para el mismo cliente.

Para implementar CDC, DataSunrise primero necesita leer los valores existentes para ambas transacciones. Las instrucciones SELECT pre-actualización emitidas por ambas transacciones pueden adquirir bloqueos compartidos sobre los registros. Sin embargo, cuando se ejecutan las instrucciones UPDATE, ambas transacciones necesitan bloqueos exclusivos.

Esto puede llevar a una situación en la que:

La Transacción A mantiene un bloqueo compartido por el SELECT en customer_id = 12345.
La Transacción B también mantiene un bloqueo compartido por el mismo SELECT.
Cuando ambas transacciones intentan adquirir bloqueos exclusivos para el UPDATE, se bloquean mutuamente, conduciendo a un deadlock.

Los deadlocks resultan en que una o más transacciones sean abortadas, lo cual afecta la confiabilidad del sistema. El aumento en el número de consultas SELECT también significa que se mantienen más bloqueos por períodos de tiempo más largos, aumentando la probabilidad de que ocurran deadlocks en un entorno de alta concurrencia.

Amplificación de la Carga

El CDC mediante soluciones proxy conduce a una amplificación de la carga en la base de datos. Por cada operación de cambio (inserción, actualización, eliminación), se generan múltiples operaciones adicionales, amplificando la carga al menos por un factor de tres. Esto puede tener consecuencias severas:

Sobrehead en CPU y I/O. El servidor de la base de datos tiene que procesar muchas más consultas, resultando en un aumento del uso de la CPU y del I/O del disco.
Contención de Consultas. Con mayor número de consultas ejecutadas, hay más competencia por recursos de la base de datos como CPU, memoria y bloqueos. Esto puede conducir a mayores tiempos de espera para las consultas y a una reducción en el rendimiento.
Desafíos de Escalabilidad. La carga adicional dificulta escalar la base de datos para acomodar más usuarios o volúmenes de transacciones mayores. La propia solución proxy puede convertirse en un cuello de botella, limitando la escalabilidad general del sistema.

Ineficiencia con Consultas SQL Complejas

Para ciertas consultas SQL complejas, el uso de una cláusula RETURNING puede no ser factible. Por ejemplo, considere un UPDATE que involucra un JOIN entre múltiples tablas:

UPDATE customers
SET balance = balance + 100
FROM transactions
WHERE customers.customer_id = transactions.customer_id AND transactions.status = 'completed';

En tales casos, puede no ser posible utilizar la cláusula RETURNING para capturar todos los valores actualizados, obligando a DataSunrise a emitir consultas SELECT adicionales. Esto resulta en planes de ejecución de consultas aún más complejos y aumenta la carga sobre la base de datos.

Ejemplo del Mundo Real: Benchmark de Rendimiento

Considere un escenario en el que una aplicación de retail tiene una base de datos con un alto volumen de transacciones. La aplicación realiza 1,000 operaciones de actualización por segundo en una tabla que almacena información de pedidos de clientes. Comparemos el impacto de usar CDC mediante DataSunrise versus usar un mecanismo de CDC basado en logs:

Sin CDC. La aplicación realiza 1,000 operaciones UPDATE por segundo.
CDC Basado en Logs. Los cambios se capturan directamente desde el log de transacciones, lo que resulta en que la aplicación no ejecute consultas adicionales.
CDC Basado en Proxy mediante DataSunrise:

1,000 consultas SELECT Pre-Actualización.
1,000 actualizaciones (UPDATE).
1,000 consultas SELECT Post-Actualización (o equivalente).

Esto resulta en 3,000 consultas por segundo en lugar de las 1,000 originales. La base de datos necesita manejar tres veces la carga, lo que conduce a:

Mayor Utilización de CPU y Memoria. La carga incrementada implica que se requieren más recursos.
Latencia en las Consultas. Los viajes de ida y vuelta adicionales añaden latencia a cada transacción, impactando la experiencia del usuario final.
Problemas de Escalabilidad. La base de datos lucha por escalar más allá del volumen original de transacciones debido a la amplificación de la carga.

Alternativas al CDC Basado en Proxy

Para evitar las desventajas de rendimiento asociadas con CDC mediante soluciones proxy como DataSunrise, considere las siguientes alternativas:

CDC Basado en Logs:

El CDC basado en logs lee directamente del log de transacciones, que es mantenido por la base de datos. Este enfoque es eficiente porque no requiere consultas SELECT adicionales ni interfiere con el flujo normal de la aplicación.
Ejemplos de herramientas de CDC basadas en logs incluyen Debezium, Oracle GoldenGate y AWS Database Migration Service (DMS).

CDC Basado en Triggers:

Se pueden utilizar triggers en la base de datos para capturar cambios a nivel de fila. Sin embargo, los triggers también pueden introducir sobrecarga, especialmente en tablas de alto volumen.
Este enfoque puede ser adecuado para cargas de trabajo pequeñas a medianas donde la complejidad de gestionar triggers se justifica.

CDC Nativo de la Base de Datos:

Algunas bases de datos proporcionan capacidades nativas de CDC que están optimizadas para capturar cambios con una sobrecarga mínima. Por ejemplo, SQL Server ofrece una característica incorporada de CDC, y PostgreSQL soporta la replicación lógica.

Además, implementar CDC para fines de monitoreo mediante medios alternativos permite observar únicamente los cambios. Las consultas SELECT y UPDATE/DELETE que no producen cambios no serán incluidas en el monitoreo.

Conclusión

Implementar Change Data Capture (CDC) utilizando una solución basada en proxy como DataSunrise puede conducir a importantes problemas de rendimiento y estabilidad, principalmente debido al aumento en el número de consultas y al potencial de bloqueos y deadlocks. La necesidad de emitir consultas SELECT adicionales antes y después de cada actualización crea una carga excesiva en la base de datos, lo que puede degradar severamente el rendimiento, especialmente en entornos de alta concurrencia.

En lugar de depender de CDC basado en proxy, es recomendable utilizar alternativas más eficientes como CDC basado en logs, CDC basado en triggers o las características nativas de CDC de la base de datos. Estos enfoques capturan los cambios sin añadir sobrecargas innecesarias, garantizando que su aplicación y base de datos puedan escalar de manera eficiente mientras mantienen la integridad de los datos.

En última instancia, la elección de la implementación de CDC debe hacerse basándose en una evaluación cuidadosa de los requisitos de rendimiento, las necesidades de escalabilidad y la complejidad operativa. Es importante proceder en función de los objetivos y comprender las limitaciones de cada tecnología. Y quizá, para un monitoreo completo, sea necesario combinar diferentes tecnologías. Al evitar las trampas del CDC basado en proxy, se puede garantizar que el sistema se mantenga eficiente y confiable, incluso a medida que aumenten los volúmenes de datos.