Tabelle globali: come funzionano
Importante
Questa documentazione riguarda la versione 2017.11.29 (legacy) delle tabelle globali, che dovrebbe essere evitata per le nuove tabelle globali. Ove possibile, i clienti devono utilizzare le Tabelle globali versione 2019.11.21 (Corrente) poiché offrono maggiore flessibilità, maggiore efficienza e utilizzano meno capacità di scrittura rispetto alla versione 2017.11.29 (Legacy).
Per determinare la versione in uso, consultare Determinare la versione di una tabella globale. Per aggiornare le tabelle globali esistenti dalla versione 2017.11.29 (legacy) alla versione 2019.11.21 (corrente), consultare Versioni delle tabelle globali DynamoDB.
Nelle sezioni seguenti sono riportate ulteriori informazioni sui concetti e il comportamento delle tabelle globali in Amazon DynamoDB.
Concetti relativi alle tabelle globali per la versione 2017.11.29 (legacy)
Una tabella globale è una raccolta di una o più tabelle di replica, tutte di proprietà di un singolo account AWS.
Una tabella di replica (o replica, in breve) è una singola tabella DynamoDB che funziona come parte di una tabella globale. Ogni replica memorizza lo stesso set di elementi di dati. Una tabella globale specificata può avere una sola tabella di replica per regione AWS.
Di seguito è riportata una panoramica concettuale della modalità di creazione di una tabella globale.
-
Crea una tabella DynamoDB ordinaria, con DynamoDB Streams abilitato, in una regione AWS.
-
Ripeti il passaggio 1 per ogni altra regione in cui si desidera replicare i dati.
-
Definire una tabella globale DynamoDB in base alle tabelle create.
La AWS Management Console consente di automatizzare queste attività in modo da poter creare una tabella globale più rapidamente e semplicemente. Per ulteriori informazioni, consulta Creazione di una tabella globale.
La tabella globale DynamoDB risultante è costituita da più tabelle di replica (una per regione) che DynamoDB considera come una singola unità. Ogni replica ha lo stesso nome di tabella e lo stesso schema di chiave primaria. Quando un'applicazione scrive dati in una tabella di replica in una regione, DynamoDB propaga automaticamente la scrittura alle altre tabelle di replica nelle altre regioni AWS.
Importante
Per mantenere sincronizzati i dati della tabella, le tabelle globali creano automaticamente i seguenti attributi per ogni elemento:
-
aws:rep:deleting -
aws:rep:updatetime -
aws:rep:updateregion
Non modificare questi attributi e non creare attributi con lo stesso nome.
È possibile aggiungere tabelle di replica alla tabella globale in modo che possa essere disponibile in altre regioni. (Per fare ciò, la tabella globale deve essere vuota. In altre parole, nessuna delle tabelle di replica può contenere alcun dato.)
È inoltre possibile rimuovere una tabella di replica da una tabella globale. In questo caso, la tabella viene completamente dissociata dalla tabella globale. Questa nuova tabella indipendente non interagisce più con la tabella globale e i dati non vengono più propagati da o verso la tabella globale.
avvertimento
È necessario tenere presente che rimuovere una replica non è un processo atomico. Per garantire un comportamento coerente e uno stato noto, è consigliabile indirizzare il traffico di scrittura dell'applicazione fuori dalla replica che deve essere rimossa in anticipo. Dopo la rimozione, attendi che tutti gli endpoint della Regione della replica mostrino la replica come dissociata prima di effettuare ulteriori scritture come tabella delle Regioni isolata.
Attività comuni
Le attività comuni per le tabelle globali funzionano come segue.
È possibile eliminare la tabella di replica di una tabella globale allo stesso modo di una tabella normale. Ciò interromperà la replica in tale regione ed eliminerà la copia della tabella conservata nella regione. Non è possibile interrompere la replica e fare in modo che le copie della tabella esistano come entità indipendenti.
Nota
Una tabella di origine non può essere eliminata finché non sono trascorse almeno 24 ore da quando è stata utilizzata per avviare una nuova regione. Se si tenta di eliminarla troppo presto, verrà restituito un errore.
Se le applicazioni aggiornano lo stesso elemento in regioni diverse quasi nello stesso momento è possibile che si verifichino dei conflitti. Per garantire la consistenza finale, le tabelle globali DynamoDB utilizzano una riconciliazione di tipo "last writer wins" per aggiornamenti contestuali. Tutte le repliche concorderanno sull'aggiornamento più recente e convergeranno verso uno stato in cui tutte hanno dati identici.
Nota
Sono disponibili diversi modi per evitare i conflitti, inclusi i seguenti:
Utilizzo di una policy IAM per consentire solo le scritture sulla tabella in una Regione.
Utilizzo di una policy IAM per instradare gli utenti verso una sola Regione e mantenimento dell’altra in standby inattiva, oppure, in alternativa, instradamento degli utenti dispari verso una Regione e gli utenti pari verso un’altra Regione.
Evitando l'uso di aggiornamenti non idempotenti come Bookmark = Bookmark + 1, a favore di aggiornamenti statici come Bookmark=25.
Monitoraggio delle tabelle globali
Puoi usare CloudWatch per osservare la metrica ReplicationLatency. Questa metrica tiene traccia del tempo trascorso tra la visualizzazione di un elemento aggiornato nel flusso DynamoDB per una tabella di replica e la sua visualizzazione in un’altra replica nella tabella globale. ReplicationLatency è espresso in millisecondi e viene emesso per ogni coppia di Regioni di origine e di destinazione. Questa è l'unica metrica di CloudWatch fornita da Tabelle globali v2.
Le latenze osservate dipendono dalla distanza tra le regioni scelte, nonché altre variabili. Le latenze comprese tra 0,5 e 2,5 secondi per le regioni possono essere comuni all'interno della stessa area geografica.
Time to live (TTL)
È possibile utilizzare Time to live (TTL) per specificare un nome di attributo il cui valore indica l'ora di scadenza dell'elemento. Questo valore è specificato come un numero in secondi dall’inizio dell’epoca Unix.
Con la versione legacy delle tabelle globali, le eliminazioni TTL non vengono replicate automaticamente su altre repliche. Quando un elemento viene eliminato tramite una regola TTL, tale attività viene eseguita senza utilizzare unità di scrittura.
Tieni presente che se le tabelle di origine e di destinazione hanno una capacità in scrittura con provisioning molto bassa, ciò potrebbe causare una limitazione (della larghezza di banda della rete) poiché le eliminazioni TTL richiedono capacità di scrittura.
Flussi e transazioni con le tabelle globali
Ogni tabella globale produce un flusso indipendente basato su tutte le relative scritture, a prescindere dal punto di origine di tali scritture. Puoi scegliere di utilizzare questo flusso DynamoDB in una regione o in tutte le regioni in modo indipendente.
Se desideri scritture locali elaborate ma non scritture replicate, puoi aggiungere l’attributo di regione a ciascun elemento. Quindi puoi utilizzare un filtro di eventi Lambda per richiamare solo la Lambda per le scritture nella regione locale.
Le operazioni transazionali forniscono garanzie ACID (atomicità, coerenza, isolamento e durabilità) SOLO all’interno della Regione in cui è stata effettuata originariamente l’operazione di scrittura. Le transazioni non sono supportate tra le Regioni nelle tabelle globali.
Ad esempio, se hai una tabella globale con repliche nelle regioni Stati Uniti orientali (Ohio) e Stati Uniti occidentali (Oregon) ed esegui un'operazione TransactWriteItems nella regione Stati Uniti orientali (Ohio), potrai osservare transazioni parzialmente completate nella regione Stati Uniti occidentali (Oregon) man mano che le modifiche vengono replicate. Le modifiche vengono replicate in altre regioni solo dopo essere state confermate nella regione di origine.
Nota
Le tabelle globali eseguono la “scrittura diretta” (write around) DynamoDB Accelerator aggiornando direttamente DynamoDB. Di conseguenza, DAX non saprà che contiene dati obsoleti. La cache DAX verrà aggiornata solo alla scadenza del TTL della cache.
I tag nelle tabelle globali non vengono propagati automaticamente.
Velocità di trasmissione effettiva di lettura e di scrittura
Le tabelle globali gestiscono la velocità di trasmissione effettiva di lettura e di scrittura nei seguenti modi.
La capacità di scrittura deve essere la stessa su tutte le istanze di tabella tra regioni.
Con la versione 2019.11.21 (Corrente), se la tabella è impostata per supportare il dimensionamento automatico o è in modalità on demand, la capacità di scrittura viene automaticamente mantenuta sincronizzata. La quantità attuale di capacità di scrittura allocata in ciascuna Regione aumenterà e diminuirà indipendentemente all’interno delle impostazioni di dimensionamento automatico sincronizzate. Se viene attivata la modalità on demand della tabella, tale modalità verrà sincronizzata con le altre repliche.
La capacità di lettura può variare tra le regioni perché le letture potrebbero essere diverse. Quando si aggiunge una replica globale a una tabella, la capacità della regione di origine viene propagata. Dopo la creazione, è possibile regolare la capacità di lettura di una replica e questa nuova impostazione non viene trasferita sull’altro lato.
Coerenza e risoluzione dei conflitti
Tutte le modifiche apportate a qualsiasi elemento in una tabella di replica vengono replicate a tutte le altre repliche all'interno della stessa tabella globale. In una tabella globale, un elemento appena scritto viene in genere propagato a tutte le tabelle di replica in pochi secondi.
Con una tabella globale, ogni tabella di replica memorizza lo stesso set di elementi di dati. DynamoDB non supporta la replica parziale soltanto di alcuni elementi.
Un'applicazione può leggere e scrivere dati in qualsiasi tabella di replica. DynamoDB supporta letture a consistenza finale tra regioni, ma non supporta elevate consistenze di lettura tra regioni. Se l'applicazione utilizza solo letture a consistenza finale ed emette le letture solo per una regione AWS, funzionerà senza che sia necessaria alcuna modifica. Tuttavia, se l'applicazione richiede elevate consistenze di lettura, dovrà eseguire tutte le elevate consistenze di lettura e le scritture nella stessa regione. In caso contrario, se si scrive in una regione e si legge da un'altra, la risposta di lettura potrebbe includere dati non aggiornati che non riflettono i risultati delle scritture completate di recente nell'altra regione.
Se le applicazioni aggiornano lo stesso elemento in regioni diverse quasi nello stesso momento è possibile che si verifichino dei conflitti. Per garantire la consistenza finale, le tabelle globali DynamoDB utilizzano una riconciliazione di tipo l'ultimo che scrive vince tra gli aggiornamenti simultanei, in cui DynamoDB fa il massimo sforzo per determinare l'ultima operazione di scrittura. Con questo meccanismo di risoluzione dei conflitti, tutte le repliche concorderanno sull'aggiornamento più recente e convergeranno verso uno stato in cui tutte hanno dati identici.
Disponibilità e durabilità
Se una singola regione AWS viene isolata o degradata, l'applicazione può essere reindirizzata a una regione diversa ed eseguire letture e scritture su una tabella di replica diversa. È possibile applicare la logica di business personalizzata per determinare quando reindirizzare le richieste ad altre regioni.
Se una regione viene isolata o degradata, DynamoDB terrà traccia delle scritture eseguite ma non ancora propagate a tutte le tabelle di replica. Quando la regione torna online, DynamoDB riprenderà la propagazione di eventuali scritture in sospeso da tale regione alle tabelle di replica in altre regioni. Riprende inoltre la propagazione delle scritture da altre tabelle di replica alla regione che è ora di nuovo online. Tutte le scritture precedenti riuscite verranno propagate, a prescindere dalla durata dell'isolamento della regione.
