Opzioni di routing

Quando invii richieste da un'applicazione a Bigtable, utilizzi un profilo 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 le norme di routing disponibili per un profilo app standard.

Le norme di routing sono particolarmente importanti per i casi d'uso dell'isolamento dei carichi di lavoro, quando non è possibile utilizzare Data Boost. Puoi configurarli insieme alle priorità delle richieste.

Le norme di routing non influiscono sulla replica, ma prima di leggere questa pagina devi conoscere il funzionamento della replica di Bigtable. Ti consigliamo inoltre di leggere Failover.

Routing a un cluster singolo

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

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

Un'istanza replicata in genere fornisce una consistenza finale. Tuttavia, puoi ottenere la coerenza read-your-writes 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 nell'istanza a seconda dei requisiti del carico di lavoro.

Routing a cluster multipli

Un criterio di routing multicluster instrada le richieste che invii 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 sul cluster disponibile più vicino.

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

Utilizza il routing multicluster se vuoi l'alta disponibilità (HA). Per le configurazioni di istanza consigliate e ulteriori dettagli, consulta Creare l'alta disponibilità (HA).

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

Per ulteriori informazioni sulle considerazioni relative al routing correlate a SQL, consulta la sezione Routing con SQL di questo documento.

Routing a qualsiasi cluster

Qualsiasi routing del cluster rende disponibile ogni cluster nell'istanza per ricevere 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 di app può inviare traffico. Può essere utile se vuoi riservare un cluster per un workload separato.

Routing con affinità delle righe

Il routing con affinità di 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 di lettura delle scritture e la maggior parte delle tue richieste sono operazioni su una sola riga, puoi utilizzare il routing con affinità di riga (routing permanente). Per attivare il routing con affinità delle righe, utilizza un profilo dell'app personalizzato con il flag --row-affinity attivato. Bigtable utilizza la chiave di riga della richiesta per determinare automaticamente a quale cluster indirizzare la richiesta. Non puoi impostare manualmente il mapping tra la chiave di riga e il cluster.

Il routing con affinità di riga può essere utilizzato solo per richieste di lettura o scrittura di una sola riga. Ciò include le richieste che chiamano ReadRows con una chiave specificata, MutateRow, e MutateRows con una chiave specificata e BulkMutateRow con una chiave specificata.

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

  • Aggiunta di un cluster all'istanza: il routing con affinità di riga determina a quale cluster eseguire il routing in base alla chiave di riga. Se un nuovo cluster viene aggiunto o rimosso dall'istanza mentre è abilitato il routing con affinità di riga, l'assegnazione della chiave di riga potrebbe cambiare. Per garantire che l'ordine di failover del cluster rimanga lo stesso 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 mentre è in uso da un profilo 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 è integro, le richieste al cluster interessato vengono indirizzate al cluster successivo in base all'ordine di failover. Questo reindirizzamento può influire sulla coerenza.

Per saperne di più sui failover, consulta Failover. Per scoprire come completare un failover, consulta Gestione dei failover.

Routing con SQL

Quando utilizzi SQL per eseguire query su Bigtable, esistono considerazioni speciali su come vengono instradate le richieste. Il comportamento di routing per le query SQL differisce da altri tipi di richieste Bigtable nei seguenti modi:

  • Sebbene un criterio di routing multi-cluster fornisca alta disponibilità tramite il failover automatico per la maggior parte delle richieste, questo comportamento non si estende alle query SQL. Se una richiesta SQL non va a buon fine, non viene eseguito il failover su un altro cluster, anche se il profilo dell'app è configurato per il routing multi-cluster.
  • Il routing con affinità di riga indirizza automaticamente le letture e le scritture di una singola riga a un cluster specifico in base alla chiave di riga. Tuttavia, Bigtable non supporta questa policy di routing per le query SQL. Questa limitazione significa che non puoi utilizzare il routing con affinità di riga con il metodo ExecuteQuery, anche se la query è progettata per leggere una singola riga. Se invii una richiesta ExecuteQuery utilizzando un profilo dell'app con il flag --row-affinity abilitato, la richiesta va a buon fine, ma l'affinità delle righe non viene applicata.

Transazioni su riga singola

Nelle mutazioni Bigtable, come le richieste di lettura, scrittura ed eliminazione, sono sempre atomiche 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 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 e tutte le letture e scritture vengono eseguite in modo atomico, ma le operazioni sono comunque atomiche solo a livello di riga:

  • Operazioni di lettura-modifica-scrittura, inclusi incrementi e accodamenti. Un'operazione di lettura-modifica-scrittura legge un valore esistente, lo incrementa o lo aggiunge al valore esistente 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 a riga singola 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 tenere un totale o un conteggio. Per ulteriori informazioni, vedi Aggregare i valori al momento della scrittura.

Per illustrare il problema che può sorgere quando non utilizzi gli aggregati, supponi di avere una tabella che utilizzi per archiviare i dati di un sistema di biglietteria. Utilizzi un contatore di numeri interi per memorizzare il numero di biglietti venduti. Ogni volta che vendi un biglietto, la tua app invia un'operazione di lettura-modifica-scrittura 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.

D'altra parte, se la tua istanza ha più cluster e il tuo profilo dell'app consente il routing multi-cluster, le richieste simultanee di incrementare il contatore potrebbero essere inviate a cluster diversi, quindi replicate negli altri cluster dell'istanza. Se invii due richieste di incremento contemporaneamente che vengono indirizzate a cluster diversi, ognuna completa la transazione senza "sapere" dell'altra. Il contatore di 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 transazioni a riga singola.
  • Ti impedisce di attivare le transazioni a riga singola in un profilo di app che utilizza il routing multi-cluster, perché non esiste un modo sicuro per attivare entrambe queste funzionalità contemporaneamente.
  • Ti avvisa se abiliti le transazioni a riga singola in due o più profili 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 di controllo e modifica in conflitto a cluster diversi.

Passaggi successivi