Opzioni di routing

Quando invii richieste da un'applicazione a Bigtable , utilizzi un profilo di app che indica a Bigtable come gestire le richieste. Un profilo di 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 di app standard.

I criteri di routing sono particolarmente importanti per i casi d'uso di isolamento del carico di lavoro, quando non puoi utilizzare Data Boost (anteprima). Puoi configurarle insieme alle priorità delle richieste.

I criteri di routing non influiscono sulla replica, ma è consigliabile avere familiarità con il funzionamento della replica Bigtable prima di leggere questa pagina. Dovresti anche leggere l'articolo Failover.

Routing a un cluster singolo

Un criterio di routing a cluster singolo instrada tutte le richieste a un cluster nella tua istanza. Se il cluster non è più disponibile, devi eseguire manualmente il failover su un altro cluster.

Questo è l'unico criterio di routing che ti consente di abilitare transazioni su riga singola.

Un'istanza replicata fornisce in genere un'eventuale coerenza. Tuttavia, puoi ottenere una coerenza di lettura/scrittura per un carico di lavoro in un'istanza replicata se configuri il profilo di un'app per quel carico di lavoro in modo da utilizzare il routing a cluster singolo per inviare richieste di lettura e scrittura allo stesso cluster. Puoi instradare il traffico per carichi di lavoro aggiuntivi sull'istanza replicata ad altri cluster nell'istanza, a seconda dei requisiti dei carichi di lavoro.

Routing a cluster multipli

Un criterio di routing multi-cluster instrada le richieste inviate a un'istanza alla regione più vicina in cui l'istanza ha un cluster. Se il cluster non è più disponibile, il traffico esegue automaticamente il failover al cluster più vicino disponibile.

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

Utilizza il routing multi-cluster se vuoi usufruire dell'alta disponibilità. Per le configurazioni delle istanze consigliate e ulteriori dettagli, consulta Creare un'alta disponibilità.

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

Routing del cluster

Con il routing di un cluster, ogni cluster dell'istanza è disponibile per ricevere richieste e per il failover.

Routing dei gruppi di cluster

Se vuoi escludere uno o più cluster di un'istanza da un possibile failover, puoi utilizzare il routing dei gruppi di cluster. Questa forma di routing multi-cluster consente di specificare un sottoinsieme di cluster a cui un profilo dell'app può inviare il traffico. Questa operazione può essere utile se vuoi prenotare un cluster per un carico di lavoro separato.

Transazioni su riga singola

Nelle mutazioni di Bigtable, come le richieste di lettura, scrittura ed eliminazione, è sempre atomica a livello di riga. Ciò include le mutazioni di più colonne in una singola riga, a condizione che siano incluse nella stessa operazione di mutazione. Bigtable non supporta le transazioni che si aggiornano atomicamente per 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 letture e scritture e tutte le letture e le scritture 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 apparizioni. Un'operazione di lettura, modifica e scrittura legge un valore esistente, incrementa o aggiunge il valore esistente e scrive il valore aggiornato nella tabella.
Operazioni di controllo e mutazione, note anche come mutazioni condizionali o scritture condizionali. In un'operazione di controllo 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 primario che accetta sia letture che scritture. Di conseguenza, le operazioni che richiedono transazioni su riga singola possono causare problemi nelle istanze replicate.

Ad esempio, supponi di avere una tabella che utilizzi per archiviare i dati di un sistema di gestione di biglietti. Puoi utilizzare un contatore di numeri interi per archiviare il numero di biglietti venduti. Ogni volta che vendi un ticket, la tua app invia un'operazione di lettura, modifica e scrittura per incrementare il contatore di 1.

Se l'istanza ha un cluster, le app client possono vendere ticket contemporaneamente e aumentare i contatori senza perdita di dati perché le richieste vengono gestite a livello atomico nell'ordine in cui vengono ricevute dal singolo cluster.

Se invece l'istanza ha più cluster e il profilo dell'app consentiva il routing multi-cluster, le richieste simultanee per incrementare il contatore potrebbero essere inviate a cluster diversi e poi replicate negli altri cluster dell'istanza. Se invii contemporaneamente due richieste di incremento instradate a cluster diversi, ciascuna termina la transazione senza "sapere" l'altra. Il contatore di ogni cluster viene incrementato di uno. Quando i dati vengono replicati nell'altro cluster, Bigtable non è in grado di sapere che intendevi incrementare di 2.

Per aiutarti a evitare risultati indesiderati, Bigtable:

Richiede che ogni profilo dell'app specifichi se consente transazioni su riga singola.
Impedisce di abilitare le transazioni su riga singola in un profilo di app che utilizza il routing multi-cluster, in quanto non esiste un modo sicuro per abilitare entrambe le funzionalità contemporaneamente.
Ricevi un avviso se abiliti le transazioni su riga singola in due o più profili di applicazione diversi che utilizzano il routing a cluster singolo e puntano a cluster diversi. Se scegli di creare questo tipo di configurazione, devi assicurarti di non inviare richieste di lettura, modifica, scrittura o controllo e modifica in conflitto a cluster diversi.