Scritture

Questa pagina elenca i tipi di richieste di scrittura che puoi inviare a Bigtable e descrive quando e quando non è consigliabile. Per informazioni sull'aggregazione dei dati in una cella al momento della scrittura, consulta Aggregare i valori al momento della scrittura.

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

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

  • Scritture semplici
  • Incrementi e aggiunte
  • Scritture condizionali
  • Scritture batch

Le librerie client di Bigtable dispongono di tentativi intelligenti integrati per scritture semplici e in batch, il che significa che gestiscono senza problemi temporanea indisponibilità. Ad esempio, se la tua applicazione tenta di scrivere dati e riscontra un'interruzione temporanea o un problema di rete, nuovi tentativi finché non viene eseguito il commit della scrittura o fino al raggiungimento della scadenza della richiesta. Questa resilienza funziona sia con istanze a cluster singolo che con istanze replicate, con routing a cluster singolo o a cluster multipli.

Per le operazioni di scrittura in modalità flusso e batch, è possibile utilizzare Connettore Bigtable Beam. Per ulteriori informazioni, consulta Scritture in batch.

Per informazioni sui limiti che si applicano alle richieste di scrittura, consulta Quote e limiti.

Per esempi di richieste di scrittura della libreria client Cloud Bigtable descritte in questa pagina, consulta Esempi 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 di app, che indichi Bigtable come routing del traffico.
  • Una o più mutazioni. Una mutazione è costituita dai seguenti elementi:
    • Nome famiglia di colonne
    • Qualificatore colonna
    • Timestamp
    • Valore che stai scrivendo nella tabella

Il timestamp di una mutazione ha un valore predefinito pari alla data e all'ora correnti, misurato come tempo trascorso dall'epoca di Unix, 00:00:00 UTC il 1° gennaio 1970.

Un timestamp inviato a Bigtable deve essere un valore in microsecondi con al massimo in millisecondi, Un timestamp con precisione in microsecondi, come 3023483279876543 è stata rifiutata. In questo esempio, il valore accettabile per il timestamp è 3023483279876000.

Tutte le mutazioni in una singola richiesta di scrittura hanno lo stesso timestamp, a meno che non le sostituisci. Puoi imposta il timestamp di tutte le mutazioni in una richiesta di scrittura in modo che sia lo stesso o diversi 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 dell'app da utilizzare, una chiave di riga e fino a 100.000 mutazioni per quella riga. Una scrittura di una singola riga è atomica. Usa questo tipo di scrittura quando apporti più mutazioni a un riga singola.

Per esempi di codice che mostrano come inviare semplici richieste di scrittura, consulta Eseguire una scrittura semplice.

Quando non usare scritture semplici

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

  • Stai scrivendo un batch di dati che avrà chiavi di riga contigue. Nel in questo caso, dovresti usare scritture in batch invece di semplici scritture consecutive, perché è possibile applicare un batch contiguo in una singola chiamata di backend.

  • Ti serve una velocità effettiva elevata (righe al secondo o byte al secondo) e non hai bisogno di una bassa latenza. In questo caso, le scritture in batch saranno più veloci.

Incrementi e aggiunte

Quando vuoi aumentare o incrementare un valore, l'opzione migliore è utilizzare gli aggregati, che ti consentono di aggiornare un valore al momento della scrittura. I dati aggregati non supportano operazioni di aggiunta. Per ulteriori informazioni, consulta Aggregare i valori al momento della scrittura.

Se vuoi aggiungere dati a un valore esistente o devi incrementare un valore numerico esistente e non puoi utilizzare gli aggregati, puoi inviare una richiesta ReadModifyWriteRow. Questa richiesta include il nome della tabella, l'ID del profilo dell'app da utilizzare, una chiave di riga e un insieme di regole da utilizzare per scrivere i dati. Ogni regola include nome della famiglia di colonne, qualificatore di colonna e un valore di aggiunta o un importo di incremento.

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

Un valore può essere incrementato solo se è codificato come un segno big-endian a 64 bit numero intero. Bigtable tratta un incremento di un valore vuoto o non esistente come se il valore fosse zero. Le richieste ReadModifyWriteRow sono atomiche. Non vengono riprovati se non vanno a buon fine per qualsiasi motivo.

Per gli esempi di codice che dimostrano come aggiungere un valore in una cella, consulta Aumento di un valore esistente.

Quando non usare ReadModifyWriteRow

Non inviare richieste ReadModifyWriteRow nelle seguenti situazioni:

  • Il tuo caso d'uso può essere gestito con gli aggregate.

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

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

  • Ti affidi alla funzionalità di riprova intelligente fornita dalle librerie client. Non è possibile ripetere gli incrementi e gli aggiunte.

  • Stai scrivendo grandi quantità di dati e devi completare le scritture 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 contare qualcosa che si misura in milioni, come le visualizzazioni di pagina, devi utilizzare gli aggregati per aggiornare i conteggi al momento della scrittura. Puoi anche registrare ogni visualizzazione come una semplice scrittura anziché incrementare un valore e poi utilizzare un job Dataflow per aggregare i dati.

Scritture condizionali

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

Una richiesta di filtro deve includere uno o entrambi i seguenti tipi di mutazione:

  • Mutazioni vere o le mutazioni da applicare se il filtro restituisce un valore.
  • False mutazioni, che vengono applicate se il filtro non restituisce nulla.

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

Per gli esempi di codice che dimostrano 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 dell'app con routing su cluster multipli.

  • Stai utilizzando più profili di app a cluster singolo e stai inviando scritture che potrebbero essere in conflitto con i dati scritti nella stessa riga e colonna in altre cluster nell'istanza. Con il routing a cluster singolo, viene inviata una richiesta di scrittura in un unico cluster e poi replicato.

  • Stai scrivendo grandi quantità di dati e hai bisogno di completare le operazioni di scrittura rapidamente. Analogamente a ReadModifyWriteRow, le richieste di scrittura condizionale devono leggere le righe prima di modificarle, pertanto le richieste ReadModifyWriteRow sono più lente delle richieste di scrittura semplici. Di conseguenza, questo tipo di scrittura spesso non è l'approccio migliore su larga scala.

Scritture batch

Puoi scrivere più di una riga con una singola chiamata utilizzando un MutateRows richiesta. Le richieste MutateRows contengono un insieme di massimo 100.000 voci che sono ciascuna applicata a livello atomico. Ogni voce è composta da una chiave di riga e almeno una mutazione da applicare alla riga. Una richiesta di scrittura batch può contenere fino a 100.000 mutazioni distribuite tra tutte le voci. Ad esempio, una scrittura batch includi 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 di una richiesta MutateRows è atomica, ma la richiesta nel suo insieme non lo è. Se necessario, Bigtable riprova tutte le voci del batch che non vanno a buon fine finché non vengono completate tutte le scritture o non viene raggiunta la scadenza della richiesta. Quindi restituisce una risposta che identifica ogni scrittura nel batch se la scrittura è riuscita.

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

Quando non utilizzare le scritture in batch

  • Stai scrivendo dati collettivi in righe non vicine. Bigtable archivia i dati in ordine lessicografico in base alla chiave di riga, l'equivalente binario dell'ordine alfabetico. Per questo motivo, quando le chiavi di riga di una richiesta non sono simili tra loro, Bigtable le gestisce in sequenza, anziché in parallelo. La velocità effettiva sarà elevata, ma anche la latenza. Per evitare questa latenza elevata, usa MutateRows quando le chiavi di riga sono simili e Bigtable scriverà righe che uno vicino all'altro. Utilizza MutateRow o semplici scritture per le righe non vicine tra loro.

  • Stai richiedendo più mutazioni per la stessa riga. In questo caso, le prestazioni saranno migliori se esegui tutte le mutazioni in una singola richiesta di scrittura. Il motivo è che in una semplice scrittura, il commit di tutte le modifiche viene eseguito una singola azione atomica, ma una scrittura batch è costretta a serializzare le mutazioni stessa riga, causando latenza.

Controllo del flusso di scrittura batch

Se invii le scritture batch utilizzando uno dei seguenti metodi, puoi abilitare controllo del flusso di scrittura in batch nel codice.

Quando il controllo del flusso di scrittura batch è abilitato per un job Dataflow, Bigtable esegue automaticamente quanto segue :

  • Imposta un limite di velocità per il traffico per evitare di sovraccaricare il cluster Bigtable
  • Garantisce che il carico del cluster sia sufficiente per attivare la scalabilità automatica di Bigtable (se abilitata), in modo che altri nodi vengano aggiunti automaticamente al cluster in caso di necessità

Queste azioni combinate prevengono il sovraccarico del cluster e gli errori dei job, devi scalare manualmente il cluster prima dell'esecuzione della scrittura batch. Quando il controllo del flusso è abilitato, la scalabilità del cluster avviene durante il job Dataflow anziché prima, quindi il job potrebbe richiedere più tempo rispetto alla scalabilità manuale del cluster.

Devi utilizzare un profilo dell'app configurato per il routing a cluster singolo. Abilitazione in corso... La scalabilità automatica di Bigtable per il cluster di destinazione non è un requisito, ma la scalabilità automatica consente di sfruttare appieno il flusso di scrittura batch controllo. Puoi utilizzare la scalabilità automatica di Dataflow come faresti con qualsiasi altro job.

Per saperne di più sulla scalabilità automatica di Bigtable, consulta Scalabilità automatica. Per comprendere le norme di routing dei profili di app, consulta la Panoramica dei profili di app.

Per un esempio di codice che mostra come attivare il controllo del flusso di scrittura batch utilizzando il connettore Beam HBase Bigtable, consulta Scrittura in Bigtable.

Scrivere dati in una vista autorizzata

Per scrivere i dati in una vista autorizzata, devi utilizzare una delle seguenti opzioni:

  • Interfaccia a riga di comando gcloud
  • Client Bigtable per Java

Le altre librerie client Bigtable non supportano ancora l'accesso alle visualizzazioni autorizzate.

Quando scrivi dati in una vista autorizzata, fornisci la classe all'ID vista autorizzata oltre all'ID tabella.

Tutte le scritture in una vista autorizzata vengono applicate direttamente alla tabella di base.

Limitazioni della definizione delle visualizzazioni autorizzate

In una vista autorizzata, le righe o le colonne in cui puoi scrivere dati sono limitate dalla definizione delle viste autorizzate. In altre parole, puoi scrivere solo in righe e colonne che soddisfano gli stessi criteri specificati per la vista autorizzata.

Ad esempio, se la vista autorizzata è definita dal prefisso della chiave di riga examplepetstore1, non potrai scrivere dati utilizzando una chiave di riga di examplepetstore2; l'inizio del valore-chiave di riga deve includere l'intero stringa examplepetstore1.

Analogamente, se la vista autorizzata è definita dal prefisso del qualificatore di colonna order-phone, puoi scrivere i dati utilizzando il qualificatore di colonna order-phone123, ma non puoi utilizzare il qualificatore di colonna order-tablet.

Inoltre, la tua richiesta di scrittura non può fare riferimento a dati al di fuori del vista autorizzata, ad esempio quando verifichi un valore in una una richiesta di scrittura condizionale.

Per qualsiasi richiesta che scriva o faccia riferimento a dati al di fuori della visualizzazione autorizzata, viene restituito un messaggio di errore PERMISSION_DENIED.

Replica

Quando un cluster di un'istanza replicata riceve una scrittura, questa viene replicata immediatamente negli altri cluster dell'istanza.

Atomicità

Viene eseguito il commit di ogni richiesta MutateRows inviata a un'istanza replicata come singola azione atomica sul cluster a cui viene instradata la richiesta. Quando la scrittura viene replicata negli altri cluster dell'istanza, anch'essi ricevono la scrittura come un'operazione atomica. I cluster non ricevono una parte mutations; una mutazione ha esito positivo o negativo a livello atomico per tutte le cellule che modifica.

Coerenza

Il tempo necessario affinché i dati scritti siano disponibili per le letture dipende in base a diversi fattori, tra cui il numero di cluster nell'istanza e il tipo di routing utilizzato dal profilo dell'app.

Con un'istanza a cluster singolo, i dati possono essere letti immediatamente, ma se un'istanza ha più di un cluster, ovvero utilizza la replica, Bigtable è coerente in modo asintotico. Puoi ottenere la coerenza read-your-writes instradando le richieste allo stesso cluster.

Puoi creare e utilizzare un token di coerenza e chiamare CheckConsistency in modalità StandardReadRemoteWrites dopo aver inviato 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 certo intervallo, come di un'ora. Poi puoi passare il token affinché venga utilizzato da un altro processo, ad esempio come modulo che effettua una richiesta di lettura, che utilizza il token per verificare tutti i dati sono stati replicati prima del tentativo di lettura.

Se utilizzi un token subito dopo averlo creato, potrebbero essere necessari alcuni minuti verifica la coerenza al primo utilizzo. Questo ritardo è dovuto al fatto che ogni il cluster controlla ogni altro cluster per assicurarsi che non siano in arrivo altri dati. Dopo l'utilizzo iniziale o se aspetti diversi minuti per utilizzare il token per la prima volta, il token riesce immediatamente ogni volta che viene utilizzato.

Risoluzione dei conflitti

Ogni valore di cella in una tabella Bigtable è identificato in modo univoco dalla quadrupla (chiave 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 scrivano con il gli stessi quattro tuple vengono inviati a due cluster diversi, Bigtable il conflitto viene risolto utilizzando un algoritmo interno last write wins basato sul server nel tempo. L'implementazione di Bigtable "l'ultima scrittura è quella valida" è deterministica e, quando la replica si aggiorna, tutti i cluster hanno lo stesso valore per la quadrupla.

Passaggi successivi