Panoramica della replica

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

Questa pagina spiega come funziona la replica in Bigtable e descrive alcuni casi d'uso comuni per la replica. Illustra anche il modello di coerenza usata da Bigtable quando la replica è abilitata e descrive cosa in caso di failover di un cluster su un altro.

Prima di leggere questa pagina, dovresti conoscere le panoramica di Bigtable.

Come funziona la replica

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

Le istanze Bigtable possono avere cluster situati in 8 regioni Bigtable e in ognuna e dispone di 8 regioni, l'istanza può contenere un solo cluster per zona. Per Ad esempio, se crei un'istanza con 3 zone ciascuna, 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 consente di accedere ai dati dell'istanza anche se una zona o regione 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 in un cluster Kubernetes. Analogamente, quando aggiungi un nuovo cluster a un'istanza esistente, Bigtable copia i dati esistenti dal cluster originale alla zona 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 al criterio di garbage collection di una famiglia di colonne

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

Bigtable tratta ogni cluster nella tua istanza come principale in modo da poter eseguire letture e scritture in ogni cluster. Puoi anche impostare dell'istanza, in modo che le richieste provenienti da diversi tipi di applicazioni instradati a diversi cluster.

Prima di aggiungere cluster a un'istanza, devi conoscere le limitazioni che vengono applicate quando modifichi la garbage collection criteri per le tabelle replicate.

Prestazioni

L'uso della replica ha implicazioni in termini di prestazioni che dovresti pianificare quando crei un'istanza replicata o abiliti la replica aggiungendo un cluster in un'istanza a cluster singolo. Ad esempio, cluster replicati in diversi le regioni hanno in genere una latenza di replica più alta rispetto ai cluster replicati la stessa regione. Inoltre, i cluster in istanze che hanno spesso un cluster necessita di più nodi per gestire le attività aggiuntive legate alla gestione della replica. Per saperne di più, consulta Informazioni sul rendimento.

Casi d'uso

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

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 e se un'applicazione esegue una combinazione di letture e scritture, il job batch di grandi dimensioni può rallentare per gli utenti dell'applicazione. Con la replica, puoi utilizzare i profili delle app il routing a cluster singolo per instradare job di analisi batch e traffico delle applicazioni a cluster diversi in modo che i job batch non influiscano utenti. Scopri di più sull'implementazione di questo utilizzo richiesta.

La disponibilità è migliore

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à mediante l'archiviazione separate dei dati in più zone o regioni e con errori automatici cluster, se necessario. Scopri di più sull'implementazione 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 a un singolo cluster. Tuttavia, puoi comunque utilizzare la replica gestendo le richieste con uno cluster e di conservare un altro cluster come backup quasi in tempo reale. Se il cluster di gestione diventa non disponibile, puoi ridurre al minimo il tempo di inattività eseguendo manualmente il failover sul cluster di backup. Scopri di più sull'implementazione di questo utilizzo richiesta.

I dati hanno una presenza globale

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

Modello di coerenza

Per impostazione predefinita, la replica per Bigtable alla fine coerente. Questo termine indica che quando scrivi una modifica a un cluster, alla fine sarai in grado di leggere la modifica dall'altro cluster dell'istanza, ma solo dopo che la modifica è stata replicata tra cluster.

Se la tua istanza è reattiva, la latenza per la replica è in genere pari a secondi o minuti, non ore. Tuttavia, se scrivi una grande quantità di dati a un cluster oppure, se un cluster è sovraccarico o temporaneamente non disponibile, la replica necessita di tempo per recuperare. Inoltre, la replica può richiedere più tempo se che i cluster sono lontani. Di conseguenza, in genere non è sicuro supporre che leggi sempre l'ultimo valore scritto o attendi secondi dopo una scrittura dà a Bigtable il tempo sufficiente per replicare modifica.

Se hai bisogno di una garanzia di coerenza diversa, Bigtable può anche forniscono la coerenza in lettura/scrittura quando la replica è abilitata per fare in modo che un'applicazione non leggerà mai i dati precedente alle sue scritture più recenti. Per ottenere coerenza in operazioni di lettura/scrittura per un gruppo di applicazioni, ogni applicazione del gruppo deve usare un'app profilo configurato per il routing a cluster singolo e tutte le I profili delle app devono instradare le richieste allo stesso cluster. Puoi utilizzare il comando contemporaneamente per altri scopi.

Per alcuni casi d'uso di replica, Bigtable può anche fornire coerenza, che garantisce che tutte le applicazioni per vedere i dati nello stesso stato. Per ottenere una elevata coerenza, utilizza lo Configurazione del profilo app di routing a cluster singolo per le operazioni di lettura/scrittura descritta in precedenza, ma non devi utilizzare il metodo cluster aggiuntivi, a meno che tu non debba eseguire il failover in un'altra in un cluster Kubernetes. Esamina gli esempi di impostazioni di replica per vedere se questo è possibile per il tuo caso d'uso.

Risoluzione dei conflitti

Il valore di ogni cella in una tabella Bigtable è identificato in modo univoco dalla quattro tupla (chiave di riga, famiglia di colonne, qualificatore di colonna, timestamp). Consulta Modello di archiviazione Bigtable per ulteriori dettagli su questi identificatori. Nel raro caso in cui due scrivano con il gli stessi quattro tuple vengono inviati a due cluster diversi, Bigtable il conflitto viene risolto utilizzando un algoritmo interno last write wins basato sul server nel tempo. Bigtable "L'ultima scrittura vince" è deterministica e quando la replica trova il ritardo, tutti i cluster hanno lo stesso valore per la quattro tuple.

Profili di applicazione

Se un'istanza utilizza la replica, devi usare i profili dell'applicazione o i profili dell'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 verifica 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, vedi Esempi di configurazioni di replica.

Criteri di routing

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

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

Failover

Se un cluster Bigtable non risponde, la replica consente alle richieste in entrata il failover del traffico su un altro cluster nella stessa istanza. I failover possono essere manuali o automatica, a seconda del profilo dell'app e di un'applicazione che sta usando e come è configurato il profilo dell'app.

Per maggiori dettagli, consulta Failover.

Eliminazione degli intervalli di righe quando la replica è abilitata

L'API Cloud Bigtable Admin ti consente di abbandonare un intervallo contiguo di righe da una tabella in base alle relative chiavi di riga. Nei casi in cui non usano la replica, Bigtable può eliminare rapidamente un intervallo di righe in modo efficiente. Tuttavia, se la replica è abilitata, l'eliminazione di un intervallo di righe è molto più lento e molto meno efficiente.

Passaggi successivi