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. Inoltre, spiega il modello di coerenza utilizzato da Bigtable quando la replica è attivata e descrive cosa accade quando un cluster passa a un altro.

Prima di leggere questa pagina, devi conoscere 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 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 con tre 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 una regione Google Cloud non è 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 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 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 presenta una certa latenza e la coerenza tra i cluster è finale.

Bigtable tratta ogni cluster dell'istanza come un cluster principale, 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, devi conoscere le limitazioni che si applicano quando modifichi i criteri di raccolta del garbage per le tabelle replicate.

Prestazioni

L'utilizzo della replica ha implicazioni sul rendimento che devi pianificare quando crei un'istanza replicata o attivi la replica aggiungendo un cluster a un'istanza a cluster singolo. Ad esempio, i cluster replicati in regioni diverse hanno in genere una latenza di replica più elevata 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 della gestione della replica. Per saperne di più, consulta Informazioni sul rendimento.

Casi d'uso

Questa sezione descrive alcuni casi d'uso comuni per la replica di Bigtable. Per trovare le impostazioni di configurazione migliori 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 in 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 i profili delle 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 tue applicazioni. Scopri di più sull'implementazione di questo caso d'uso.

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à sia 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 inoltrare 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 in tempo quasi reale. Se il cluster di pubblicazione diventa non 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 clienti. Ad esempio, puoi creare un'istanza con cluster replicati negli Stati Uniti, in Europa e in Asia e configurare i profili delle 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 è a coerenza finale. Questo termine indica che quando scrivi una modifica in un cluster, alla fine sarai in grado di leggerla dagli altri cluster dell'istanza, ma solo dopo che la modifica viene 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 su un cluster o se un cluster è sovraccaricato o temporaneamente non disponibile, la replica può richiedere del tempo. Inoltre, la replica può richiedere più tempo se i cluster sono lontani. Di conseguenza, in genere non è sicuro presumere di leggere sempre l'ultimo valore scritto o che attendere alcuni secondi dopo una scrittura dia a Bigtable tempo sufficiente per replicare la modifica.

Se hai bisogno di una garanzia di coerenza diversa, Bigtable può anche fornire coerenza di lettura delle tue scritture quando la replica è attivata, il che garantisce che un'applicazione non leggerà mai dati precedenti alle sue scritture più recenti. Per ottenere la coerenza delle letture delle tue scritture per un gruppo di applicazioni, ogni applicazione del gruppo deve utilizzare un profilo dell'app configurato per il routing a cluster singolo e tutti i profili dell'app devono instradare le richieste allo stesso cluster. Puoi utilizzare contemporaneamente i cluster aggiuntivi dell'istanza per altri scopi.

Per alcuni casi d'uso della replica, Bigtable può anche fornire coerenza, che garantisce che tutte le applicazioni vedano i dati nello stesso stato. Per ottenere una elevata coerenza, utilizza la configurazione del profilo dell'app per il routing a cluster singolo per la coerenza delle letture delle tue scritture descritta in precedenza, ma non devi utilizzare i cluster aggiuntivi dell'istanza, a meno che tu non debba eseguire il failover su un altro cluster. Esamina gli esempi di impostazioni di 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 raro caso in cui due scritture con la stessa quadrupletta esatta vengano inviate a due cluster diversi, Bigtable risolve automaticamente il conflitto utilizzando un algoritmo interno l'ultima scrittura è quella valida in base al tempo lato server. L'implementazione di Bigtable "l'ultima scrittura è quella valida" è deterministica e, quando la replica si aggiorna, tutti i cluster hanno lo stesso valore per la quadrupla.

Profili di applicazione

Se un'istanza utilizza la replica, puoi utilizzare i profili delle applicazioni o i profili di app per specificare i criteri di routing. I profili dell'app determinano anche se puoi eseguire transazioni con una sola riga, 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 delle applicazioni. Per esempi di impostazioni che puoi utilizzare per implementare casi d'uso comuni, consulta Esempi di configurazioni di replica.

Criteri di routing

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

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

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 degli intervalli di righe quando la replica è attiva

L'API Cloud Bigtable Admin ti consente di eliminare 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 è attiva, l'eliminazione di un intervallo di righe è molto più lenta e molto meno efficiente.

Passaggi successivi