Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica delle modifiche in tempo reale

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 stream di modifiche di Bigtable. Prima di leggere questo documento, devi 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 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 alla 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 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 un per la tabella Bigtable, consulta Letture, Scritture, eliminazioni, e Panoramica della raccolta dei rifiuti.

Le modifiche in tempo reale non tengono traccia delle modifiche allo schema, come l'aggiunta o la modifica di un di famiglia di colonne o topologia di replica, come 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 ordinazione per i record delle modifiche dei dati per un chiave di riga o un cluster diverso.

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 ai 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 delle modifiche dei dati non contiene il valore precedente.

Un record di modifica dei dati riceve il proprio timestamp, chiamato timestamp del commit, contemporaneamente all'applicazione della modifica al primo cluster che lo riceve. Per consideriamo un'istanza con due cluster. Se invii una richiesta di scrittura a Tabella 1 sul cluster A, il timestamp di commit del record di modifiche dei dati viene assegnato quando la scrittura viene ricevuta dal Cluster A e il record delle modifiche dei dati sul Cluster B questa scrittura ha lo stesso timestamp di commit.

Ciascun 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 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 da famiglie di colonne per ogni famiglia di colonne che che 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 tavola
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 che utilizza i dati per riprendere il flusso, se è 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 delle modifiche dei dati, consulta l'API riferimento per DataChange

Archiviazione delle modifiche in tempo reale

Una tabella e il rispettivo flusso di modifiche condividono le stesse risorse a livello di cluster, nodi e spazio di archiviazione. Di conseguenza, l'archiviazione dei dati delle modifiche in tempo reale fa parte archiviazione. In un'istanza che utilizza la replica, una copia dei dati di un stream di modifiche viene archiviata in ogni cluster dell'istanza che contiene 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 di modifica (anche se potrebbe essere necessario aggiungere nodi per una maggiore potenza di calcolo). Tuttavia, ti viene addebitato il costo dell'archiviazione utilizzata dai dati del tuo stream di modifiche. Per maggiori dettagli, vedi Considerazioni sui costi.

Lettura di un flusso di modifiche

Per leggere (in streaming) un stream delle modifiche, devi utilizzare un profilo dell'applicazione configurato per il routing a cluster singolo e, se utilizzi lo streaming con Dataflow, devi attivare le transazioni a 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 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 una velocità effettiva di lettura elevata che corrisponda a una velocità di scrittura o modifica elevata, Bigtable divide un flusso di modifiche in più partizioni che per leggere il flusso di modifiche in parallelo. Ogni partizione di modifiche in tempo reale Se è associato a un tablet. I tablet sono sottosezioni di una tabella vengono ridistribuiti in base alle esigenze per 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 verificare le modifiche e fornisce le informazioni necessarie per gestire le modifiche nelle partizioni a divisioni 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 estimatedLowWatermark è un e non garantisce che non siano ancora disponibili dati durante lo streaming.

Filigrane per le tabelle replicate

Il valore estimatedLowWatermark (filigrane bassa) di una partizione non avanza se la replica non è completamente aggiornata per la partizione. Il basso a livello di stream filigrana: la più bassa di tutte le filigrane basse stimate a livello di partizione : interrompe l'avanzamento se la filigrana della partizione non va avanti. R la filigrana che ha interrotto l'avanzamento è considerata in stallo. Quando questo se invii in modalità flusso il flusso di modifiche in una pipeline, la pipeline le bancarelle.

Molti fattori possono causare il blocco di una o più filigrane a livello di partizione in alcuni casi molto tempo, inclusi i seguenti dati:

Sovraccarico di un cluster con traffico che causa la mancata interruzione della replica in ritardo 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 ulteriori informazioni, vedi Raggruppare i dati senza orari degli eventi.

Monitoraggio

Per aiutarti a capire in che modo l'attivazione di un flusso di modifiche influisce sull'utilizzo della CPU e dello spazio di archiviazione per un'istanza contenente tabelle con flusso di modifiche abilitato, forniamo due metriche specifiche per i flussi 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 stream di modifiche (utilizza cpu_load_by_app_profile_by_method_by_table)

Per informazioni dettagliate su queste metriche, consulta Monitoraggio.

Considerazioni sui costi

L'abilitazione di un flusso di modifiche in una tabella comporta un aumento dei costi per nodi archiviazione. In particolare, sono prevedibili più spazio di archiviazione aggiuntivi.

Nodi

In genere devi aggiungere nodi a un cluster (o aumentare il numero massimo nodi se utilizzi la scalabilità automatica) per gestire il traffico aggiuntivo durante l'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. Elaborazione di un flusso di modifiche, ad esempio la lettura utilizzando una pipeline Dataflow, può aumentare l'utilizzo della CPU di circa dal 20% al 30%, a seconda del livello di attività di modifica e del modo in cui i dati del flusso viene letto.

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 dei dati di rete

Se leggi uno stream di modifiche in più regioni, potresti dover sostenere costi per questo traffico. Consulta la sezione Rete Prezzi di Bigtable per un elenco completo delle velocità di trasferimento dei 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 maggiori dettagli, consulta Prezzi di Dataflow.

Inserire intervalli di righe

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