Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica delle modifiche in tempo reale

Bigtable offre Change Data Capture (CDC) con la sua funzionalità Change Data Capture. Una modifica in tempo reale acquisisce le modifiche ai dati in una tabella Bigtable nel momento in cui si verificano le modifiche, 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 avere familiarità con la panoramica di Bigtable.

Le modifiche in tempo reale sono utili per i casi d'uso dei 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 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 delle modifiche dei dati. I record delle modifiche ai dati includono le modifiche ai dati applicate da quanto segue:

Scrive, eliminazioni e aggiornamenti inviati utilizzando i metodi dell'API Cloud Bigtable MutateRow, MutateRows, CheckAndMutateRow e ReadModifyWriteRow
Eliminazioni che avvengono 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, consulta Letture, Scritture, Eliminazioni e Panoramica della raccolta di rifiuti.

Le modifiche in tempo reale non monitorano le modifiche allo schema, come l'aggiunta o la modifica di una famiglia di colonne o una 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 in ordine di timestamp di commit. Tuttavia, non esiste una garanzia di ordinamento per i record delle modifiche dei dati per una chiave di riga o un cluster differente.

Puoi abilitare le modifiche in tempo reale in una tabella e specificare un periodo di conservazione compreso tra 1 e 7 giorni.

Contenuti di un record delle modifiche dei dati

Ogni record delle modifiche dei dati contiene tutte le modifiche per una riga che sono state applicate atomicamente come parte di una singola chiamata RPC.

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

Un record delle modifiche dei dati riceve il proprio timestamp, chiamato timestamp di commit, nello stesso momento in cui la modifica viene applicata al primo cluster che lo riceve. Considera ad esempio un'istanza con due cluster. Se invii una richiesta di scrittura alla tabella 1 sul cluster A, il timestamp di commit del record di modifiche dei dati viene assegnato quando il cluster A riceve la scrittura e il record delle modifiche dei dati sul cluster B per questa scrittura ha lo stesso timestamp di commit.

Ciascun record di modifica dei dati contiene quanto segue:

Voci: modifiche apportate alla riga, tra cui una o più delle seguenti informazioni:
- 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: l'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 integrato per la risoluzione dei conflitti di Bigtable
Token: utilizzato dall'applicazione che utilizza i dati per riprendere il flusso se viene interrotto
Watermark basso stimato: il tempo stimato dopo che la partizione del record ha raggiunto la replica in tutti i cluster. Per maggiori dettagli, vedi Partizioni e Filigrane.

Per ulteriori informazioni sui campi in un record delle modifiche dei dati, consulta il riferimento API per DataChange.

Archiviazione delle modifiche in tempo reale

Una tabella e il relativo flusso di modifiche condividono le stesse risorse a livello di cluster, inclusi nodi e spazio di archiviazione. Di conseguenza, l'archiviazione dei dati in modalità flusso di 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 le modifiche in tempo reale.

Lo spazio di archiviazione utilizzato per i dati delle modifiche in tempo reale non viene conteggiato ai fini dell'utilizzo dello spazio di archiviazione totale (% max). Di conseguenza, non è necessario aggiungere nodi per gestire l'aumento dello spazio di archiviazione utilizzato dai dati delle modifiche in tempo reale (anche se potrebbe essere necessario aggiungere nodi per aumentare la potenza di calcolo). Tuttavia, ti viene addebitato il costo dello spazio di archiviazione utilizzato dai dati delle modifiche in tempo reale. Per i dettagli, vedi Considerazioni sui costi.

Lettura di un flusso di modifiche

Per leggere (in modalità flusso) una modifica in tempo reale, devi utilizzare un profilo di applicazione configurato per il routing a cluster singolo e, se utilizzi Dataflow, devi abilitare le transazioni su riga singola.

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

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

I metodi delle modifiche 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 monitorare e gestire le modifiche alla partizione dovute a suddivisioni e unioni.

Per maggiori informazioni, vedi 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

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

Libreria client Java

Client Cloud Bigtable per Java

Partizioni

Per mantenere una velocità effettiva di lettura elevata corrispondente a un'elevata frequenza di scrittura o modifica, Bigtable divide 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 secondo le necessità per aiutare a 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 rilevare le 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 di recente 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 delle modifiche dei dati) include un campo estimatedLowWatermark, che è la filigrana per la partizione associata al record delle modifiche ai dati. Questo estimatedLowWatermark è una stima e non garantisce che non siano ancora disponibili dati nello stream.

Filigrane per le tabelle replicate

Il valore estimatedLowWatermark (filigrane bassa) di una partizione non avanza se la replica non è completamente coinvolta dalla 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 della partizione non va avanti. Una filigrana che non avanza più viene considerata in stallo. In questo caso, se trasmetti in modalità flusso il flusso di modifiche in una pipeline, la pipeline si blocca.

Sono molti i fattori che possono causare il blocco di una o più filigrane a livello di partizione per un certo periodo di tempo, tra cui:

Sovraccarico un cluster con traffico che fa sì che la replica resti indietro per una o più partizioni
Ritardi di rete
Mancata disponibilità del cluster

Il connettore Bigtable Beam gestisce questa operazione 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 di CPU e 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 sulla 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 CPU per modifiche in tempo reale ( utilizza cpu_load_by_app_profile_by_method_by_table)

Per maggiori dettagli su queste metriche, consulta Monitoraggio.

Considerazioni sui costi

L'abilitazione di un flusso di modifiche su una tabella comporta un aumento dei costi per nodi e archiviazione. In particolare, sono previsti 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 associato all'abilitazione e all'elaborazione dei record delle modifiche dei 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, ad esempio la lettura mediante 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 Bigtable standard per archiviare i record delle modifiche dei dati della tabella. Ti vengono inoltre addebitati i costi per l'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, un giorno di record delle modifiche dei dati, che riflettono solo le mutazioni che si sono verificate in quel giorno, occupano circa 1,5 volte più spazio di archiviazione rispetto al consumo su disco dei dati scritti quel giorno.

Trasferimento dei dati di rete

Se leggi un flusso di modifiche in più regioni, ti possono venire addebitati dei costi per quel traffico. Consulta la sezione Rete sui prezzi di Bigtable per un elenco completo delle tariffe di trasferimento di dati di rete.

Costi di elaborazione

A seconda della modalità di lettura dei record delle modifiche ai dati, si applicano costi aggiuntivi per i 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 i prezzi di Dataflow.

Eliminazione degli intervalli di righe

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