Opzioni di routing

Quando invii 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 i cluster che ricevono le richieste e la modalità di gestione dei failover.

Questo documento descrive i criteri di routing disponibili per un profilo dell'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 configurarli in combinazione con le priorità di richiesta.

I criteri di routing non influiscono sulla replica, ma devi conoscere il funzionamento della replica di Bigtable prima di leggere questa pagina. Leggi anche la sezione su come gestire i failover.

Routing a un cluster singolo

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

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

Un'istanza replicata fornisce normalmente coerenza finale. Tuttavia, puoi ottenere la coerenza delle letture delle tue scritture per un carico di lavoro in un'istanza replicata se configuri un profilo dell'app per quel carico di lavoro in modo che utilizzi 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 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 non è più 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 le configurazioni di istanze consigliate e ulteriori dettagli, consulta Creare l'alta disponibilità (HA).

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

Routing a qualsiasi cluster

Qualsiasi routing del cluster rende disponibile ogni cluster dell'istanza per la ricezione delle richieste e per il failover.

Routing del gruppo di cluster

Se vuoi escludere uno o più cluster di un'istanza dal 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 traffico. Questa opzione può essere utile se vuoi riservare un cluster per un carico di lavoro separato.

Routing per affinità delle righe

Il routing per affinità riga indirizza automaticamente le richieste di lettura e scrittura di una singola riga a un cluster specifico in base alla chiave di riga della richiesta.

Se vuoi che il routing multicluster raggiunga un tasso più elevato di coerenza delle letture delle tue scritture e la maggior parte delle tue richieste sono operazioni con una sola riga, puoi utilizzare il routing per affinità riga (routing fisso). Per attivare il routing in base all'affinità delle righe, utilizza un profilo dell'app personalizzato con il flag --row-affinity abilitato. Bigtable utilizza la chiave di riga della richiesta per determinare automaticamente a quale cluster indirizzarla. Non puoi impostare manualmente la mappatura tra la chiave di riga e il cluster.

Il routing in base all'affinità delle righe può essere utilizzato solo per richieste di lettura o scrittura di una singola riga. Sono incluse le richieste che chiamano ReadRows con una chiave specificata, MutateRow, MutateRows con una chiave specificata e BulkMutateRow con una chiave specificata.

La coerenza read-your-writes non viene raggiunta completamente con il routing in base all'affinità riga nei seguenti casi:

  • Aggiunta di un cluster all'istanza: il routing in base all'affinità delle righe determina a quale cluster indirizzare in base alla chiave di riga. Se un nuovo cluster viene aggiunto o rimosso dall'istanza mentre il routing in base all'affinità riga è abilitato, l'assegnazione della chiave di riga potrebbe cambiare. Per assicurarti che l'ordine di failover del cluster rimanga invariato nonostante le modifiche all'elenco dei cluster dell'istanza, ti consigliamo di utilizzare i gruppi di cluster impostando il flag --restrict-to.

    Con i gruppi di cluster, non puoi eliminare un cluster in un'istanza se è in uso da un profilo dell'app. Inoltre, qualsiasi nuovo cluster aggiunto all'istanza non inizia a ricevere richieste, a meno che non venga aggiunto esplicitamente al gruppo di cluster del profilo dell'app.

  • Failover: se un cluster non è disponibile o non è in stato normale, le richieste al cluster interessato vengono indirizzate al cluster successivo in base all'ordine di failover. Questo reindirizzamento può influire sulla coerenza.

Per ulteriori informazioni sui failover, consulta Failover. Per scoprire come completare un failover, consulta Gestire i failover.

Transazioni su riga singola

In Bigtable, le mutazioni, come le richieste di lettura, scrittura ed eliminazione, sono sempre atomiche 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 supporta le transazioni che aggiornano in modo atomico 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 letture e scritture, che vengono eseguite in modo 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 controllo e modifica, 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 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 al 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 gli aggregati, supponiamo di avere una tabella che utilizzi per archiviare i dati di un sistema di vendita di biglietti. 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 cluster, le app client possono vendere biglietti contemporaneamente e incrementare i contatori senza perdita di dati perché le richieste vengono gestite in modo atomico nell'ordine in cui vengono ricevute dal singolo cluster.

Se invece la tua istanza ha più cluster e il profilo dell'app consente 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 indirizzate a cluster diversi, ciascuna completa la transazione senza "sapere" dell'altra. 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 a ogni profilo dell'app di specificare se consente transazioni con una sola riga.
  • Ti impedisce di attivare le transazioni con una riga in un profilo dell'app che utilizza il routing multi-cluster, perché non esiste un modo sicuro per attivare entrambe le 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 scelgo di creare questo tipo di configurazione, devo assicurarmi di non inviare richieste di lettura, modifica e scrittura o di controllo e modifica in conflitto a diversi cluster.

Passaggi successivi