Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica dei flussi di modifiche

Bigtable fornisce il monitoraggio delle modifiche (CDC) con la funzionalità flussi di modifiche. Un flusso di modifiche acquisisce le modifiche ai dati di una tabella Bigtable man mano che si verificano, consentendoti di trasmetterle in streaming per l'elaborazione o l'analisi.

Questo documento fornisce una panoramica degli modifiche in tempo reale di Bigtable. Prima di leggere questo documento, devi avere familiarità con la panoramica di Bigtable.

Gli stream di variazioni sono utili per i casi d'uso dei CDC, tra cui:

Attivazione della logica dell'applicazione a valle quando si verificano modifiche specifiche
Integrazione con una pipeline di analisi dei dati
Supporto dei requisiti di controllo e archiviazione

Che cos'è un flusso di modifiche

Uno stream di modifiche tiene traccia delle modifiche a livello di tabella apportate da un utente o da un'applicazione, in genere utilizzando una delle librerie client di Cloud Bigtable. Vengono acquisite anche le modifiche al garbage collection.

Tutte le modifiche applicate a una tabella abilitata per i flussi di modifiche vengono archiviate come record di variazione dei dati. I record delle modifiche ai dati includono le modifiche ai dati applicate da quanto segue:

Scritture, eliminazioni e aggiornamenti inviati utilizzando i metodi dell'API Cloud BigtableMutateRow, MutateRows, CheckAndMutateRow e ReadModifyWriteRow
Eliminazioni che si verificano a causa della garbage collection
Righe eliminate utilizzando il metodo DropRowRange dell'API Admin

Per informazioni dettagliate sui tipi di modifiche che puoi inviare a una tabella Bigtable, consulta Letture, Scritture, Eliminazioni e Panoramica del garbage collection.

I flussi di modifiche non monitorano le modifiche allo schema, ad esempio l'aggiunta o la modifica di una famiglia di colonne o la topologia di replica, ad esempio l'aggiunta o la rimozione di un cluster.

I record di modifica dei dati per ogni chiave di riga e ogni cluster sono in ordine di timestamp commit. Tuttavia, non esiste alcuna garanzia di ordinamento per i record di modifica dei dati per un cluster o una chiave di riga diversa.

Attiva modifiche in tempo reale in una tabella e specifica un periodo di conservazione compreso tra 1 e 7 giorni.

Contenuto di un record di modifica dei dati

Ogni record di modifica dei dati contiene tutte le modifiche apportate a una riga in modo atomico nell'ambito di una singola chiamata RPC.

Se un valore viene sovrascritto, il valore appena scritto viene registrato nel record di variazione dei dati. Il record di modifica dei dati non contiene il vecchio valore.

Un record di modifica dei dati riceve il timestamp, chiamato timestamp del commit, contemporaneamente all'applicazione della modifica al primo cluster che lo riceve. Ad esempio, considera un'istanza con due cluster. Se invii una richiesta di scrittura alla tabella 1 del cluster A, il timestamp di commit del record di modifica dei dati viene assegnato quando la scrittura viene ricevuta dal cluster A e il record di modifica dei dati sul cluster B per questa scrittura ha lo stesso timestamp di commit.

Ogni record di modifica dei dati contiene quanto segue:

voci: le modifiche apportate alla riga, tra cui una o più delle seguenti:
- Scrivi
  - Famiglia di colonne
  - Qualificatore di colonna
  - Timestamp
  - Valore
- Eliminazione delle celle
  - Famiglia di colonne
  - Qualificatore di colonna
  - Intervallo di timestamp
- Eliminazione di una famiglia di colonne
  - Famiglia di colonne
  - Eliminazione da una riga: l'eliminazione da una riga viene convertita in un elenco di eliminazioni dalle famiglie di colonne per ogni famiglia di colonne in cui la riga contiene dati.
Chiave di riga: l'identificatore della riga modificata
Tipo di modifica: avviata dall'utente o garbage collection
ID del cluster che ha ricevuto la modifica
Timestamp di commit: ora lato server in cui è stato eseguito il commit della modifica nella tabella
Tie breaker: un valore che consente all'applicazione che legge lo stream di utilizzare le norme di risoluzione dei conflitti integrate di Bigtable.
Token: utilizzato dall'applicazione di destinazione per riprendere lo stream se viene interrotto
Spostamento minimo stimato: il tempo stimato dall'ultima volta che la partizione del record ha raggiunto la replica in tutti i cluster. Per maggiori dettagli, consulta Partizioni e Marchi d'acqua.

Per ulteriori informazioni sui campi di un record di modifica dei dati, consulta il riferimento all'API per DataChange.

Spazio di archiviazione per le modifiche in tempo reale

Una tabella e il relativo stream di modifiche condividono le stesse risorse a livello di cluster, inclusi i nodi e lo spazio di archiviazione. Di conseguenza, lo spazio di archiviazione dei dati del flusso di modifiche fa parte dello spazio di archiviazione di una tabella. In un'istanza che utilizza la replica, una copia dei dati di un stream di modifiche viene archiviata in ogni cluster dell'istanza contenente la tabella abilitata per gli stream di modifiche.

Lo spazio di archiviazione utilizzato per i dati del flusso di modifiche non viene conteggiato ai fini dell'utilizzo totale dello spazio di archiviazione (% max). Di conseguenza, non è necessario aggiungere nodi per gestire l'aumento dello spazio di archiviazione consumato dai dati dello stream delle modifiche (anche se potrebbe essere necessario aggiungere nodi per una maggiore potenza di calcolo). Tuttavia, ti viene addebitato il costo dello spazio di archiviazione utilizzato dai dati del flusso di modifiche. Per maggiori dettagli, consulta la sezione Aspetti relativi ai costi.

Lettura di un flusso di modifiche

Per leggere (riprodurre in streaming) un stream delle modifiche, devi utilizzare un profilo dell'applicazione configurato per il routing a cluster singolo e, se riproduci in streaming utilizzando Dataflow, devi attivare le transazioni a riga singola.

Per ulteriori informazioni sui criteri di routing, consulta Opzioni di routing.

Per ulteriori informazioni sulle transazioni su riga singola, consulta la sezione Transazioni su riga singola.

I metodi di flusso di modifiche sono forniti dall'API Cloud Bigtable (API Data). Ti consigliamo di utilizzare una delle seguenti opzioni anziché chiamare l'API senza utilizzare una libreria client o un connettore:

Modelli Dataflow
Connettore Bigtable Beam
Libreria client Java

Tutte le opzioni ti consentono di evitare di dover monitorare e gestire le modifiche delle partizioni a causa di suddivisioni e unioni.

Per ulteriori informazioni, consulta ReadChangeStream.

Modelli Dataflow

Puoi utilizzare uno dei seguenti modelli Dataflow forniti da Google:

Connettore Bigtable Beam

Puoi utilizzare il connettore Bigtable Beam per creare una pipeline:

Connettore Bigtable Beam

Se non vuoi creare la tua pipeline, puoi utilizzare gli esempi di codice del tutorial o della guida introduttiva di Bigtable come punto di partenza per il tuo codice:

Libreria client Java

Client Cloud Bigtable per Java

Partizioni

Per mantenere un'elevata velocità in lettura che corrisponda a una frequenza elevata di scrittura o modifica, Bigtable suddivide uno stream delle modifiche in più partizioni che possono essere utilizzate per leggere lo stream delle modifiche in parallelo. Ogni partizione dello stream di modifiche è associata a un tablet. I tablet sono sottosezioni di una tabella che vengono ridistribuite in base alle esigenze per contribuire a bilanciare il carico di lavoro delle richieste della tabella. Per saperne di più, consulta Bilanciamento del carico.

La libreria client Java ti consente di eseguire query su ogni partizione per rilevare le modifiche e fornisce le informazioni necessarie per gestire le modifiche nelle partizioni dovute a suddivisioni e unioni.

Filigrane

Un segno di spunta è un timestamp che stima quanto di recente una partizione ha raggiunto la replica in tutti i cluster. La filigrana della partizione viene aggiornata continuamente man mano che si verifica la replica, procedendo nel tempo.

Ogni ChangeStreamMutation (record di modifica dei dati) include un estimatedLowWatermark, ovvero la filigrana della partizione associata al record di modifica dei dati. Questo valore estimatedLowWatermark è un' stima e non garantisce che non ci siano dati che devono ancora arrivare nello stream.

Filigrane per le tabelle replicate

Il valore estimatedLowWatermark (soglia minima) di una partizione non avanza se la replica non è stata completata per la partizione. La filigrana minima per l'intero stream, ovvero la più bassa di tutte le filigrane minime stimate a livello di partizione, interrompe l'avanzamento se la filigrana di una partizione non avanza. Una filigrana che ha smesso di avanzare è considerata bloccata. In questo caso, se stai eseguendo lo streaming dello stream delle modifiche in una pipeline, la pipeline si blocca.

Molti fattori possono causare l'interruzione di una o più filigrane a livello di partizione per un certo periodo di tempo, tra cui:

Sovraccarico di un cluster con traffico che causa un ritardo della replica per una o più partizioni
Ritardi della rete
Mancata disponibilità del cluster

Il connettore Beam Bigtable gestisce questo problema impostando il timestamp di output su zero per tutti i dati. Per ulteriori informazioni, vedi Raggruppare i dati senza orari degli eventi.

Monitoraggio

Per aiutarti a capire in che modo l'attivazione di un stream di modifiche influisce sull'utilizzo della CPU e dello spazio di archiviazione per un'istanza contenente tabelle con stream di modifiche abilitati, forniamo due metriche specifiche per gli stream di modifiche. Puoi visualizzare le metriche nella pagina Monitoraggio Bigtable o utilizzando la suite di strumenti Cloud Monitoring.

Byte utilizzati dai record del flusso di modifiche (change_stream_log_used_bytes)
Utilizzo della CPU per modifiche in tempo reale ( utilizza cpu_load_by_app_profile_by_method_by_table)

Per informazioni dettagliate su queste metriche, consulta Monitoraggio.

Considerazioni sui costi

L'attivazione di uno stream di modifiche in una tabella comporta un aumento dei costi per i nodi e lo spazio di archiviazione. In particolare, puoi aspettarti di sostenere costi di archiviazione superiori.

Nodi

In genere, devi aggiungere nodi a un cluster (o aumentare il numero massimo di nodi se utilizzi la scalabilità automatica) per gestire il traffico aggiuntivo dovuto all'attivazione e all'elaborazione dei record di modifica dei dati.

L'attivazione di un flusso di modifiche può aumentare l'utilizzo della CPU di circa il 10%, anche prima di iniziare a elaborarlo. L'elaborazione di un stream delle modifiche, ad esempio la lettura con una pipeline Dataflow, può aumentare l'utilizzo della CPU di circa il 20-30%, a seconda del livello di attività di modifica e del modo in cui vengono letti i dati dello stream.

Archiviazione

Ti vengono addebitate le tariffe di archiviazione di Bigtable standard per archiviare i record delle modifiche dei dati della tabella. Ti vengono addebitati anche i costi di archiviazione della tabella creata per monitorare i metadati del flusso di modifiche. Il periodo di conservazione specificato influisce direttamente sui costi di archiviazione.

Come regola generale, un giorno di record di variazione dei dati, che riflettono solo le mutazioni avvenute quel giorno, occupa circa 1,5 volte lo spazio di archiviazione necessario per i dati scritti quel giorno sul disco.

Trasferimento di dati di rete

Se leggi uno stream di modifiche in più regioni, potresti dover sostenere costi per questo traffico. Consulta la sezione Rete nella pagina Prezzi di Bigtable per un elenco completo delle tariffe di trasferimento di dati di rete.

Costi di elaborazione

A seconda di come leggi i record di modifica dei dati, si applicano costi aggiuntivi per servizi diversi da Bigtable. Ad esempio, se utilizzi Dataflow, paghi per i byte elaborati e per le macchine worker che elaborano il job. Per i dettagli, consulta Prezzi di Dataflow.

Inserire intervalli di righe

Se possibile, evita di eliminare un intervallo di righe da una tabella in cui è attivato uno stream di modifiche. Se devi eliminare un intervallo di righe, tieni presente che Bigtable potrebbe impiegare molto tempo per completare l'operazione e l'utilizzo della CPU aumenta durante l'operazione.