Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica delle modifiche in tempo reale

Bigtable offre Change Data Capture (CDC) con i suoi flussi di modifiche funzionalità. Una modifica in tempo reale acquisisce le modifiche ai dati in una tabella Bigtable man mano che vengono apportate le modifiche, permettendoti di trasmetterle in modalità flusso per l'elaborazione o analisi.

Questo documento fornisce una panoramica delle modifiche in tempo reale di Bigtable. Prima di leggere questo documento, dovresti conoscere gli 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 utilizzando in genere 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 modifica di dati record. 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 delle modifiche dei dati per ogni chiave di riga e ogni cluster sono nel timestamp di commit ordine. 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 dei dati

Ogni record delle modifiche ai dati contiene tutte le modifiche per una riga applicate a livello atomico come parte di una singola chiamata RPC.

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

Un record delle modifiche ai dati riceve il proprio timestamp, chiamato timestamp di commit, al nello stesso momento in cui la modifica viene applicata al primo cluster che la 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: 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 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 il flusso usano la risoluzione dei conflitti integrata di Bigtable norme
Token - Utilizzato dall'applicazione che utilizza i dati per riprendere il flusso, se è interrotto
Watermark basso stimato: il tempo stimato dalla partizione del record ha raggiunto la replica in tutti i cluster. Per maggiori dettagli, vedi Partizioni e Filigrane.

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 flusso di modifiche viene archiviato in ogni cluster dell'istanza che contiene la modifica abilitata per il flusso di dati.

Lo spazio di archiviazione utilizzato per i dati delle modifiche in tempo reale non viene conteggiato nel calcolo del totale utilizzo dello spazio di archiviazione (% max). Di conseguenza, non devi aggiungere nodi per gestire lo spazio di archiviazione aggiuntivo consumato dai dati in modalità flusso (anche se potresti dover per aggiungere nodi per aumentare la potenza di calcolo). Tuttavia, ti vengono addebitati i costi lo spazio di archiviazione utilizzato dai dati delle modifiche in tempo reale. Per maggiori dettagli, vedi Considerazioni sui costi.

Lettura di un flusso di modifiche

Per leggere (un flusso di modifiche) un flusso di modifiche, devi utilizzare un profilo di applicazione configurato per il routing a cluster singolo e, se utilizzi Dataflow per il flusso di dati, 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 ulteriori 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 da il tutorial o la guida rapida di Bigtable come punto di partenza per 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 ulteriori informazioni vedi altro Bilanciamento del carico.

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

Filigrane

Una filigrana è un timestamp che stima da quanto tempo una partizione è stata rilevata con la replica in tutti i cluster. Il watermark per la partizione è che viene continuamente aggiornato man mano che si verifica la replica, avanzando in avanti nel tempo.

Ogni ChangeStreamMutation (record delle modifiche dei dati) include un parametro estimatedLowWatermark, che corrisponde alla filigrana per la partizione associate al record delle modifiche 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 quando trasmetti in modalità flusso il flusso di modifiche in una 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 Raggruppamento dei dati senza orari degli eventi.

Monitoraggio

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

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 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 viene addebitato l'importo Tariffe di archiviazione Bigtable per archiviare i record delle modifiche ai dati della tabella. Ti viene inoltre addebitato un costo per archiviare creata per monitorare i metadati delle modifiche in tempo reale. Il periodo di conservazione che specifichi incide direttamente sui costi di archiviazione.

Come regola generale, un giorno di dati registra le modifiche, che riflettono solo mutazioni avvenute quel giorno: occupa circa 1,5 volte lo spazio di archiviazione rispetto a i dati scritti quel giorno consumano su disco.

Trasferimento dei dati di rete

Se leggi un flusso di modifiche tra regioni, ti possono essere addebitati dei costi per via del traffico. Consulta la sezione Rete Prezzi di Bigtable per un elenco completo delle velocità di trasferimento dei dati di rete.

Costi di elaborazione

In base alla modalità di lettura dei record delle modifiche ai dati, costi aggiuntivi per si applicano anche servizi diversi da Bigtable. Ad esempio, se utilizzi Dataflow, paghi per i byte elaborati e per il che elaborano il job. Per maggiori dettagli, vedi Prezzi di Dataflow.

Eliminazione degli 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, che Bigtable potrebbe impiegare molto tempo per completare e l'utilizzo della CPU aumenta durante l'operazione.