Panoramica della replica

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

Questa pagina spiega come funziona la replica in Bigtable e 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 su un altro cluster.

Per esempi di impostazioni che puoi utilizzare per implementare casi d'uso comuni, consulta Esempi di impostazioni di replica.
Per informazioni su come creare un'istanza che utilizza la replica, consulta Creazione di 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 dei 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 oppure aggiungi cluster a un'istanza esistente.

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

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

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 tuoi dati in ogni zona in cui l'istanza ha un cluster. Analogamente, quando aggiungi un nuovo cluster a un'istanza esistente, Bigtable copia i dati esistenti dalla zona del cluster originale a quella del nuovo cluster, quindi sincronizza le modifiche ai dati tra le zone.

Bigtable replica qualsiasi modifica ai 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 ai criteri di garbage collection di una famiglia di colonne

È importante notare che la replica presenta una certa latenza, mentre la coerenza tra le repliche è finale. È importante notare che la replica presenta una certa latenza e che la coerenza tra i cluster è finale.

Bigtable tratta ogni cluster nell'istanza come cluster primario, quindi puoi eseguire letture e scritture 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, è bene 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 dovresti pianificare quando crei un'istanza replicata o abiliti la replica aggiungendo un cluster a un'istanza a cluster singolo. Ad esempio, i cluster replicati in regioni diverse di solito hanno una latenza di replica maggiore rispetto ai cluster replicati nella stessa regione. Inoltre, i cluster in istanze che hanno più di un cluster spesso hanno bisogno di più nodi per gestire il lavoro aggiuntivo di gestione della replica. Per scoprire di più, consulta Informazioni sul rendimento.

Casi d'uso

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

Isola le applicazioni di gestione 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 una combinazione di letture e scritture, il job batch di grandi dimensioni può rallentare le operazioni per gli utenti dell'applicazione. Con la replica puoi utilizzare profili di app con 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 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 tuoi dati in più zone o regioni ed eseguendo automaticamente il failover tra cluster, se necessario. Scopri di più sull'implementazione di questo caso d'uso.

Fornisci backup quasi in tempo reale

In alcuni casi, ad esempio se non puoi permetterti di leggere i dati inattivi, dovrai sempre instradare 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 gestione non è più disponibile, puoi ridurre al minimo i tempi di inattività eseguendo il failover manuale sul cluster di backup. Scopri di più sull'implementazione di questo caso d'uso.

Assicurati che i tuoi dati siano presenti a livello globale

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

Modello di coerenza

Per impostazione predefinita, la replica per Bigtable è alla fine coerente. Questo termine significa che quando scrivi una modifica in un cluster, alla fine sarai in grado di leggere la modifica dagli altri cluster nell'istanza, ma solo dopo che la modifica è stata replicata tra i cluster.

Se l'istanza è reattiva, la latenza per la replica è in genere di alcuni secondi o minuti, non di ore. Tuttavia, se stai scrivendo una grande quantità di dati in un cluster o se un cluster è sovraccarico o temporaneamente non disponibile, la replica potrebbe richiedere del tempo per recuperare. Inoltre, la replica può richiedere più tempo se i cluster sono distanti. Di conseguenza, in genere non è sicuro supporre che tu stia leggendo sempre l'ultimo valore scritto o che attendere qualche secondo dopo una scrittura dia a Bigtable il tempo sufficiente per replicare la modifica.

Se hai bisogno di una garanzia di coerenza diversa, Bigtable può anche fornire coerenza di lettura/scrittura quando è abilitata la replica, in modo che un'applicazione non possa mai leggere dati precedenti alle scritture più recenti. Per garantire la coerenza delle operazioni di lettura e scrittura per un gruppo di applicazioni, ogni applicazione del gruppo deve utilizzare un profilo di applicazione configurato per il routing a cluster singolo e tutti i profili di app devono instradare le richieste allo stesso cluster. Puoi utilizzare contemporaneamente altri cluster dell'istanza per altri scopi.

Per alcuni casi d'uso della replica, Bigtable può anche fornire un'elevata coerenza, che assicura che tutte le applicazioni vedano i dati nello stesso stato. Per una elevata coerenza, utilizza la configurazione del profilo dell'app di routing a cluster singolo per la coerenza delle operazioni 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. Esamina gli esempi di impostazioni di replica per verificare se questo è possibile per il tuo caso d'uso.

Risoluzione dei conflitti

Ogni valore di cella in una tabella Bigtable è identificato in modo univoco da quattro tuple (chiave di riga, famiglia di colonne, qualificatore di colonna, timestamp). Per ulteriori dettagli su questi identificatori, consulta Modello di archiviazione Bigtable. Nel raro caso in cui due scritture con le stesse quattro tuple vengano inviate a due cluster diversi, Bigtable risolve automaticamente il conflitto utilizzando un algoritmo interno l'ultima scrittura vince in base al tempo lato server. L'implementazione "l'ultima scrittura vince" di Bigtable è deterministica e, quando la replica raggiunge il valore, tutti i cluster hanno lo stesso valore per la quattro tupla.

Profili di applicazione

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

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

Criteri di routing

Ogni profilo di app dispone di un criterio di routing che controlla quali cluster gestiscono le richieste in arrivo dalle tue applicazioni. Le opzioni per i criteri di routing includono:

Routing a cluster singolo: invia tutte le richieste a un singolo cluster da te specificato.
Routing multi-cluster a qualsiasi cluster: invia le richieste al cluster più vicino disponibile nell'istanza.
Routing di gruppi di cluster: invia le richieste al cluster più vicino disponibile all'interno di un gruppo di cluster specificato nelle impostazioni del profilo dell'app.

Failover

Se un cluster Bigtable non risponde, 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 usato da un'applicazione e della configurazione del profilo stesso.

Per maggiori dettagli, vedi Failover.

Eliminazione degli intervalli di righe quando la replica è abilitata

L'API Cloud Bigtable Admin ti consente di rilasciare un intervallo contiguo di righe da una tabella in base alle relative 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 è notevolmente più lenta e molto meno efficiente.