Il Costo Nascosto della Change Data Capture: Capire i Compromessi della CDC su Soluzioni Proxy come DataSunrise

La Change Data Capture (CDC) è un approccio ampiamente utilizzato nelle imprese data-driven per tracciare le modifiche in un database. La CDC consente alle organizzazioni di monitorare le modifiche ai dati (come inserimenti, aggiornamenti ed eliminazioni) e propagare efficacemente queste modifiche ai sistemi a valle. Sebbene la CDC possa offrire valore nel mantenere la coerenza dei dati tra più sistemi, l’attuazione della CDC utilizzando soluzioni proxy, come DataSunrise, può portare a significativi problemi di prestazioni e operativi.

In questo articolo esploreremo cosa sia la CDC, le sfide coinvolte nel suo utilizzo tramite soluzioni proxy come DataSunrise, e perché questa pratica è considerata inefficiente. Includeremo anche esempi dettagliati per illustrare i problemi e l’impatto sulle prestazioni associato a questo approccio.

Che Cos’è la Change Data Capture (CDC)?

La Change Data Capture (CDC) è un meccanismo per identificare e tracciare le modifiche in un database in tempo reale o quasi reale. Catturando operazioni di inserimento, aggiornamento e cancellazione, la CDC garantisce che le modifiche ai dati siano disponibili per analisi, data warehousing, processi ETL e scopi di replica dei dati. La CDC è diventata cruciale per casi d’uso come:

• Replica dei dati per mantenere la sincronizzazione tra diversi database.
• Alimentazione dei dati in sistemi di streaming per analisi in tempo reale.
• Monitoraggio di auditing e conformità.

La CDC può essere implementata in vari modi, come:

1. CDC Basata su Log. Legge direttamente dai log delle transazioni del database.
2. CDC Basata su Trigger. Utilizza i trigger del database per catturare le modifiche.
3. CDC Basata su Polling. Interroga periodicamente le tabelle per rilevare le modifiche.
4. CDC Basata su Proxy. Utilizza un proxy middleware per intercettare e registrare le modifiche ai dati.

In questo articolo ci concentreremo specificamente sulla CDC basata su proxy e sui problemi che introduce, in particolare nel contesto delle soluzioni come DataSunrise.

Come Funziona la CDC con Soluzioni Proxy come DataSunrise

DataSunrise agisce come un proxy middleware che si trova tra l’applicazione e il database, intercettando tutte le query SQL in entrata. Mira a fornire funzionalità di sicurezza, audit e CDC, il che significa che deve catturare ogni modifica apportata ai dati.

Per implementare la CDC, DataSunrise deve determinare le esatte modifiche per ogni operazione di aggiornamento. Questo processo richiede tipicamente di:

1. Eseguire un SELECT statement prima di un aggiornamento, utilizzando le stesse condizioni della dichiarazione UPDATE per catturare lo stato corrente dei dati.
2. Eseguire un altro SELECT statement dopo l’aggiornamento (o utilizzare funzionalità del database come il comando RETURNING) per catturare i valori aggiornati.

Questi passaggi aggiuntivi aumentano significativamente il numero di query eseguite sul database, il che porta a una degradazione delle prestazioni.

Implicazioni sulle Prestazioni della CDC tramite Soluzioni Proxy

1. Aumento del Numero di Query

Uno dei principali svantaggi dell’implementazione della CDC tramite un proxy è l’aumento delle query SELECT aggiuntive necessarie per catturare gli stati “prima” e “dopo” dei dati. Consideriamo il seguente scenario:

Scenario d’Esempio. Operazione di Aggiornamento

Supponiamo che un’applicazione esegua una query UPDATE per modificare i dati del cliente:

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

Per implementare la CDC, DataSunrise deve catturare sia lo stato precedente che quello nuovo dei dati. Questo implica i seguenti passaggi:

Snapshot Pre-Aggiornamento. DataSunrise esegue una dichiarazione SELECT per catturare i valori correnti:

SELECT * FROM customers WHERE customer_id = 12345;

Questa query cattura lo stato “prima”, inclusi i valori del bilancio prima dell’applicazione dell’aggiornamento.

Applicare l’Aggiornamento. La query UPDATE originale viene eseguita:

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

Snapshot Post-Aggiornamento. DataSunrise poi esegue un’altra query per catturare lo stato “dopo”:

SELECT * FROM customers WHERE customer_id = 12345;

In alternativa, se supportato, può utilizzare la clausola RETURNING:

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

Impatto. Per ogni query UPDATE, ci sono ora due dichiarazioni SELECT aggiuntive (o un meccanismo RETURNING alternativo). Questo approccio triplica il numero di query eseguite sul database, risultando in:

• Aumento del Carico sul Database. Il database deve gestire un numero significativamente maggiore di query.
• Aumento del Traffico di Rete. Viene trasferita più data fra il proxy e il database.
• Problemi di Latenza. I viaggi di andata e ritorno per le query aggiuntive introducono latenza, che può portare a tempi di risposta più lenti per l’applicazione.
2. Blocchi e Potenziali Deadlock

Un’altra preoccupazione importante con l’esecuzione di dichiarazioni SELECT aggiuntive è l’impatto sui blocchi del database e il rischio di deadlock.

Scenario d’Esempio. Blocco di Dati e Deadlock

Consideriamo il seguente esempio in cui più transazioni concorrenti stanno aggiornando lo stesso set di record:

• La Transazione A tenta di aggiornare il bilancio per customer_id = 12345.
• Allo stesso tempo, la Transazione B tenta di aggiornare un altro campo, come l’email, per lo stesso cliente.

Per implementare la CDC, DataSunrise deve prima leggere i valori esistenti per entrambe le transazioni. Le dichiarazioni SELECT pre-aggiornamento emesse da entrambe le transazioni possono acquisire blocchi condivisi sui record. Tuttavia, quando le dichiarazioni UPDATE vengono eseguite, entrambe le transazioni hanno bisogno di blocchi esclusivi.

Questo può portare a una situazione in cui:

• La Transazione A detiene un blocco condiviso per la SELECT su customer_id = 12345.
• La Transazione B detiene anche un blocco condiviso per la stessa SELECT.
• Quando entrambe le transazioni tentano di acquisire blocchi esclusivi per l’UPDATE, si trovano mutuamente bloccate, portando a un deadlock.

I deadlock portano all’annullamento di una o più transazioni, il che influisce sull’affidabilità del sistema. L’aumento del numero di query SELECT significa anche che più blocchi vengono mantenuti per periodi più lunghi, aumentando la probabilità che si verifichino deadlock in un ambiente con alta concorrenza.

3. Amplificazione del Carico

La CDC attraverso soluzioni proxy porta a un’amplificazione del carico sul database. Per ogni operazione di modifica (inserimento, aggiornamento, eliminazione), vengono generate più operazioni aggiuntive, amplificando il carico di almeno un fattore di tre. Questo può avere gravi conseguenze:

• Sovraccarico di CPU e I/O. Il server del database deve elaborare molte più query, risultando in un aumento dell’uso di CPU e I/O del disco.
• Contesa delle Query. Con un numero maggiore di query eseguite, c’è una maggiore contesa per le risorse del database come CPU, memoria e blocchi. Questo può portare a tempi di attesa delle query più lunghi e a una riduzione della capacità di throughput.
• Problemi di Scalabilità. Il carico aggiuntivo rende difficile scalare il database per accomodare un numero maggiore di utenti o volumi di transazioni più elevati. La stessa soluzione proxy può diventare un collo di bottiglia, limitando la scalabilità complessiva del sistema.
4. Inefficienza con Query SQL Complesse

Per alcune query SQL complesse, l’uso di una clausola RETURNING potrebbe non essere fattibile. Ad esempio, consideriamo un UPDATE che coinvolge una JOIN tra più tabelle:

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

In questi casi, potrebbe non essere possibile utilizzare una clausola RETURNING per catturare tutti i valori aggiornati, costringendo DataSunrise a emettere query SELECT aggiuntive. Questo risulta in piani di esecuzione delle query ancora più complessi e mette ulteriormente a dura prova il database.

Esempio nel Mondo Reale: Benchmark delle Prestazioni

Consideriamo uno scenario in cui un’applicazione retail ha un database con un alto volume di transazioni. L’applicazione esegue 1.000 operazioni di aggiornamento al secondo su una tabella che memorizza le informazioni sugli ordini dei clienti. Confrontiamo l’impatto dell’uso della CDC tramite DataSunrise rispetto all’uso di un meccanismo di CDC basato su log:

• Senza CDC. L’applicazione esegue 1.000 operazioni UPDATE al secondo.
• Log-Based CDC. Le modifiche sono catturate direttamente dal log delle transazioni, senza query aggiuntive eseguite dall’applicazione.
• Proxy-Based CDC via DataSunrise:
• 1.000 dichiarazioni SELECT Pre-Aggiornamento.
• 1.000 dichiarazioni Update.
• 1.000 dichiarazioni SELECT Post-Aggiornamento (o equivalenti).

Questo risulta in 3.000 query al secondo invece delle originarie 1.000. Il database deve gestire un carico triplicato, portando a:

• Maggiore Utilizzo di CPU e Memoria. Il carico aumentato richiede più risorse.
• Latenza delle Query. I viaggi di andata e ritorno aggiuntivi aumentano la latenza di ogni transazione, influenzando l’esperienza dell’utente finale.
• Problemi di Scalabilità. Il database fa fatica a scalare oltre il volume di transazioni originale a causa dell’amplificazione del carico.

Alternative alla CDC Basata su Proxy

Per evitare i problemi di prestazioni associati alla CDC tramite soluzioni proxy come DataSunrise, considerare le seguenti alternative:

1. CDC Basata su Log:
• La CDC basata su log legge direttamente dal log delle transazioni, che è mantenuto dal database. Questo approccio è efficiente perché non richiede dichiarazioni SELECT aggiuntive né interferisce con il normale flusso di lavoro dell’applicazione.
• Esempi di strumenti di CDC basati su log includono Debezium, Oracle GoldenGate, e AWS Database Migration Service (DMS).
2. CDC Basata su Trigger:
• I trigger del database possono essere utilizzati per catturare le modifiche a livello di riga. Tuttavia, i trigger possono anche introdurre sovraccarico, specialmente per tabelle ad alto volume.
• Questo approccio può essere adatto per carichi di lavoro piccoli o medi dove la complessità di gestione dei trigger è giustificata.
3. CDC Nativa del Database:
• Alcuni database forniscono capacità di CDC native che sono ottimizzate per catturare le modifiche con overhead minimo. Ad esempio, SQL Server offre una funzionalità CDC integrata, e PostgreSQL supporta la replica logica.

Inoltre, implementare la CDC per scopi di monitoraggio tramite mezzi alternativi consente di monitorare solo le modifiche. Le query SELECT e UPDATE/DELETE che non producono cambiamenti non saranno incluse nel monitoraggio.

Conclusione

Implementare la Change Data Capture (CDC) utilizzando una soluzione basata su proxy come DataSunrise può portare a significativi problemi di prestazioni e stabilità, principalmente a causa dell’aumento del numero di query e del potenziale per blocchi dei dati e deadlock. La necessità di query SELECT aggiuntive prima e dopo ogni aggiornamento crea un carico eccessivo sul database, che può severamente degradare le prestazioni, specialmente in ambienti con alta concorrenza.

Invece di affidarsi a una CDC basata su proxy, è consigliabile utilizzare alternative più efficienti come la CDC basata su log, la CDC basata su trigger o le funzionalità CDC native del database. Questi approcci catturano le modifiche senza aggiungere overhead superfluo, assicurando che la vostra applicazione e il database possano scalare efficientemente mantenendo l’integrità dei dati.

In definitiva, la scelta dell’implementazione della CDC deve essere fatta in base a un’attenta valutazione delle necessità di prestazioni, delle esigenze di scalabilità e della complessità operativa. È importante partire dagli obiettivi e comprendere le limitazioni di ciascuna tecnologia. E forse, per un monitoraggio completo, è necessario combinare diverse tecnologie. Evitando le insidie della CDC basata su proxy, si può assicurare che il sistema rimanga performante e affidabile, anche con l’aumentare dei volumi di dati.