Opzioni di routing

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

I criteri di routing sono particolarmente importanti per i casi d'uso di isolamento dei carichi 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 prima di leggere questa pagina devi avere familiarità con il funzionamento della replica di Bigtable. Dovresti leggere anche Failovers.

Routing a un cluster singolo

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

Questo è l'unico criterio di routing che consente di attivare le transazioni su riga singola.

Un'istanza replicata solitamente fornisce la coerenza finale. Tuttavia, puoi ottenere una coerenza di lettura e scrittura per un carico di lavoro in un'istanza replicata se configuri un profilo dell'app per quel carico di lavoro in modo da utilizzare il routing a cluster singolo al fine di 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 del carico 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 si trova un cluster. Se il cluster non è più disponibile, viene eseguito automaticamente il failover del traffico verso il cluster più vicino disponibile.

Questa configurazione fornisce coerenza finale. Non puoi abilitare le transazioni su riga singola con routing multi-cluster, poiché le transazioni su riga singola possono causare conflitti di dati quando utilizzi il routing multi-cluster. Per i dettagli, consulta la sezione Transazioni su riga singola.

Utilizza il routing multi-cluster se vuoi l'alta disponibilità. Per le configurazioni suggerite delle istanze e ulteriori dettagli, consulta Creare un'alta disponibilità (HA).

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

Routing di qualsiasi cluster

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

Routing dei gruppi di cluster

Se vuoi escludere uno o più cluster di un'istanza da un possibile failover, puoi utilizzare il routing del gruppo di cluster. Questa forma di routing multi-cluster consente di specificare un sottoinsieme di cluster a cui un profilo di 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 le richieste di lettura, scrittura ed eliminazione, sono sempre atomiche a livello di riga. Ciò include le mutazioni in più colonne in una singola riga, purché siano incluse nella stessa operazione di mutazione. Bigtable non supporta le 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 su riga singola per completare queste operazioni. Queste operazioni includono letture e scritture e tutte le operazioni di lettura e scrittura vengono eseguite a livello atomico, ma le operazioni sono comunque 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, incrementa o aggiunge il valore esistente e scrive il valore aggiornato nella tabella.
  • Operazioni di verifica e mutazione, note anche come mutazioni condizionali o scritture condizionali. In un'operazione di verifica e mutazione, Bigtable controlla una riga per vedere 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 su riga singola 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 quello esistente. I dati aggregati ti consentono di tenere una somma o un contatore parziale. Per maggiori informazioni, consulta Valori aggregati al momento della scrittura.

Per illustrare il problema che può sorgere se non utilizzi i dati aggregati, supponiamo che tu abbia una tabella da utilizzare per archiviare i dati di un sistema di gestione dei ticket. Utilizzi un contatore di numeri interi per memorizzare il numero di biglietti venduti. Ogni volta che vendi un ticket, l'app invia un'operazione di lettura, modifica e scrittura per incrementare di 1 il contatore.

Se l'istanza ha un solo 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 di incremento del 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, ognuna termina la propria transazione senza "conoscere" l'altra. Il contatore in ogni cluster è incrementato di uno. Quando i dati vengono replicati nell'altro cluster, Bigtable non può sapere che hai intenzione di aumentare di 2.

Per aiutarti a evitare risultati indesiderati, Bigtable:

  • Richiede che ogni profilo dell'app specifichi se consente le transazioni su riga singola.
  • Ti impedisce di abilitare le transazioni su riga singola in un profilo dell'app che utilizza il routing a cluster multipli, perché 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 app 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 verifica e modifica in conflitto a cluster diversi.

Passaggi successivi