I Costi Nascosti del Change Data Capture: Comprendere i Compromessi del CDC su Soluzioni Proxy come DataSunrise

Il Change Data Capture (CDC) è un approccio ampiamente utilizzato nelle imprese guidate dai dati per tracciare le modifiche in un database. CDC permette alle organizzazioni di monitorare le modifiche ai dati (come inserti, aggiornamenti e cancellazioni) e propagare efficientemente queste modifiche ai sistemi a valle. Sebbene CDC possa fornire valore nel mantenere la coerenza dei dati tra sistemi multipli, implementare CDC utilizzando soluzioni proxy, come DataSunrise, può portare a significativi problemi di prestazioni e operativi.

In questo articolo esploreremo cos’è il CDC, le sfide coinvolte nella sua implementazione utilizzando soluzioni proxy come DataSunrise e perché questa pratica è considerata inefficiente. Includeremo anche esempi dettagliati per illustrare i problemi e l’impatto sulle prestazioni associati a questo approccio.

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

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

• Replicazione dei dati per mantenere la sincronizzazione tra diversi database.
• Alimentare sistemi di streaming per analisi in tempo reale.
• Auditing e monitoraggio della conformità.

Il CDC può essere implementato in vari modi, come:

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

In questo articolo, ci concentreremo specificamente sul CDC basato su proxy e sui problemi che introduce, in particolare nel contesto di soluzioni come DataSunrise.

Come Funziona il CDC con Soluzioni Proxy come DataSunrise

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

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

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

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

Implicazioni sulle Prestazioni del CDC tramite Soluzioni Proxy

1. Aumento del Numero di Query

Uno dei principali svantaggi dell’implementare il CDC tramite un proxy è la necessità di ulteriori query SELECT per catturare gli stati “prima” e “dopo” dei dati. Consideriamo il seguente scenario:

Scenario di Esempio. Operazione di Aggiornamento

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

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

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

Scatto Pre-Aggiornamento. DataSunrise emette una SELECT statement per catturare i valori correnti:

SELECT * FROM customers WHERE customer_id = 12345;

Questa query cattura lo stato “prima”, incluso il valore del saldo prima che venga applicato l’aggiornamento.

Applicazione dell’Aggiornamento. La query UPDATE originale viene eseguita:

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

Scatto Post-Aggiornamento. DataSunrise emette quindi un’altra query per catturare lo stato “dopo”:

SELECT * FROM customers WHERE customer_id = 12345;

In alternativa, se supportato, potrebbe utilizzare la clausola RETURNING:

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

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

• Aumento del Carico del Database. Il database deve gestire un numero significativamente più alto di query.
• Aumento del Traffico di Rete. Più dati vengono trasferiti tra il proxy e il database.
• Problemi di Latenza. I viaggi di andata e ritorno per le query aggiuntive introducono latenza, il che può portare a tempi di risposta più lenti per l’applicazione.
2. Blocco e Potenziale Deadlock

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

Scenario di Esempio. Blocco dei Dati e Deadlock

Consideriamo il seguente esempio in cui più transazioni concorrenti aggiornano lo stesso insieme di record:

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

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

Ciò 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, rimangono mutualmente bloccate, portando a un deadlock.

I deadlock comportano l’aborto di una o più transazioni, il che influisce sull’affidabilità del sistema. Il maggior numero di query SELECT significa anche che più blocchi vengono detenuti per periodi più lunghi, aumentando la probabilità che si verifichino deadlock in un ambiente ad alta concorrenza.

3. Amplificazione del Carico

Il CDC tramite soluzioni proxy porta a una amplificazione del carico sul database. Per ogni operazione di cambiamento (inserimento, aggiornamento, cancellazione), vengono generate molte operazioni aggiuntive, amplificando il carico di almeno tre volte. Questo può avere conseguenze gravi:

• Sovraccarico di CPU e I/O. Il server del database deve elaborare molte più query, risultando in un aumento dell’utilizzo della CPU e dell’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 una riduzione della produttività.
• Sfide di Scalabilità. Il carico aggiuntivo rende difficile scalare il database per accomodare più utenti o volumi di transazioni più alti. La soluzione proxy stessa può diventare un collo di bottiglia, limitando la scalabilità complessiva del sistema.
4. Inefficienza con Query SQL Complesse

Per alcune query SQL complesse, l’utilizzo di una clausola RETURNING potrebbe non essere fattibile. Ad esempio, consideriamo un aggiornamento 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 ulteriori query SELECT. Questo risulta in piani di esecuzione delle query ancora più complessi e ulteriori sforzi per 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 per secondo su una tabella che memorizza informazioni sugli ordini dei clienti. Confrontiamo l’impatto dell’utilizzo del CDC tramite DataSunrise rispetto all’utilizzo di un meccanismo di CDC basato sui log:

• Senza CDC. L’applicazione esegue 1.000 operazioni di UPDATE per secondo.
• CDC Basato sui Log. Le modifiche vengono catturate direttamente dal log delle transazioni, risultando in nessuna query aggiuntiva eseguita dall’applicazione.
• CDC Basato su Proxy tramite DataSunrise:
• 1.000 SELECT Pre-Aggiornamento statement.
• 1.000 Update statement.
• 1.000 SELECT Post-Aggiornamento statement (o equivalente).

Questo risulta in 3.000 query per secondo invece delle originali 1.000. Il database deve gestire tre volte il carico, portando a:

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

Alternative al CDC Basato su Proxy

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

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

Inoltre, l’implementazione del CDC per scopi di monitoraggio tramite mezzi alternativi permette di monitorare solo le modifiche. Le query SELECT e UPDATE/DELETE che non producono modifiche non saranno incluse nel monitoraggio.

Conclusione

Implementare il 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 di dati e deadlock. La necessità di ulteriori query SELECT prima e dopo ogni aggiornamento crea un carico eccessivo sul database, che può gravemente degradare le prestazioni, specialmente in ambienti ad alta concorrenza.

Invece di fare affidamento sul CDC basato su proxy, è consigliabile utilizzare alternative più efficienti come il CDC basato sui log, il CDC basato su trigger o le funzionalità CDC native del database. Questi approcci catturano le modifiche senza aggiungere overhead non necessario, garantendo che la tua applicazione e il tuo database possano scalare in modo efficiente mantenendo l’integrità dei dati.

In definitiva, la scelta dell’implementazione del CDC dovrebbe essere basata su una valutazione attenta dei requisiti di prestazione, delle esigenze di scalabilità e della complessità operativa. È importante procedere dagli obiettivi e comprendere le limitazioni di ciascuna tecnologia. E forse per un monitoraggio completo, è necessario combinare diverse tecnologie. Evitando le insidie del CDC basato su proxy, è possibile assicurare che il proprio sistema rimanga performante e affidabile, anche con la crescita dei volumi di dati.