Opzioni di routing

Quando invii richieste da un'applicazione a Bigtable, utilizzi una profilo che indica a Bigtable per gestire le richieste. Un profilo dell'app specifica il criterio di routing per le richieste. Per le istanze che utilizzano la replica, il criterio di routing controlla quali cluster ricevono le richieste e come vengono gestiti i failover.

Questo documento descrive i criteri di routing disponibili per un profilo dell'app standard.

I criteri di routing sono particolarmente importanti per il carico di lavoro di isolamento, quando non puoi utilizzare Data Boost (anteprima). Puoi configurarle in in combinazione con le priorità delle richieste.

I criteri di routing non influiscono sulla replica, ma è necessario sapere come Bigtable replica funziona prima di leggere questa pagina. Dovresti leggere inoltre Failover.

Routing a un cluster singolo

Un criterio di routing a cluster singolo instrada tutte le richieste a un solo cluster in esecuzione in un'istanza Compute Engine. Se il cluster non è più disponibile, devi eseguire manualmente il failover su in un altro cluster.

Questo è l'unico criterio di routing che ti consente di attivare una riga singola transazioni.

Un'istanza replicata di solito fornisce coerenza. Tuttavia, puoi ottenere i comandi di lettura/scrittura coerenza per un carico di lavoro in un'istanza replicata, se configuri il profilo di un'app utilizzare il routing a cluster singolo per inviare richieste di lettura e scrittura nello stesso cluster. Puoi instradare il traffico per carichi di lavoro aggiuntivi sull'istanza replicata ad altri cluster dell'istanza, a seconda dei requisiti del carico di lavoro.

Routing a cluster multipli

Un criterio di routing a più cluster instrada le richieste inviate a un'istanza alla regione più vicina in cui l'istanza ha un cluster. Se il cluster diventa non disponibile, il traffico viene eseguito automaticamente sul cluster più vicino disponibile.

Questa configurazione garantisce la coerenza finale. Non puoi attivare le transazioni con una sola riga con il routing multi-cluster, perché possono causare conflitti di dati quando utilizzi il routing multi-cluster. Per maggiori dettagli, vedi Transazioni con una sola riga.

Utilizza il routing a cluster multipli se vuoi l'alta disponibilità (HA). Per consigliato configurazioni di istanza e ulteriori dettagli, consulta Creare un'alta disponibilità ad alta disponibilità.

I due tipi di routing multi-cluster sono qualsiasi cluster e gruppo di cluster.

Routing di qualsiasi cluster

Il routing di qualsiasi cluster rende ogni cluster nell'istanza disponibile per ricevere richieste e per il failover.

Routing del gruppo di cluster

Se vuoi escludere uno o più cluster di un'istanza dai possibili di failover, puoi usare il routing del gruppo di cluster. Questa forma di routing multi-cluster consente di specificare un sottoinsieme di cluster a cui un profilo dell'app può inviare traffico. Questa opzione può essere utile se vuoi riservare un cluster per un carico di lavoro separato.

Transazioni su riga singola

Nelle mutazioni di Bigtable, come richieste di lettura, scrittura ed eliminazione, sono sempre atomici a livello di riga. Sono incluse le mutazioni di più colonne in una singola riga, a condizione che siano incluse nella stessa operazione di mutazione. Bigtable non supportare transazioni che aggiornano atomicamente più di una riga.

Tuttavia, Bigtable supporta alcune operazioni di scrittura che richiederebbero una transazione in altri database. In effetti, Bigtable utilizza transazioni a riga singola per completare queste operazioni. Queste operazioni includono operazioni di lettura e scrittura, mentre tutte le operazioni di lettura e scrittura vengono eseguite a livello atomico, ma le operazioni sono ancora atomiche solo a livello di riga:

  • Operazioni di lettura, modifica e scrittura, inclusi incrementi e aggiunte. Un'operazione di lettura, modifica e scrittura legge un valore esistente, lo incrementa o lo aggiunge e scrive il valore aggiornato nella tabella.
  • Operazioni di verifica e mutazione, anche note come mutazioni condizionali o scritture condizionali. In un'operazione di verifica e modifica, Bigtable controlla una riga per verificare se soddisfa una condizione specificata. Se la condizione è soddisfatta, Bigtable scrive nuovi valori nella riga.

Conflitti tra transazioni su riga singola

Ogni cluster in un'istanza Bigtable è un cluster principale che accetta sia letture che scritture. Di conseguenza, le operazioni che richiedono transazioni con una sola riga possono causare problemi nelle istanze replicate.

Se il tuo caso d'uso lo consente, puoi evitare questi conflitti utilizzando gli aggregati. Quando invii una richiesta di aggiunta a un campo aggregato, il nuovo valore viene unito a il valore esistente. Gli aggregati ti consentono di mantenere una somma o un contatore in esecuzione. Per ulteriori informazioni, consulta Aggregare i valori al momento della scrittura.

Per illustrare il problema che può sorgere quando non utilizzi i dati aggregati, supponi hai una tabella che utilizzi per archiviare i dati di un sistema di gestione dei ticket. Utilizza un contatore intero per memorizzare il numero di biglietti venduti. Ogni volta che vendi un biglietto, la tua app invia un'operazione read-modify-write per incrementare il contatore di 1.

Se la tua istanza ha un solo cluster, le app client possono vendere biglietti contemporaneamente e di incrementare i contatori senza perdita di dati perché le richieste vengono atomicamente nell'ordine in cui vengono ricevuti da quel singolo cluster.

Se invece l'istanza ha più cluster e il profilo della tua app consentire il routing multi-cluster, le richieste simultanee di incremento ogni contatore potrebbe essere inviato a cluster diversi e poi replicato cluster nell'istanza. Se invii due richieste di incremento contemporaneamente con routing a cluster diversi, ognuno termina la propria transazione senza "sapere" sull'altro. Il contatore su ogni cluster viene incrementato di uno. Quando i dati vengono replicati nell'altro cluster, Bigtable non può sapere che intendevi incrementare di 2.

Per aiutarti a evitare risultati indesiderati, Bigtable esegue le seguenti operazioni:

  • Richiede che ogni profilo dell'app specifichi se consente una sola riga transazioni.
  • Ti impedisce di attivare le transazioni su riga singola nel profilo di un'app che utilizza il routing multi-cluster, perché non esiste un modo sicuro queste funzionalità contemporaneamente.
  • Ti avvisa se attivi le transazioni con una riga in due o più profili di app diversi che utilizzano il routing a cluster singolo e rimandano a cluster diversi. Se di creare questo tipo di configurazione, devi assicurarti di non invia richieste di lettura-modifica-scrittura o verifica e modifica in conflitto a diverse cluster.

Passaggi successivi