Questa pagina è stata tradotta dall'API Cloud Translation.

Informazioni sulla replica

La replica per Cloud Bigtable ti consente di aumentare la disponibilità e la durabilità dei tuoi dati copiandoli in 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. Illustra anche il modello di coerenza utilizzato da Bigtable quando la replica è abilitata e cosa succede quando un cluster esegue il failover su un altro.

Per esempi di impostazioni che puoi utilizzare per implementare casi d'uso comuni, consulta gli esempi di impostazioni di replica.
Per informazioni su come creare un'istanza che utilizza la replica, consulta Creare 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 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.

Bigtable supporta cluster replicati situati in un massimo di 8 regioni Google Cloud in cui è disponibile Bigtable. Ogni zona di un'area geografica può contenere un solo cluster. La presenza di cluster in zone o regioni diverse ti consente di accedere ai dati dell'istanza anche se una zona o una regione di Google Cloud non è disponibile.

Quando crei un'istanza con più di un cluster, Bigtable avvia immediatamente la sincronizzazione dei tuoi dati tra i cluster, creando una copia indipendente e separata 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 eventuali modifiche 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 relativi alla garbage collection della famiglia di colonne

È importante notare che la replica ha una certa latenza e la coerenza tra le repliche è finale.

Bigtable tratta ogni cluster nell'istanza come un cluster primario, consentendoti di eseguire operazioni di lettura e scrittura in ogni cluster. Puoi anche configurare l'istanza in modo che le richieste da diversi tipi di applicazioni vengano indirizzate a cluster diversi.

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

Prestazioni

L'uso della replica ha implicazioni sulle prestazioni che devi pianificare quando crei un'istanza multi-cluster o abiliti la replica aggiungendo un cluster a un'istanza a cluster singolo. Ad esempio, i cluster replicati in diverse aree geografiche in genere hanno una latenza di replica più elevata rispetto ai cluster replicati nella stessa area geografica. Inoltre, i cluster nelle istanze con più di un cluster spesso hanno bisogno di più nodi per gestire il lavoro aggiuntivo di gestione della replica. Per scoprire di più, consulta l'articolo 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 in altri casi d'uso, consulta gli esempi di impostazioni di replica.

Isolare le applicazioni di gestione dalle letture in batch

Quando utilizzi un singolo cluster per eseguire un job di analisi batch che esegue numerose letture di grandi dimensioni oltre a un'applicazione che esegue una combinazione di operazioni di lettura e scrittura, il job in batch di grandi dimensioni può rallentare gli utenti per l'applicazione. Con la replica, puoi utilizzare i profili di 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 aree geografiche ed eseguendo il failover automatico tra i 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 dati non aggiornati, 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 gestione diventa non disponibile, puoi ridurre al minimo i tempi di inattività eseguendo manualmente il failover nel cluster di backup. Scopri di più sull'implementazione di questo caso d'uso.

Assicurati che i tuoi dati abbiano una presenza globale

Puoi configurare la replica in località di tutto il mondo per mettere i tuoi dati più vicini ai clienti. Ad esempio, puoi creare un'istanza con cluster replicati negli Stati Uniti, in Europa e in Asia e configurare 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 è definitivamente coerente. 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 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 recuperare. Inoltre, la replica può richiedere più tempo se i cluster sono molto distanti tra loro. Di conseguenza, di solito non è opportuno supporre che tu stia sempre leggendo il valore più recente scritto o che attendere alcuni secondi dopo una scrittura dia a Bigtable il tempo necessario per replicare la modifica.

Se hai bisogno di una garanzia di coerenza diversa, Bigtable può anche fornire la coerenza di lettura/scrittura quando è abilitata la replica, assicurando così che un'applicazione non legga mai dati più vecchi delle scritture più recenti. Per ottenere la coerenza delle operazioni di lettura/scrittura per un gruppo di applicazioni, ogni applicazione del gruppo deve utilizzare un profilo app configurato per il routing del cluster singolo e tutti i profili app devono indirizzare le richieste allo stesso cluster. Puoi utilizzare i cluster aggiuntivi dell'istanza contemporaneamente per altri scopi.

Per alcuni casi d'uso di replica, Bigtable può anche fornire una elevata coerenza, che assicura che tutte le tue applicazioni vedano i tuoi dati nello stesso stato. Per ottenere una elevata coerenza, utilizza la configurazione del profilo dell'app routing del cluster singolo per la coerenza Read-your-Writes, descritta sopra, ma non devi utilizzare i cluster aggiuntivi dell'istanza, a meno che non sia necessario eseguire il failover in un cluster diverso. Controlla 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 evento in cui due scritture con la stessa identica quattro tuple vengano inviate a due cluster diversi, Bigtable risolve automaticamente il conflitto utilizzando un algoritmo interno ultimo scrittura basato sul tempo lato server. Bigtable "vince l'ultima scrittura" (l'implementazione è deterministica e, quando la replica arriva al massimo, tutti i cluster hanno lo stesso valore per la quattro tuple.

Profili di applicazione

Se un'istanza utilizza la replica, puoi usare i profili di applicazione o i profili di app per specificare i criteri di routing. I profili di 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 o scritture condizionali).

Per i dettagli, consulta la sezione Profili di applicazioni. Per esempi di impostazioni che puoi utilizzare per implementare casi d'uso comuni, consulta gli esempi di impostazioni di replica.

Criteri di routing

Ogni profilo dell'app ha 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 specificato.
Routing multi-cluster a qualsiasi cluster: invia le richieste al cluster più vicino disponibile nell'istanza.
Routing del gruppo di cluster: invia richieste al cluster più vicino disponibile all'interno di un gruppo di cluster specificato nelle impostazioni del profilo app.

Failover

Se un cluster Cloud Bigtable non risponde, la replica consente il failover del traffico in entrata su un altro cluster nella stessa istanza. Il failover può essere manuale o automatico, a seconda del profilo dell'app utilizzato dall'applicazione e della sua configurazione.

Per informazioni dettagliate, vedi Failover.

Eliminazione degli intervalli di righe quando è attiva la replica

L'API Bigtable Admin ti consente di rimuovere 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, eliminare un intervallo di righe è significativamente più lento e molto meno efficiente.