Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
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. I clienti devono utilizzare la versione 2019.11.21 (attuale) di Global Tables quando possibile, poiché offre maggiore flessibilità, maggiore efficienza e consuma meno capacità di scrittura rispetto alla 2017.11.29 (Legacy).
Per determinare la versione in uso, consultare Determinazione della versione della tabella globale di DynamoDB in uso. Per aggiornare le tabelle globali esistenti dalla versione 2017.11.29 (legacy) alla versione 2019.11.21 (corrente), consultare Aggiornamento delle tabelle globali.
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.
AWS Management Console Automatizza queste attività, in modo da poter creare una tabella globale più rapidamente e facilmente. 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
Tieni presente che la rimozione di 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 averla rimossa, attendi che tutti gli endpoint della regione di replica mostrino la replica come dissociata prima di effettuare ulteriori scritture su di essa come tabella regionale 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 IAM politica per consentire le scritture sulla tabella solo in una regione.
Utilizzare una IAM politica per indirizzare gli utenti verso una sola regione e mantenere l'altra come inattiva, oppure indirizzare alternativamente gli utenti dispari verso una regione e persino gli utenti 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
È possibile utilizzare per osservare la CloudWatch 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 il momento in cui tale elemento appare in un'altra replica nella tabella globale. ReplicationLatencyè espressa in millisecondi e viene emessa per ogni coppia origine-regione e destinazione-regione. Questa è l'unica metrica fornita da Global Tables v2. CloudWatch
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.
È ora di vivere () TTL
È possibile utilizzare Time To Live (TTL) per specificare il nome di un attributo il cui valore indica l'ora di scadenza dell'elemento. Questo valore è specificato come numero in secondi dall'inizio dell'epoca Unix.
Con la versione legacy di Global Tables, le TTL eliminazioni non vengono replicate automaticamente su altre repliche. Quando un elemento viene eliminato tramite una TTL regola, tale operazione viene eseguita senza consumare unità di scrittura.
Tieni presente che se la tabella di origine e di destinazione ha una capacità di scrittura Provisioned molto bassa, ciò potrebbe causare una limitazione poiché le TTL eliminazioni 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à) ONLY all'interno della regione in cui è stata originariamente effettuata la scrittura. Le transazioni non sono supportate tra le regioni nelle tabelle globali.
Ad esempio, se disponi di una tabella globale con repliche nelle regioni Stati Uniti orientali (Ohio) e Stati Uniti occidentali (Oregon) ed esegui un' TransactWriteItems operazione nella regione Stati Uniti orientali (Ohio), puoi osservare le transazioni parzialmente completate nella regione Stati Uniti occidentali (Oregon) mentre 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 non DAX saprà che contiene dati obsoleti. La DAX cache verrà aggiornata solo alla scadenza della TTL 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 ridimensionamento automatico o è in modalità on-demand, la capacità di scrittura viene automaticamente mantenuta sincronizzata. La quantità attuale di capacità di scrittura fornita in ciascuna regione aumenterà e diminuirà indipendentemente dalle impostazioni di auto scaling sincronizzato. 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 per 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 alla fine coerenti ed emette letture solo su una AWS regione, funzionerà senza 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 AWS regione viene isolata o danneggiata, l'applicazione può reindirizzare verso 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.
