Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Scritture

Panoramica

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

L'API Cloud Bigtable Data e le librerie client ti consentono di scrivere i dati nelle tue tabelle in modo programmatico. 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
  • Scritture condizionali
  • Scritture batch

Le librerie client di Bigtable dispongono di una funzionalità integrata di tentativi intelligenti per le scritture semplici e batch, il che significa che possono gestire senza problemi i problemi di indisponibilità temporanea. Ad esempio, se la tua applicazione tenta di scrivere dati e rileva un'interruzione temporanea o un problema di rete, tenta automaticamente di nuovo fino al commit della scrittura o al raggiungimento della scadenza della richiesta. Questa resilienza funziona con istanze a cluster singolo e 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 informazioni sui limiti che si applicano alle richieste di scrittura, consulta Quote e limiti.

Esempi di ogni tipo di scrittura sono disponibili per ciascuna libreria client di Bigtable.

Tipi di operazioni di scrittura e quando utilizzarle

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 come la data e l'ora correnti. Tutte le mutazioni in una singola richiesta di scrittura hanno lo stesso timestamp, a meno che non vengano sostituite. Puoi impostare il timestamp di tutte le mutazioni in una richiesta di scrittura in modo che siano uguali o diversi l'una dall'altra.

Scritture semplici

Puoi scrivere una singola riga in Bigtable con una richiesta MutateRow che include il nome della tabella, l'ID del profilo 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 mostrano come inviare richieste di scrittura semplici, consulta Eseguire 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 che avrà chiavi di riga contigue. In questo caso, dovresti utilizzare le scritture batch anziché le scritture semplici consecutive, perché è possibile applicare un batch contiguo in una singola chiamata di backend.

  • Vuoi una velocità effettiva elevata (righe al secondo o byte al secondo) e non richiedere una bassa latenza. In questo caso, le operazioni di scrittura in batch saranno più rapide.

Incrementi e aggiunte

Se vuoi aggiungere dati a un valore esistente o aumentare 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 durante 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 richiesta include una richiesta di incremento di due valori per una colonna e una regola successiva nella stessa richiesta viene incrementata di 1, 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 intero con end-end a 64 bit. Bigtable tratta un incremento di un valore che è vuoto o non esiste come se il valore fosse zero. Le richieste ReadModifyWriteRow sono atomiche. Non vengono tentati di nuovo se non vengono riusciti per qualsiasi motivo.

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

Quando non utilizzare gli incrementi e le aggiunte

Non devi inviare richieste ReadModifyWriteRow nelle seguenti situazioni:

  • Stai utilizzando un profilo di app con routing multi-cluster.

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

  • Tu utilizzi la funzionalità di nuovo tentativo fornita dalle librerie client. Incrementamenti e aggiunte non possono essere recuperati.

  • 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 spesso non è l'approccio migliore su larga scala. Ad esempio, se vuoi conteggiare qualcosa che conta nei milioni, come le visualizzazioni di pagina, ti consigliamo di registrare ogni visualizzazione come una scrittura semplice anziché aumentare un valore. Quindi puoi utilizzare un job Dataflow per aggregare i dati.

Scritture condizionali

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

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

  • Vere mutazioni o modifiche da applicare se il filtro restituisce un valore.
  • Falsi mutazioni, che vengono applicate se il filtro non restituisce risultati.

Puoi fornire fino a 100.000 di ciascun tipo di mutazione,true o false, in una sola scrittura e devi inviarne almeno una. Bigtable invia una risposta quando tutte le mutazioni sono state completate.

Per esempi di codice che mostrano come inviare scritture condizionali, consulta 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 di app a cluster singolo e invii scritture che potrebbero essere in conflitto con i dati scritti nella stessa riga e colonna in altri cluster dell'istanza. Con il routing a cluster singolo, una richiesta di scrittura viene inviata a un singolo cluster e quindi replicata.

Scritture batch

Puoi scrivere più di una riga con una singola chiamata utilizzando una richiesta MutateRows. Le richieste MutateRows contengono un insieme di fino a 100.000 voci applicate ciascuna a livello atomico. 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 in tutte le voci. Ad esempio, una scrittura in batch potrebbe includere una qualsiasi delle seguenti permutazioni:

  • 100.000 voci con 1 mutazione in ciascuna voce.
  • 1 voce con 100.000 mutazioni.
  • 1000 voci con 100 mutazioni ciascuna.

Ogni voce in una richiesta MutateRows è atomica, ma non lo è la richiesta nel suo complesso. Bigtable invia una risposta dopo la scrittura di tutte le voci.

Per gli esempi di codice che mostrano come inviare scritture batch, consulta Esecuzione di operazioni di scrittura batch.

Quando non utilizzare le scritture batch

  • Stai scrivendo dati collettivi per righe non vicine. Bigtable memorizza i dati in modo letterale 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à alta. Per evitare questa elevata latenza, usa 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 nella stessa riga. In questo caso, potrai ottenere prestazioni migliori se esegui tutte le mutazioni in una singola richiesta di scrittura semplice. Questo perché in una semplice scrittura tutte le modifiche vengono eseguite in una singola azione atomica, ma la scrittura in batch viene forzata a serializzare le mutazioni nella stessa riga, causando latenza.

Coerenza quando viene usata la replica

Il tempo necessario per rendere disponibili i dati da scrivere dipende da diversi fattori, tra cui il numero di cluster nella tua 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 è a coerenza finale. Puoi ottenere la coerenza delle operazioni 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 controlla 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 trasferire il token in modo che venga utilizzato da un altro processo, ad esempio un modulo che effettua una richiesta di lettura, che lo utilizza per verificare che tutti i dati siano stati replicati prima di tentare di leggere.

Se utilizzi un token subito dopo la sua creazione, possono 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 diversi minuti per l'utilizzo del token, l'operazione andrà a buon fine ogni volta che verrà 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 evento in cui due scritture con la stessa identica quattro tuple vengano inviate a due cluster diversi, Bigtable risolve automaticamente il conflitto utilizzando un algoritmo interno ultimo scrittura basato sul tempo lato server. Bigtable "vince l'ultima scrittura" (l'implementazione è deterministica e, quando la replica arriva al massimo, tutti i cluster hanno lo stesso valore per la quattro tuple.

Passaggi successivi