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 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 uno standard profilo dell'app.

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 sulla macchina ad altri cluster nell'istanza, a seconda del carico di lavoro i tuoi requisiti.

Routing a cluster multipli

Un criterio di routing multi-cluster instrada le richieste che invii a un'istanza a la regione più vicina in cui è presente un cluster per l'istanza. Se il cluster diventa non disponibile, il failover del traffico viene eseguito automaticamente verso il cluster più vicino disponibili.

Questa configurazione fornisce coerenza finale. Non puoi abilitare una riga singola con routing a cluster multipli, poiché le transazioni su riga singola causa dati conflitti quando utilizzi il routing multi-cluster. Per maggiori dettagli, consulta Riga singola. transazioni.

Utilizza il routing multi-cluster se vuoi l'alta disponibilità. 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 cluster .

Routing di qualsiasi cluster

Con il routing di qualsiasi cluster, ogni cluster nell'istanza può ricevere richieste e per il failover.

Routing dei gruppi di cluster

Se vuoi escludere uno o più cluster di un'istanza dai possibili fai il 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. Questo può essere utile se vuoi prenotare 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 in più colonne in una singola riga, purché siano inclusi nello stesso operazione di mutazione. Bigtable non supportare transazioni che aggiornano atomicamente più di una riga.

Tuttavia, Bigtable supporta alcune operazioni di scrittura che richiedono una transazione in altri database. In effetti, Bigtable utilizza transazioni su 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 codice valore; gli incrementi o le aggiunte al valore esistente; 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 Se la condizione è soddisfatta, Bigtable scrive nuovi valori nella riga.

Conflitti tra transazioni su riga singola

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

Se il tuo caso d'uso lo consente, puoi evitare questi conflitti utilizzando i dati aggregati. Quando invii una richiesta di aggiunta a un campo aggregato, il nuovo valore viene unito a il valore esistente. I dati aggregati ti consentono di tenere una somma o un contatore parziale. Per ulteriori informazioni informazioni, consulta Valori aggregati 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. Utilizzi un un contatore di numeri interi per memorizzare il numero di biglietti venduti. Ogni volta vendi un ticket, la tua app invia un'email di lettura, modifica e scrittura per aumentare il contatore di 1.

Se la tua istanza ha un solo cluster, le app client possono vendere biglietti contemporaneamente e incrementare i contatori senza perdite 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, ciascuna termina la propria transazione senza "sapere" sull'altro. Il contatore in ogni cluster è incrementato di uno. Quando i dati vengono replicati nell'altro cluster, Bigtable probabilmente vuoi incrementare di 2.

Per aiutarti a evitare risultati indesiderati, Bigtable:

  • 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.
  • Ricevi un avviso se attivi le transazioni su riga singola in due o più app diverse profili che utilizzano il routing a cluster singolo e puntano 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