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 quali cluster ricevono le richieste e come vengono gestiti i 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 è possibile utilizzare Data Boost. Puoi configurarli insieme alle priorità delle richieste.
I criteri di routing non influiscono sulla replica, ma prima di leggere questa pagina devi conoscere il funzionamento della replica di Bigtable. Devi anche leggere 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 a un altro cluster. I profili dell'app Data Boost e del livello in memoria (anteprima) utilizzano il routing a cluster singolo.
Questo è l'unico criterio di routing che ti consente di abilitare le transazioni su riga singola.
Un'istanza replicata in genere fornisce una coerenza 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 a cluster multipli 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 al cluster disponibile più vicino. La velocità di un failover automatico dipende dalla scadenza della richiesta. Per saperne di più, consulta Failover automatici.
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 a cluster multipli. Per maggiori dettagli, vedi Transazioni su riga singola.
Utilizza il routing a cluster multipli se vuoi una disponibilità elevata (HA). Per le configurazioni di istanze consigliate e ulteriori dettagli, vedi Creare una disponibilità elevata (HA).
Quando utilizzi il routing a cluster multipli, puoi instradare le richieste a qualsiasi cluster nell'istanza o a un gruppo di cluster che definisci. Se il tuo carico di lavoro è costituito principalmente da operazioni su riga singola e vuoi ottenere una frequenza maggiore di coerenza read-your-writes, puoi abilitare il routing con affinità delle righe.
Per ulteriori informazioni sulle considerazioni sul routing relative a SQL, consulta la sezione Routing con SQL di questo documento.
Routing a qualsiasi cluster
Il routing a qualsiasi cluster rende disponibile ogni cluster nell'istanza per ricevere richieste e per il failover.
Routing a gruppi di cluster
Se vuoi escludere uno o più cluster di un'istanza dal possibile failover, puoi utilizzare il routing a gruppi di cluster. Questa forma di routing a cluster multipli ti 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 con affinità delle righe
Il routing con affinità delle righe indirizza automaticamente le richieste di lettura e scrittura a riga singola a un cluster specifico in base alla chiave di riga della richiesta.
Puoi abilitare il routing con affinità delle righe utilizzando gcloud CLI, la Google Cloud console, la libreria client Bigtable per Java o Terraform. Per saperne di più, consulta Creare un profilo dell'app.
Se vuoi che il routing a cluster multipli raggiunga una frequenza maggiore di coerenza read-your-writes e la maggior parte delle richieste siano operazioni su riga singola, puoi utilizzare il routing con affinità delle righe (routing sticky). Bigtable utilizza la chiave di riga della richiesta per determinare automaticamente il cluster a cui instradare la richiesta. Non puoi impostare manualmente il mapping tra la chiave di riga e il cluster.
Il routing con affinità delle righe può essere utilizzato solo per le richieste di lettura o scrittura a riga singola.
Sono incluse 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à delle righe nei seguenti casi:
Aggiunta di un cluster all'istanza: il routing con affinità delle righe determina il cluster a cui instradare in base alla chiave di riga. Se un nuovo cluster viene aggiunto o rimosso dall'istanza mentre il routing con affinità delle righe è abilitato, 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 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 è 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 Gestire i failover.
Routing con SQL
Quando utilizzi SQL per eseguire query su Bigtable, devi tenere in considerazione alcune considerazioni speciali su come vengono instradate le richieste. Il comportamento di routing per le query SQL è diverso da altri tipi di richieste Bigtable.
Il routing con affinità delle righe indirizza le letture e le scritture a riga singola
automaticamente a un cluster specifico in base alla chiave di riga. Bigtable non supporta questo criterio di routing per le query SQL. Questa limitazione significa che non puoi utilizzare il routing con affinità delle righe 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 viene completata, ma l'affinità delle righe non viene applicata.
Transazioni su riga singola
Nelle mutazioni di Bigtable, come le richieste di lettura, scrittura ed eliminazione, sono sempre atomiche a livello di riga. Sono incluse le mutazioni a più colonne in una singola riga, purché 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 le transazioni su riga singola per completare queste operazioni. Queste operazioni includono letture e scritture e tutte le letture e le 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 aggiunte. Un'operazione di lettura-modifica-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 mutazione, 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.
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 saperne di più, consulta Aggregare i valori al momento della scrittura.
Per illustrare il problema che può verificarsi quando non utilizzi gli aggregati, supponiamo di avere una tabella che utilizzi per archiviare i dati di un sistema di ticketing. Utilizzi un contatore intero 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 solo cluster, le app client possono vendere i 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 a cluster multipli, le richieste simultanee di incrementare il contatore potrebbero essere inviate a cluster diversi e poi replicate negli altri cluster dell'istanza. Se invii due richieste di incremento contemporaneamente che vengono instradate a cluster diversi, ogni richiesta completa la transazione senza "conoscere" l'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 che ogni profilo dell'app specifichi se consente le transazioni su riga singola.
- 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.
- Ti avvisa se abiliti le transazioni su riga singola in due o più profili dell'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 mutazione in conflitto a cluster diversi.