Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica delle modifiche in tempo reale

Bigtable offre Change Data Capture (CDC) con la sua funzionalità per i flussi di modifiche. Un flusso di modifiche acquisisce le modifiche ai dati di una tabella Bigtable nel momento in cui vengono apportate, consentendoti di trasmetterle in flussi per l'elaborazione o l'analisi.

Questo documento fornisce una panoramica delle modifiche in tempo reale di Bigtable. Prima di leggere questo documento, dovresti acquisire familiarità con la panoramica di Bigtable.

Le modifiche in tempo reale sono molto utili per i casi d'uso della CDC, tra cui:

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

Che cos'è un flusso di modifiche

Una modifica in tempo reale monitora le 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 alla garbage collection.

Tutte le modifiche applicate a una tabella abilitata per le modifiche in tempo reale vengono archiviate come record di modifiche dei dati. I record delle modifiche ai dati includono le modifiche ai dati applicate da:

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

Per maggiori dettagli sui tipi di modifiche che puoi inviare a una tabella Bigtable, vedi Letture, Write, eliminazioni e Panoramica della raccolta dei rifiuti.

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

I record delle modifiche dei dati per ogni chiave di riga e ogni cluster sono nell'ordine del timestamp di commit. Tuttavia, non esiste alcuna garanzia di ordinamento per i record di modifica dei dati per una chiave di riga o un cluster diversi.

Puoi abilitare i modifiche in tempo reale su una tabella e specificare un periodo di conservazione da 1 a 7 giorni.

Contenuto di un record di modifica dei dati

Ogni record di modifica dei dati contiene tutte le modifiche per una riga che sono state applicate a livello atomico come parte di una singola chiamata RPC.

Se un valore viene sovrascritto, quello appena scritto viene registrato nel record delle modifiche dei dati. Il record di modifica dei dati non contiene il valore precedente.

Un record di modifica dei dati riceve il proprio timestamp, chiamato timestamp di commit, nello stesso momento in cui la modifica viene applicata al primo cluster che la riceve. Ad esempio, considera un'istanza con due cluster. Se invii una richiesta di scrittura alla Tabella 1 sul 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 delle modifiche ai dati contiene quanto segue:

Voci: modifiche apportate alla riga, incluse una o più delle seguenti opzioni:
- Scrittura
  - Famiglia di colonne
  - Qualificatore colonna
  - Timestamp
  - Valore
- Eliminazione di celle
  - Famiglia di colonne
  - Qualificatore colonna
  - Intervallo 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 del commit: ora lato server in cui è stato eseguito il commit della modifica nella tabella
Tie breaker: un valore che consente all'applicazione che legge il flusso di utilizzare il criterio di risoluzione dei conflitti integrato di Bigtable
Token - utilizzato dall'applicazione consumer per riprendere il flusso se viene interrotto
Filigrana bassa stimata: il tempo stimato trascorso dal raggiungimento della partizione del record con la replica in tutti i cluster. Per maggiori dettagli, consulta Partizioni e Filigrane.

Per saperne di più sui campi in un record di modifica dei dati, consulta la documentazione di riferimento API per DataChange.

Archiviazione di modifiche in tempo reale

Una tabella e il relativo flusso di modifiche condividono le stesse risorse a livello di cluster, inclusi nodi e archiviazione. Di conseguenza, l'archiviazione dei dati in tempo reale delle modifiche fa parte dell'archiviazione di una tabella. In un'istanza che utilizza la replica, una copia dei dati di un flusso di modifiche viene archiviata in ogni cluster dell'istanza che contiene la tabella abilitata per il flusso di modifiche.

Lo spazio di archiviazione utilizzato per i dati delle modifiche in tempo reale non viene conteggiato ai fini del calcolo 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 delle modifiche in tempo reale (anche se potrebbe essere necessario aggiungere nodi per aumentare la potenza di calcolo). Tuttavia, ti viene addebitato lo spazio di archiviazione utilizzato dai dati delle modifiche in tempo reale. Per maggiori dettagli, consulta Considerazioni sui costi.

Lettura di una modifica in tempo reale

Per leggere (trasmettere) un flusso di modifiche, devi utilizzare un profilo di applicazione configurato per il routing a cluster singolo e, se esegui il flusso di dati utilizzando Dataflow, devi abilitare le transazioni su riga singola.

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

Per saperne di più sulle transazioni su riga singola, consulta Transazioni su riga singola.

I metodi di modifica in tempo reale sono forniti dall'API Cloud Bigtable (API di dati). 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 consentono di evitare di dover monitorare e gestire le modifiche alla partizione dovute a divisioni e unioni.

Per maggiori informazioni, consulta ReadChangeStream.

Modelli Dataflow

Puoi utilizzare uno dei seguenti modelli di Dataflow forniti da Google:

Connettore Bigtable Beam

Puoi utilizzare il connettore Bigtable Beam per creare una pipeline:

Connettore Bigtable Beam

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

Libreria client Java

Client Cloud Bigtable per Java

Partizioni

Per mantenere una velocità effettiva di lettura elevata corrispondente a un'elevata velocità di scrittura o modifica, Bigtable suddivide un flusso di modifiche in più partizioni che possono essere utilizzate per leggere il flusso di modifiche in parallelo. Ogni partizione di modifiche in tempo reale è associata a un tablet. I tablet sono sottosezioni di una tabella che vengono ridistribuite in base alle esigenze per bilanciare il carico di lavoro delle richieste della tabella. Per scoprire di più, consulta Bilanciamento del carico.

La libreria client Java consente di eseguire query su ogni partizione per verificare se sono state apportate modifiche e fornisce le informazioni necessarie per gestire le modifiche nelle partizioni dovute a divisioni e unioni.

Filigrane

Una filigrana è un timestamp che stima quanto recentemente una partizione ha raggiunto la replica in tutti i cluster. La filigrana della partizione viene aggiornata continuamente man mano che viene eseguita la replica, avanzando nel tempo.

Ogni ChangeStreamMutation (record di modifica dei dati) include un campo estimatedLowWatermark, che rappresenta la filigrana della partizione associata al record delle modifiche dei dati. Questo valore estimatedLowWatermark è una stima e non garantisce che non siano ancora presenti dati nello stream.

Filigrane per le tabelle replicate

Il valore estimatedLowWatermark (filigrana bassa) di una partizione non avanza se la replica non viene raggiunta completamente per la partizione. La filigrana bassa a livello di flusso, la più bassa di tutte le filigrane basse stimate a livello di partizione, smette di avanzare se la filigrana di una partizione non procede. Una filigrana che ha smesso di avanzare è considerata in stallo. Quando ciò si verifica, se trasmetti il flusso di modifiche in una pipeline, la pipeline si blocca.

Esistono molti fattori che possono causare lo stallo di una o più filigrane a livello di partizione per un determinato periodo di tempo, tra cui:

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

Il connettore Bigtable Beam gestisce questa situazione impostando il timestamp di output su zero per tutti i dati. Per maggiori informazioni, consulta Raggruppamento dei dati senza orari degli eventi.

Monitoraggio

Per aiutarti a capire in che modo l'abilitazione di un flusso di modifiche influisce sull'utilizzo della CPU e dello spazio di archiviazione per un'istanza che contiene tabelle abilitate per le modifiche in tempo reale, forniamo due metriche specifiche per le modifiche in tempo reale. Puoi visualizzare le metriche nella pagina di monitoraggio di Bigtable o utilizzando la suite di strumenti di Cloud Monitoring.

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

Per maggiori dettagli su queste metriche, consulta Monitoring.

Considerazioni sui costi

L'abilitazione di un flusso di modifiche su una tabella comporta un aumento dei costi per nodi e archiviazione. In particolare, puoi aspettarti costi di archiviazione maggiori.

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 necessario per l'abilitazione e l'elaborazione dei record delle modifiche ai dati.

L'abilitazione 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 flusso di modifiche, come la lettura tramite una pipeline Dataflow, può aumentare l'utilizzo della CPU di circa il 20-30%, a seconda del livello di attività di modifica e di come vengono letti i dati del flusso.

Archiviazione

Ti vengono addebitate le tariffe di archiviazione di Bigtable standard per archiviare i record delle modifiche ai dati della tabella. Ti viene inoltre addebitato il costo di archiviazione della tabella creata per monitorare i metadati delle modifiche in tempo reale. Il periodo di conservazione specificato influisce direttamente sui costi di archiviazione.

Come regola generale, i record delle modifiche dei dati di un giorno, che riflettono solo le mutazioni che si sono verificate quel giorno, occupano circa una volta e mezza lo spazio di archiviazione che i dati scritti quel giorno consumano su disco.

Trasferimento dati di rete

Se leggi un flusso di modifiche in più regioni, puoi incorrere in costi per quel traffico. Consulta la sezione Rete relativa ai 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 delle modifiche 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 maggiori dettagli, consulta Prezzi di Dataflow.

Eliminazione degli intervalli di righe

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