Panoramica della replica

La replica per Bigtable consente di aumentare la disponibilità e la durabilità dei tuoi dati in quanto vengono copiati su più regioni o più zone all'interno della stessa regione. Puoi anche isolare i carichi di lavoro instradando diversi tipi di richieste a cluster diversi.

Questa pagina spiega come funziona la replica in Bigtable e descrive alcuni casi d'uso comuni per la replica. Spiega inoltre il modello di coerenza utilizzato da Bigtable quando la replica è abilitata e descrive cosa succede quando un cluster esegue il failover a un altro.

Per esempi di impostazioni che puoi utilizzare per implementare casi d'uso comuni, vedi Esempi di configurazioni di replica.
Per scoprire come creare un'istanza che utilizza la replica, consulta Crea un'istanza.
Per scoprire come abilitare la replica per un'istanza esistente, consulta Aggiungere un cluster.
Per comprendere i costi associati alla replica, consulta la sezione Prezzi.

Prima di leggere questa pagina, dovresti acquisire familiarità con la panoramica di Bigtable.

Come funziona la replica

Per utilizzare la replica in un'istanza Bigtable, crea una nuova istanza con più di un cluster o aggiungi cluster a un'istanza esistente.

Le istanze Bigtable possono avere cluster situati in un massimo di 8 regioni Bigtable e, in ciascuna di queste 8 regioni, l'istanza può contenere un solo cluster per zona. Ad esempio, se crei un'istanza in 8 regioni, ognuna con 3 zone, l'istanza può avere fino a 24 cluster.

Ogni zona di una regione può contenere un solo cluster. Avere cluster in zone o regioni diverse ti consente di accedere ai dati dell'istanza anche se una zona o una regione non è disponibile. Google Cloud

Quando crei un'istanza con più di un cluster, Bigtable inizia immediatamente a sincronizzare i dati tra i cluster, creando una copia separata e indipendente dei dati in ogni zona in cui l'istanza ha un cluster. Allo stesso modo, quando aggiungi un nuovo cluster a un'istanza esistente, Bigtable copia i dati esistenti dalla zona del cluster originale alla zona del nuovo cluster, quindi sincronizza le modifiche ai dati tra le zone.

Bigtable replica qualsiasi modifica ai tuoi dati, inclusi tutti i seguenti tipi di modifiche:

Aggiornamenti ai dati nelle tabelle esistenti
Tabelle nuove ed eliminate
Famiglie di colonne aggiunte e rimosse
Modifiche alla policy di garbage collection di una famiglia di colonne

La replica ha una certa latenza e la coerenza tra i cluster è finale.

Bigtable considera ogni cluster della tua istanza come un cluster principale, quindi puoi eseguire operazioni di lettura e scrittura in ogni cluster. Puoi anche configurare l'istanza in modo che le richieste di diversi tipi di applicazioni vengano instradate a cluster diversi.

Prima di aggiungere cluster a un'istanza, devi conoscere le limitazioni che si applicano quando modifichi i criteri di garbage collection per le tabelle replicate.

Prestazioni

L'utilizzo della replica ha implicazioni sulle prestazioni che devi pianificare quando crei un'istanza replicata o abiliti la replica aggiungendo un cluster a un'istanza a un solo cluster. Ad esempio, i cluster replicati in regioni diverse in genere hanno una latenza di replica superiore rispetto ai cluster replicati nella stessa regione. Inoltre, i cluster nelle istanze con più di un cluster spesso richiedono più nodi per gestire il lavoro aggiuntivo di gestione della replica. Per saperne di più, consulta Comprendere il rendimento.

Casi d'uso

Questa sezione descrive alcuni casi d'uso comuni per la replica di Bigtable. Per trovare le migliori impostazioni di configurazione per ogni caso d'uso, nonché suggerimenti per l'implementazione di altri casi d'uso, consulta Esempi di impostazioni di replica.

Le applicazioni pubblicate sono isolate dalle letture batch

Quando utilizzi un singolo cluster per eseguire un job di analisi batch che esegue numerose letture di grandi dimensioni insieme a un'applicazione che esegue un mix di letture e scritture, il job batch di grandi dimensioni può rallentare le operazioni per gli utenti dell'applicazione. Con la replica, puoi utilizzare i profili delle app con il routing a cluster singolo per instradare i job di analisi batch e il traffico delle applicazioni a cluster diversi, in modo che i job batch non influiscano sugli utenti delle tue applicazioni. Scopri di più sull'implementazione di questo caso d'uso.

Migliora la disponibilità

Se un'istanza ha un solo cluster, la durabilità e la disponibilità dei dati sono limitate alla zona in cui si trova il cluster. La replica può migliorare sia la durabilità che la disponibilità archiviando copie separate dei dati in più zone o regioni ed eseguendo il failover automatico tra i cluster, se necessario. Scopri di più sull'implementazione di questo caso d'uso.

Il backup è quasi in tempo reale

In alcuni casi, ad esempio se non puoi permetterti di leggere dati obsoleti, dovrai sempre indirizzare le richieste a un singolo cluster. Tuttavia, puoi comunque utilizzare la replica gestendo le richieste con un cluster e mantenendo un altro cluster come backup quasi in tempo reale. Se il cluster di pubblicazione non è più disponibile, puoi ridurre al minimo i tempi di inattività eseguendo manualmente il failover al cluster di backup. Scopri di più sull'implementazione di questo caso d'uso.

I dati hanno una presenza globale

Puoi configurare la replica in località in tutto il mondo per avvicinare i dati ai tuoi clienti. Ad esempio, puoi creare un'istanza con cluster replicati negli Stati Uniti, in Europa e in Asia e configurare profili app per indirizzare il traffico dell'applicazione al cluster più vicino. Scopri di più sull'implementazione di questo caso d'uso.

Modelli di coerenza

Questa sezione spiega i modelli di coerenza che Bigtable può fornire per la replica, a seconda della policy di routing che utilizzi.

Coerenza finale

Per impostazione predefinita, la replica per Bigtable è a coerenza finale. Questo termine indica che quando scrivi una modifica in un cluster, alla fine puoi leggerla dagli altri cluster dell'istanza, ma solo dopo che la modifica viene replicata tra i cluster.

Se l'istanza risponde, la latenza per la replica è in genere di pochi secondi o minuti, non ore. Tuttavia, se stai scrivendo una grande quantità di dati in un cluster o se un cluster è sovraccarico o temporaneamente non disponibile, può essere necessario del tempo prima che la replica venga completata. Inoltre, la replica può richiedere più tempo se i cluster sono molto distanti tra loro. Di conseguenza, in genere non è sicuro presupporre di leggere sempre l'ultimo valore scritto o che l'attesa di qualche secondo dopo una scrittura dia a Bigtable il tempo sufficiente per replicare la modifica.

Coerenza read-your-writes

Puoi ottenere la coerenza read-your-writes con il routing a cluster singolo e puoi raggiungere un alto tasso di coerenza read-your-writes utilizzando il routing multicluster con il routing con affinità di riga o quando i cluster dell'istanza si trovano ciascuno in una regione diversa.

Routing a un cluster singolo

Se utilizzi il routing a cluster singolo, Bigtable può fornire coerenza di lettura delle tue scritture quando la replica è attivata. Questo modello di coerenza garantisce che un'applicazione non legga mai dati più vecchi delle sue scritture più recenti.

Ogni profilo dell'app che utilizzi deve essere configurato per il routing a un singolo cluster e tutti i profili dell'app devono instradare le richieste allo stesso cluster. Puoi utilizzare i cluster aggiuntivi dell'istanza contemporaneamente per altri scopi.

Routing multi-cluster con un cluster per regione

Con il routing multi-cluster, Bigtable indirizza sempre le richieste al cluster più vicino. Se ogni cluster nella tua istanza si trova in una regione Bigtable diversa e utilizzi un profilo dell'app configurato per il routing multicluster, i tuoi dati hanno una coerenza di lettura e scrittura all'interno della regione di origine, a meno che non si verifichi un failover.

Routing con affinità delle righe

Per ottenere un tasso più elevato di coerenza di lettura/scrittura con il routing multi-cluster a un'istanza con più di un cluster in una regione, puoi utilizzare un profilo di app configurato per il routing per affinità di riga (routing sticky).

Con il routing con affinità di riga, Bigtable indirizza automaticamente le richieste di lettura e scrittura di una singola riga a un cluster specifico in base alla chiave di riga della richiesta. Non puoi impostare manualmente la mappatura tra la chiave di riga e il cluster. La coerenza non è garantita perché le richieste potrebbero comunque non riuscire per vari motivi, ad esempio quando un cluster non è integro, sono presenti problemi di rete o il cluster ha ricevuto troppe richieste.

Elevata coerenza

Per alcuni casi d'uso della replica, Bigtable può anche fornire una coerenza forte, che garantisce che tutte le tue applicazioni vedano i tuoi dati nello stesso stato. Per ottenere una elevata coerenza, utilizza la configurazione del profilo app di routing a cluster singolo per la coerenza di lettura/scrittura descritta in precedenza, ma non devi utilizzare i cluster aggiuntivi dell'istanza, a meno che tu non debba eseguire il failover su un cluster diverso. Consulta gli esempi di impostazioni della replica per verificare se questa operazione è possibile per il tuo caso d'uso.

Risoluzione dei conflitti

Ogni valore di cella in una tabella Bigtable è identificato in modo univoco dalla quadrupla (chiave di riga, famiglia di colonne, qualificatore di colonna, timestamp). Per ulteriori dettagli su questi identificatori, consulta Modello di archiviazione Bigtable. Nel caso in cui due scritture con la stessa quadrupla esatta vengano inviate a due cluster diversi, Bigtable risolve automaticamente il conflitto utilizzando un algoritmo interno last write wins basato sull'ora lato server. L'implementazione "last write wins" di Bigtable è deterministica e, quando la replica viene completata, tutti i cluster hanno lo stesso valore per la quadrupla.

Profili di applicazione

Se un'istanza utilizza la replica, i profili applicazione o i profili app, per specificare i criteri di routing. I profili delle app determinano anche se puoi eseguire transazioni a riga singola, che includono operazioni di lettura-modifica-scrittura (inclusi incrementi e aggiunte) e operazioni di controllo e mutazione (note anche come mutazioni condizionali o scritture condizionali).

Per maggiori dettagli, vedi Profili delle applicazioni. Per esempi di impostazioni che puoi utilizzare per implementare casi d'uso comuni, vedi Esempi di configurazioni di replica.

Policy di routing

Ogni profilo dell'app ha un criterio di routing che controlla quali cluster gestiscono le richieste in entrata dalle tue applicazioni. Le opzioni per i criteri di routing includono le seguenti:

Routing a un cluster singolo: invia tutte le richieste a un singolo cluster che specifichi.
Routing multicluster:
- Routing a qualsiasi cluster: invia le richieste al cluster più vicino nell'istanza.
- Routing del gruppo di cluster: limita tutte le richieste ai cluster che specifichi.
- Routing con affinità di riga: invia una richiesta di lettura o scrittura di una singola riga a un cluster specifico in base alla chiave di riga della richiesta. Per ulteriori informazioni, consulta Routing con affinità di riga.

Failover

Se un cluster Bigtable smette di rispondere, la replica consente il failover del traffico in entrata su un altro cluster nella stessa istanza. I failover possono essere manuali o automatici, a seconda del profilo dell'app utilizzato da un'applicazione e della modalità di configurazione del profilo dell'app. Per maggiori dettagli, vedi Failover.

Eliminazione di intervalli di righe quando la replica è abilitata

L'API Cloud Bigtable Admin ti consente di eliminare un intervallo contiguo di righe da una tabella in base alle chiavi di riga. Nelle istanze che non utilizzano la replica, Bigtable può eliminare un intervallo di righe in modo rapido ed efficiente. Tuttavia, quando la replica è abilitata, l'eliminazione di un intervallo di righe è molto più lenta e meno efficiente.