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à.
Le seguenti sezioni descrivono i concetti e i comportamenti delle tabelle globali in Amazon DynamoDB.
Concetti relativi alle tabelle globali
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 . Per ulteriori informazioni su come iniziare a utilizzare le tabelle globali, consulta Tutorial: creazione di una tabella globale.
Quando si crea una tabella globale DynamoDB, questa è 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 su una tabella di replica in una regione, DynamoDB propaga automaticamente la scrittura alle altre tabelle di replica nelle altre regioni. AWS
È possibile aggiungere tabelle di replica alla tabella globale in modo che possa essere disponibile in altre regioni.
Con la versione 2019.11.21 (corrente), quando si crea un indice secondario globale in una regione, questo viene replicato automaticamente nelle altre regioni e compilato automaticamente.
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 far sì che le copie della tabella esistano come entità indipendenti. È possibile copiare la tabella globale in una tabella locale in quella regione e quindi eliminare la replica globale per quella regione.
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:
Consentendo solo scritture nella tabella in un’unica regione.
Instradando il traffico utente verso regioni differenti in base alle policy di scrittura, per garantire che non vi siano conflitti.
Evitando l'uso di aggiornamenti non idempotenti come Bookmark = Bookmark + 1, a favore di aggiornamenti statici come Bookmark=25.
Tieni presente che quando indirizzi le scritture o le letture verso una regione, spetta all'applicazione garantire che il flusso venga applicato.
Monitoraggio delle tabelle globali
Puoi usarlo CloudWatch per osservare la metrica. ReplicationLatency Questo consente di tracciare il tempo trascorso tra il momento in cui un elemento viene scritto in una tabella di replica e quando tale elemento viene visualizzato in un'altra replica nella tabella globale. È espresso in millisecondi e viene generato per ogni coppia origine-regione e destinazione-regione. Questa metrica è conservata nella regione di origine. Questa è l'unica CloudWatch metrica fornita da Global Tables v2.
La latenza di replica che si verificherà dipende dalla distanza tra le variabili scelte e da Regioni AWS altre variabili. Se la tabella originale si trovava nella regione Stati Uniti occidentali (California settentrionale) (us-west-1), una replica in una regione più vicina, come la regione Stati Uniti occidentali (Oregon) (us-west-2), avrebbe una latenza di replica inferiore rispetto a una replica in una regione molto più lontana, come la regione Africa (Città del Capo) (af-south-1).
Nota
La latenza di replica non influisce sulla latenza. API Se hai un client e una tabella nella Regione A e aggiungi una replica di tabelle globali nella Regione B, il client e la tabella nella Regione A avranno la stessa latenza di prima dell'aggiunta della Regione B. Se chiami l'PutItemAPIoperazione nella Regione B, alla fine sarà disponibile per la lettura nella Regione A dopo un ritardo di circa la ReplicationLatency statistica disponibile in Amazon. CloudWatch Prima della replica, riceverai una risposta vuota e dopo la replica riceverai l'elemento; entrambe le chiamate avrebbero all'incirca la stessa API latenza.
È 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 è fornito come un numero in secondi dall'inizio dell'epoca Unix. Alla fine di tale periodo, DynamoDB può eliminare l'elemento senza incorrere in costi di scrittura.
Con le tabelle globali si configura TTL in una regione e tale impostazione viene replicata automaticamente nelle altre regioni. Quando un elemento viene eliminato tramite una TTL regola, tale lavoro viene eseguito senza consumare unità di scrittura nella tabella di origine, ma le tabelle di destinazione comporteranno costi relativi alle unità di scrittura replicate.
Tieni presente che se le tabelle di origine e di destinazione hanno capacità di scrittura Provisioned molto basse, ciò potrebbe causare una limitazione, poiché le eliminazioni richiedono capacità di scrittura. TTL
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 il tuo attributo Region 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 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'TransactWriteItemsoperazione 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 verranno replicate in altre regioni solo dopo averle apportate 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 sulle tabelle globali non si propagano 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. Ciò significa che una modifica della capacità di scrittura in una tabella viene replicata nelle altre.
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 entro un secondo.
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. 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 letture fortemente consistenti, dovrà eseguire tutte le letture e le scritture fortemente consistenti nella stessa regione. DynamoDB non supporta letture fortemente coerenti tra le regioni. Pertanto, se si scrive in una regione e si legge da un'altra regione, 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 contemporaneamente, è 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. Questa operazione viene eseguita a livello di elemento. 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 diventa isolata o danneggiata, DynamoDB tiene traccia di tutte le scritture che sono state eseguite ma non sono state 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 anche la propagazione delle scritture da altre tabelle di replica nella regione che ora è di nuovo online.
