Scritture

Panoramica

Questa pagina elenca i tipi di richieste di scrittura che puoi inviare a Cloud Bigtable e descrive quando utilizzarli e quando non utilizzarli.

L'API Cloud Bigtable Data e le librerie client ti consentono di scrivere i dati in modo programmatico nelle tue tabelle. Bigtable invia una risposta o una conferma per ogni scrittura.

Ogni libreria client offre la possibilità di inviare i seguenti tipi di richieste di scrittura:

Scritture semplici
Incrementi e aggiunte
Scrittura condizionale
Scritture in batch

Le librerie client di Bigtable hanno una funzionalità integrata di nuovi tentativi per la scrittura semplice e batch, il che significa che possono gestire senza problemi l'indisponibilità temporanea. Ad esempio, se la tua applicazione tenta di scrivere dati e riscontra un'interruzione temporanea o un problema di rete, riprova automaticamente fino al commit della scrittura o al raggiungimento della scadenza della richiesta. Questa resilienza funziona con le istanze sia a cluster singolo che multi-cluster, con routing a cluster singolo o routing a cluster multipli.

Per le operazioni di scrittura in modalità flusso e batch, puoi utilizzare il connettore Dataflow per Bigtable. Per saperne di più sui limiti che si applicano alle richieste di scrittura, consulta Quote e limiti.

Per ogni libreria client di Bigtable sono disponibili esempi di ciascun tipo di scrittura.

Tipi di scrittura e quando utilizzarli

Tutte le richieste di scrittura includono i seguenti componenti di base:

Il nome della tabella in cui scrivere.
Un ID profilo app, che indica a Bigtable come instradare il traffico.
Una o più mutazioni. Una mutazione è composta da quattro elementi:
- Nome famiglia di colonne
- Qualificatore colonna
- Timestamp
- Valore che stai scrivendo nella tabella

Il timestamp di una mutazione ha un valore predefinito della data e dell'ora correnti. Tutte le mutazioni in una singola richiesta di scrittura hanno lo stesso timestamp, a meno che tu non le sostituisca. Puoi impostare il timestamp di tutte le mutazioni in una richiesta di scrittura in modo che siano uguali o diverse tra loro.

Scritture semplici

Puoi scrivere una singola riga in Bigtable con una richiesta MutateRow che include il nome della tabella, l'ID del profilo di app da utilizzare, una chiave di riga e fino a 100.000 mutazioni per quella riga. La scrittura a riga singola è atomica. Utilizza questo tipo di scrittura quando apporti più mutazioni in una singola riga.

Per esempi di codice che dimostrano come inviare richieste di scrittura semplici, consulta Esecuzione di una scrittura semplice.

Quando non utilizzare scritture semplici

Le scritture semplici non sono il modo migliore per scrivere dati per i seguenti casi d'uso:

Stai scrivendo un gruppo di dati con chiavi di riga contigue. In questo caso, dovresti utilizzare le scritture batch anziché le operazioni di scrittura semplici consecutive, perché un batch contiguo può essere applicato in una singola chiamata di backend.
Vuoi una velocità effettiva elevata (righe al secondo o byte al secondo) e non richiedi una bassa latenza. In questo caso, le scritture batch saranno più veloci.

Incrementi e aggiunte

Se vuoi aggiungere dati a un valore esistente o incrementare un valore numerico esistente, invia una richiesta ReadModifyWriteRow. Questa richiesta include il nome della tabella, l'ID del profilo app da utilizzare, una chiave di riga e un insieme di regole da utilizzare per la scrittura dei dati. Ogni regola include il nome della famiglia di colonne, il qualificatore di colonna e un valore di aggiunta o un importo incrementale.

Le regole vengono applicate in ordine. Ad esempio, se la tua richiesta include una richiesta di incremento di due volte del valore di una colonna e una regola successiva nella stessa richiesta aumenta di 1 la stessa colonna, la colonna viene incrementata di 3 in questa singola scrittura atomica. La regola successiva non sovrascrive la regola precedente.

Un valore può essere incrementato solo se è codificato come numero intero con firma big-endian a 64 bit. Bigtable considera un incremento per un valore vuoto o non esistente come se il valore fosse zero. Le richieste ReadModifyWriteRow sono atomiche. Non vengono ritentati se falliscono per qualsiasi motivo.

Per esempi di codice che dimostrano come aggiungere un valore in una cella, consulta la sezione Incrementare un valore esistente.

Quando non utilizzare incrementi e aggiunte

Non inviare richieste ReadModifyWriteRow nelle seguenti situazioni:

Stai utilizzando un profilo di app con routing multi-cluster.
Stai utilizzando più profili app per cluster singoli e invii scritture che potrebbero essere in conflitto con i dati scritti nella stessa riga e colonna in altri cluster nell'istanza. Con il routing a cluster singolo, una richiesta di scrittura viene inviata a un singolo cluster e quindi replicata.
Ti affidi alla funzionalità dei nuovi tentativi intelligenti fornita dalle librerie client. Non è possibile incrementare gli incrementi e le appendici.
Stai scrivendo grandi quantità di dati e hai bisogno che le scritture vengano completate rapidamente. Una richiesta che legge e poi modifica una riga è più lenta di una semplice richiesta di scrittura. Di conseguenza, questo tipo di scrittura non è spesso l'approccio migliore su larga scala. Ad esempio, se vuoi conteggiare qualcosa che conta i milioni di visualizzazioni, come le visualizzazioni di pagina, dovresti registrare ogni visualizzazione come una scrittura semplice anziché incrementare un valore. Quindi puoi utilizzare un job Dataflow per aggregare i dati.

Scrittura condizionale

Se vuoi controllare una riga per una condizione e, a seconda del risultato, scrivi dati in quella riga, invia una richiesta CheckAndMutateRow. Questo tipo di richiesta include una chiave di riga e un filtro di riga. Un filtro riga è un insieme di regole che puoi utilizzare per verificare il valore dei dati esistenti. Le modifiche vengono quindi impegnate in colonne specifiche nella riga solo quando vengono soddisfatte determinate condizioni, controllate dal filtro. Il processo di verifica e scrittura viene completato come una singola azione atomica.

Una richiesta di filtro deve includere uno o entrambi i due tipi di mutazioni:

Vere mutazioni o le mutazioni da applicare se il filtro restituisce un valore.
False mutazioni, che vengono applicate se il filtro non produce alcun risultato.

Puoi fornire fino a 100.000 per ciascun tipo di mutazione (vero e falso) in una sola scrittura e devi inviarne almeno una. Bigtable invia una risposta quando tutte le mutazioni sono complete.

Per esempi di codice che dimostrano come inviare scritture condizionali, consulta la sezione Scrivere un valore in modo condizionale.

Quando non utilizzare le scritture condizionali

Non puoi utilizzare le scritture condizionali per il seguente caso d'uso:

Stai utilizzando un profilo di app con routing multi-cluster.
Stai utilizzando più profili app per cluster singoli e invii scritture che potrebbero essere in conflitto con i dati scritti nella stessa riga e colonna in altri cluster nell'istanza. Con il routing a cluster singolo, una richiesta di scrittura viene inviata a un singolo cluster e quindi replicata.

Scritture in batch

Puoi scrivere più di una riga con una singola chiamata utilizzando una richiesta MutateRows. Le richieste MutateRows contengono un insieme di massimo 100.000 voci applicate singolarmente. Ogni voce è composta da una chiave di riga e da almeno una modifica da applicare alla riga. Una richiesta di scrittura in batch può contenere fino a 100.000 mutazioni distribuite tra tutte le voci. Ad esempio, una scrittura batch potrebbe includere una delle seguenti permutazioni:

100.000 voci con 1 mutazione in ciascuna voce.
1 voce con 100.000 mutazioni.
1.000 voci con 100 mutazioni ciascuna.

Ogni voce in una richiesta MutateRows è atomica, ma la richiesta nel suo complesso non lo è. Se necessario, Bigtable tenta di recuperare le voci del batch che non hanno esito positivo, finché non tutte le operazioni di scrittura vengono completate o viene raggiunta la scadenza della richiesta. Dopodiché restituisce una risposta che identifica ogni scrittura nel batch e indica se l'operazione è riuscita o meno.

Per esempi di codice che dimostrano come inviare scritture batch, consulta Esecuzione di scritture batch.

Quando non utilizzare le scritture batch

Stai scrivendo dati collettivi su righe vicine tra loro. Bigtable archivia i dati lexicograficamente per chiave di riga, l'equivalente binario dell'ordine alfabetico. Per questo motivo, quando le chiavi di riga in una richiesta non sono simili tra loro, Bigtable le gestisce in sequenza, anziché in parallelo. La velocità effettiva sarà elevata, ma anche la latenza sarà elevata. Per evitare un'elevata latenza, utilizza MutateRows quando le chiavi di riga sono simili e Bigtable scriverà righe vicine tra loro. Utilizza MutateRow, o scritture semplici, per le righe non vicine tra loro.
Stai richiedendo più mutazioni alla stessa riga. In questo caso, noterai prestazioni migliori se esegui tutte le mutazioni in una singola richiesta di scrittura. Questo perché, in una semplice scrittura, tutte le modifiche vengono impegnate in una singola azione atomica, ma una scrittura batch è costretta a serializzare le mutazioni sulla stessa riga, causando latenza.

Coerenza quando si utilizza la replica

Il tempo necessario per rendere disponibili i dati che scrivi dipende da diversi fattori, tra cui il numero di cluster nell'istanza e il tipo di routing utilizzato dal profilo della tua app. Con un'istanza a cluster singolo, i dati possono essere letti immediatamente, ma se un'istanza ha più di un cluster, il che significa che utilizza la replica, Bigtable è alla fine coerente. Puoi ottenere la coerenza di lettura/scrittura indirizzando le richieste allo stesso cluster.

Puoi creare e utilizzare un token di coerenza dopo aver inviato le richieste di scrittura. Il token verifica la coerenza della replica. In generale, crei un token di coerenza dopo l'invio di un batch di scritture o dopo un determinato intervallo, ad esempio un'ora. Quindi puoi passare il token per essere utilizzato da un altro processo, ad esempio un modulo che effettua una richiesta di lettura, che utilizza il token per verificare che tutti i dati siano stati replicati prima di tentare di leggerlo.

Se utilizzi un token subito dopo averlo creato, potrebbero essere necessari alcuni minuti per verificare la coerenza al primo utilizzo. Questo ritardo è dovuto al fatto che ogni cluster controlla ogni altro cluster per assicurarsi che non vengano ricevuti altri dati. Dopo l'utilizzo iniziale o se attendi qualche minuto per l'utilizzo del token per la prima volta, il token ha esito positivo ogni volta che viene utilizzato.

Risoluzione dei conflitti

Ogni valore di cella in una tabella Bigtable è identificato in modo univoco da quattro tuple (chiave di riga, famiglia di colonne, qualificatore di colonna, timestamp). Per ulteriori dettagli su questi identificatori, consulta Modello di archiviazione Bigtable. Nel raro caso in cui due scritture con esattamente la stessa tupla a quattro tuple vengano inviate a due cluster diversi, Bigtable risolve automaticamente il conflitto utilizzando un algoritmo interno ultimo scrittura basato sul tempo lato server. L'implementazione di Bigtable "l'ultima scrittura vince" è deterministica e, quando la replica recupera, tutti i cluster hanno lo stesso valore per la tupla a quattro tuple.