Inicio
Noticias Profesionales
Los Costos Ocultos de la Captura de Datos de Cambio: Entendiendo los Compromisos del CDC en Soluciones Proxy como DataSunrise

Los Costos Ocultos de la Captura de Datos de Cambio: Entendiendo los Compromisos del CDC en Soluciones Proxy como DataSunrise

La Captura de Datos de Cambio (CDC) es un enfoque ampliamente utilizado en empresas basadas en datos para rastrear cambios en una base de datos. El CDC permite a las organizaciones monitorear modificaciones de datos (como inserciones, actualizaciones y eliminaciones) y propagar estos cambios de manera eficiente a sistemas downstream. Si bien el CDC puede proporcionar valor al mantener la consistencia de los datos a través de múltiples sistemas, implementar el CDC usando soluciones proxy, como DataSunrise, puede llevar a problemas de rendimiento significativos y dolores de cabeza operativos.

En este artículo, exploraremos qué es el CDC, los desafíos involucrados en implementarlo 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 la Captura de Datos de Cambio (CDC)?

La Captura de Datos de Cambio (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, el CDC asegura que los cambios de datos estén disponibles para análisis, almacenamiento de datos, procesos ETL y propósitos de replicación de datos. El 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 datos a sistemas de streaming para análisis en tiempo real.
Monitoreo de auditoría y cumplimiento.

El CDC se puede implementar de varias maneras, tales como:

CDC basado en registros. Lee directamente de los registros de transacciones de la base de datos.
CDC basado en triggers. Usa triggers de base de datos para capturar cambios.
CDC basado en sondeo. Sondos tablas periódicamente para detectar cambios.
CDC basado en proxy. Usa un proxy intermedio para interceptar y registrar cambios de datos.

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

Cómo Funciona el CDC con Soluciones Proxy como DataSunrise

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

Para implementar el CDC, DataSunrise necesita determinar las modificaciones exactas para cada operación de actualización. Este proceso generalmente requiere:

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

Estos pasos adicionales aumentan significativamente el número de consultas que se ejecutan en la base de datos, lo que conduce a una degradación del rendimiento.

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

Aumento del Número de Consultas

Una de las principales desventajas de implementar el CDC a través de un proxy es la adición de consultas SELECT necesarias para capturar los estados de los datos “antes” y “después”. Consideremos el siguiente escenario:

Escenario de Ejemplo. Operación de Actualización

Supongamos que una aplicación ejecuta una consulta UPDATE para modificar los datos del cliente:

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

Para implementar el 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 sentencia SELECT para capturar los valores actuales:

SELECT * FROM customers WHERE customer_id = 12345;

Esta consulta captura el estado “antes”, incluido el valor del balance antes de aplicar 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 compatible, podría usar la cláusula RETURNING:

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

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

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

Bloqueos y Potenciales Interbloqueos

Otra preocupación importante con la ejecución de consultas SELECT adicionales es el impacto en los bloqueos de la base de datos y el riesgo de interbloqueos.

Escenario de Ejemplo. Bloqueo de Datos e Interbloqueos

Consideremos el siguiente ejemplo donde 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 un campo diferente, como el correo electrónico, para el mismo cliente.

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

Esto puede llevar a una situación donde:

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

Los interbloqueos resultan en que una o más transacciones sean abortadas, lo que afecta la fiabilidad del sistema. El mayor número de consultas SELECT también significa que se mantienen más bloqueos durante más tiempo, aumentando la probabilidad de que ocurran interbloqueos en un entorno de alta concurrencia.

Amplificación de Carga

El CDC a través de soluciones proxy lleva a una amplificación de carga en la base de datos. Para cada operación de cambio (insertar, actualizar, eliminar), se generan múltiples operaciones adicionales, amplificando la carga por al menos un factor de tres. Esto puede tener graves consecuencias:

Sobrecarga de CPU y I/O. El servidor de la base de datos tiene que procesar muchas más consultas, resultando en un mayor uso de CPU y disco I/O.
Contención de Consultas. Con un mayor número de consultas ejecutándose, hay una mayor contención de los recursos de la base de datos como la CPU, la memoria y los bloqueos. Esto puede llevar a tiempos de espera de consultas más largos y reducción del rendimiento.
Desafíos de Escalabilidad. La carga adicional hace que sea un desafío escalar la base de datos para acomodar más usuarios o mayores volúmenes de transacciones. 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, usar una cláusula RETURNING podría no ser factible. Por ejemplo, consideremos una actualización que involucra un JOIN a través de 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 usar una cláusula RETURNING para capturar todos los valores actualizados, forzando a DataSunrise a emitir consultas SELECT adicionales. Esto resulta en planes de ejecución de consultas aún más complejos y pone más tensión en la base de datos.

Ejemplo del Mundo Real: Benchmark de Rendimiento

Consideremos un escenario donde 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 la información de los pedidos de clientes. Comparemos el impacto de usar el CDC a través de DataSunrise versus usar un mecanismo de CDC basado en registros:

Sin CDC. La aplicación realiza 1,000 operaciones UPDATE por segundo.
CDC Basado en Registros. Los cambios se capturan directamente desde el registro de transacciones, resultando en ninguna consulta adicional ejecutada por la aplicación.
CDC Basado en Proxy a través de DataSunrise:

1,000 Sentencias SELECT Pre-Actualización.
1,000 Sentencias Update.
1,000 Sentencias 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, llevando a:

Mayor Utilización de CPU y Memoria. La carga aumentada requiere más recursos.
Latencia de Consultas. Los viajes de ida y vuelta aumentan la latencia de cada transacción, impactando la experiencia del usuario final.
Problemas de Escalabilidad. La base de datos lucha por escalar más allá del volumen de transacción original debido a la amplificación de carga.

Alternativas al CDC Basado en Proxy

Para evitar las dificultades de rendimiento asociadas con el CDC a través de soluciones proxy como DataSunrise, considere las siguientes alternativas:

CDC Basado en Registros:

El CDC basado en registros lee directamente del registro 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 trabajo de la aplicación.
Ejemplos de herramientas de CDC basadas en registros incluyen Debezium, Oracle GoldenGate, y AWS Database Migration Service (DMS).

CDC Basado en Triggers:

Se pueden usar triggers de base de datos para capturar cambios a nivel de fila. Sin embargo, los triggers también pueden introducir sobrecarga, especialmente para tablas de alto volumen.
Este enfoque puede ser adecuado para cargas medianas y pequeñas donde la complejidad de manejar triggers está justificada.

CDC Nativo de la Base de Datos:

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

Además, implementar el CDC para fines de monitoreo por otros medios permite monitorear solo los cambios. Las consultas SELECT y UPDATE/DELETE que no producen ningún cambio no serán incluidas en el monitoreo.

Conclusión

La implementación de la Captura de Datos de Cambio (CDC) usando una solución basada en proxy como DataSunrise puede llevar a significativos problemas de rendimiento y estabilidad, principalmente debido al aumento del número de consultas y el potencial de bloqueos de datos e interbloqueos. La necesidad de consultas SELECT adicionales antes y después de cada actualización crea una carga excesiva en la base de datos, la cual puede degradar severamente el rendimiento, especialmente en entornos de alta concurrencia.

En lugar de confiar en el CDC basado en proxy, es aconsejable usar alternativas más eficientes como el CDC basado en registros, el CDC basado en triggers o características nativas de CDC de la base de datos. Estos enfoques capturan cambios sin añadir sobrecarga innecesaria, asegurando que su aplicación y base de datos puedan escalar eficientemente mientras mantienen la integridad de los datos.

En última instancia, la elección de la implementación de CDC debe hacerse en función de una evaluación cuidadosa de los requisitos de rendimiento, las necesidades de escalabilidad y la complejidad operativa. Es importante proceder desde los objetivos y entender las limitaciones de cada tecnología. Y tal vez para un monitoreo completo, sea necesario combinar diferentes tecnologías. Al evitar las dificultades del CDC basado en proxy, puede asegurar que su sistema permanezca funcional y fiable, incluso a medida que aumentan los volúmenes de datos.