Utilizzo delle tabelle globali DynamoDB - Amazon DynamoDB
Aspetti chiaveAspetti chiave della MRECAspetti chiave della MRSCCasi d’usoConclusioni e risorse

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à.

Utilizzo delle tabelle globali DynamoDB

Le tabelle globali sono progettate in base all’impatto globale di Amazon DynamoDB per offrire un database completamente gestito, multi-Regione e multi-attivo in grado di garantire prestazioni di lettura e scrittura rapide e locali per applicazioni globali dimensionate su larga scala. Le tabelle globali replicano automaticamente le tabelle DynamoDB tra quelle di tua scelta. Regioni AWS Non sono necessarie modifiche all'applicazione perché le tabelle globali utilizzano DynamoDB APIs esistente. Non sono previsti costi anticipati o impegni per l'utilizzo delle tabelle globali; vengono infatti addebitati solo i costi per le risorse utilizzate.

In questa guida viene illustrato come utilizzare efficacemente le tabelle globali di DynamoDB. Vengono fornite informazioni chiave sulle tabelle globali, spiegati i casi d’uso principali della funzionalità, descritte le due modalità di coerenza, introdotta una tassonomia di tre diversi modelli di scrittura da prendere in considerazione, vengono illustrate le quattro principali scelte di instradamento delle richieste che è possibile implementare, illustrati i modi per evacuare una Regione attiva o una Regione offline, viene spiegato come pensare alla pianificazione della capacità di throughput e viene fornito un elenco di aspetti da considerare per l’implementazione delle tabelle globali.

Questa guida si inserisce in un contesto più ampio di implementazioni in più AWS regioni, come illustrato nel white paper AWS Multi-Region Fundamentals e nei modelli di progettazione della resilienza dei dati con video. AWS

Argomenti

Aspetti chiave sulla progettazione di tabelle DynamoDB globali

  • Esistono due versioni delle tabelle globali: la versione corrente Tabelle globali versione 2019.11.21 (Corrente) (a volte detta “V2”) e Tabelle globali versione 2017.11.29 (Legacy) (a volte detta “V1”). Questa guida fa riferimento esclusivamente alla versione corrente.

  • DynamoDB (senza tabelle globali) è un servizio Regionale, il che significa che è altamente disponibile e intrinsecamente resiliente ai guasti dell’infrastruttura, inclusi i guasti in un’intera zona di disponibilità. Una tabella DynamoDB a Regione singola è progettata per garantire una disponibilità del 99,99%. Per ulteriori informazioni, consulta l’Accordo sul livello di servizio (SLA).

  • Una tabella globale DynamoDB replica i propri dati tra due o più Regioni. Una tabella DynamoDB multi-Regione è progettata per garantire una disponibilità del 99,999%. Con una pianificazione adeguata, le tabelle globali possono contribuire a creare un’architettura resiliente ai guasti a livello Regionale.

  • DynamoDB non ha un endpoint globale. Tutte le richieste vengono effettuate a un endpoint Regionale, che accede all’istanza della tabella globale locale per tale Regione.

  • Le chiamate a DynamoDB non devono passare tra Regioni. La best practice prevede che un’applicazione che risiede in una Regione acceda direttamente solo all’endpoint DynamoDB locale per tale Regione. Se vengono rilevati problemi all’interno di una Regione, nel livello DynamoDB o nello stack circostante, il traffico degli utenti finali deve essere instradato a un endpoint dell’applicazione diverso ospitato in una Regione diversa. Le tabelle globali assicurano che l’applicazione ospitata in ogni Regione abbia accesso agli stessi dati.

Modalità di coerenza

Quando viene creata una tabella globale, viene configurata la modalità di coerenza. Le tabelle globali supportano due modalità di coerenza: coerenza finale multi-Regione (MREC, Multi-Region Eventual Consistency) ed elevata consistenza multi-Regione (MRSC, Multi-Region Strong Consistency), introdotta nel giugno 2025.

Se non si specifica una modalità di coerenza durante la creazione di una tabella globale, la tabella globale per impostazione predefinita è MREC. Una tabella globale non può contenere repliche configurate con modalità di coerenza diverse. Non è possibile modificare la modalità di coerenza di una tabella globale dopo la sua creazione.

Aspetti chiave della MREC

  • Anche le tabelle globali che utilizzano la MRSC impiegano un modello di replica attivo-attivo. Dal punto di vista di DynamoDB, la tabella in ogni regione può accettare richieste di lettura e scrittura. Dopo aver ricevuto una richiesta di scrittura, la tabella di replica locale replicherà l’operazione di scrittura in altre Regioni remote partecipanti in background.

  • Gli elementi vengono replicati singolarmente. Gli elementi aggiornati all’interno di una singola transazione potrebbero non venire replicati congiuntamente.

  • Ogni partizione di tabella nella Regione di origine replica le proprie operazioni di scrittura in parallelo con ogni altra partizione. La sequenza delle operazioni di scrittura all’interno della Regione remota potrebbe non corrispondere alla sequenza delle operazioni di scrittura eseguite all’interno della Regione di origine. Per ulteriori informazioni sulle partizioni delle tabelle, consulta il post del blog relativo al dimensionamento di DynamoDB e all'impatto sulle prestazioni di partizioni, tasti di scelta rapida e isolamento.

  • Un elemento appena scritto viene in genere propagato a tutte le tabelle di replica entro un secondo. La propagazione nelle regioni vicine è in genere più veloce.

  • Amazon CloudWatch fornisce una ReplicationLatency metrica per ogni coppia di regioni. Viene calcolata in base all’analisi degli elementi in arrivo e al confronto tra la relativa ora di arrivo e il tempo di scrittura iniziale. Viene infine calcolata una media. Le tempistiche sono memorizzate CloudWatch nella regione di origine. L’analisi dei tempi medi e massimi può essere utile a determinare il ritardo di replica medio e peggiore. Non esiste alcun Accordo sul livello di servizio (SLA) per questa latenza.

  • Se un singolo elemento viene aggiornato all’incirca nello stesso momento (all’interno della finestra ReplicationLatency) in due Regioni diverse e la seconda operazione di scrittura avviene prima della replica della prima operazione di scrittura, è possibile che si verifichino conflitti di scrittura. Le tabelle globali che utilizzano la MREC risolvono tali conflitti utilizzando un meccanismo basato sulla priorità dell’ultima istanza di scrittura, ovvero sul timestamp delle operazione di scrittura. La prima operazione “perde” rispetto alla seconda operazione. Questi conflitti non vengono registrati in CloudWatch o AWS CloudTrail.

  • Il timestamp dell'ultima scrittura viene conservato come proprietà di sistema privata di ciascun elemento. L’approccio basato sulla priorità dell’ultima istanza viene implementato utilizzando un’operazione di scrittura condizionale che richiede che il timestamp dell’elemento in arrivo sia maggiore (cronologicamente successivo) del timestamp dell’elemento esistente.

  • Una tabella globale replica tutti gli elementi in tutte le Regioni partecipanti. Per avere ambiti di replica diversi, è possibile creare più tabelle globali e assegnare a ciascuna di esse diverse Regioni partecipanti.

  • La Regione locale accetta operazioni di scrittura anche se la Regione di replica è offline o se ReplicationLatency aumenta. La tabella locale continua a tentare di replicare gli elementi nella tabella remota finché la replica di ogni elemento non ha esito positivo.

  • Nell’improbabile eventualità che una Regione risulti offline, quando in seguito torna online per tutte le repliche in uscita e in entrata in sospeso verranno effettuate ripetizioni di tentativi. Non è richiesta alcuna azione speciale per ripristinare la sincronizzazione delle tabelle. Il meccanismo basato sulla priorità dell’ultima istanza di scrittura garantisce la coerenza finale dei dati.

  • È possibile aggiungere una nuova Regione a una tabella MREC DynamoDB in qualsiasi momento. DynamoDB gestisce la sincronizzazione iniziale e la replica continua. È possibile anche rimuovere una Regione (anche la Regione originale), e questo eliminerà la tabella locale in quella Regione.

Aspetti chiave della MRSC

  • Anche le tabelle globali che utilizzano la MRSC impiegano un modello di replica attivo-attivo. Dal punto di vista di DynamoDB, la tabella in ogni regione può accettare richieste di lettura e scrittura. Le modifiche agli elementi in una replica di tabella globale MRSC vengono replicate in modo sincrono in almeno un’altra Regione prima che l’operazione di scrittura restituisca una risposta con esito positivo.

  • Le operazioni a elevata consistenza di lettura su qualsiasi replica MRSC restituiscono sempre la versione più recente di un elemento. Le operazioni di scrittura condizionale valutano sempre l’espressione della condizione rispetto alla versione più recente di un elemento. Gli aggiornamenti funzionano sempre sulla base della versione più recente di un elemento.

  • Le operazioni di lettura a coerenza finale su una replica MRSC potrebbero non includere le modifiche apportate di recente in un’altra Regione e potrebbero non includere nemmeno le modifiche avvenute di recente nella stessa Regione.

  • Un’operazione di scrittura ha esito negativo con un’eccezione ReplicatedWriteConflictException quando tenta di modificare un elemento che è già stato modificato in un’altra Regione. Per le operazioni di scrittura che hanno esito negativo con l’eccezione ReplicatedWriteConflictException è possibile effettuare ripetizioni di tentativi. Queste avranno esito positivo se l’elemento non viene più modificato in un’altra Regione.

  • Con MRSC, le latenze sono più elevate per le operazioni di scrittura e per le operazioni a elevata consistenza di lettura. Queste operazioni richiedono una comunicazione multi-Regione. Questa comunicazione può aggiungere una latenza che aumenta in base alla latenza del round trip tra la Regione a cui si accede e la Regione più vicina che partecipa alla tabella globale. Per ulteriori informazioni, consulta la presentazione di AWS re:Invent 2024, Forte coerenza multiregionale con le tabelle globali DynamoDB. Le operazioni di lettura a coerenza finale non comportano alcuna latenza aggiuntiva. Esiste uno strumento di test open source che consente di calcolare sperimentalmente queste latenze con le proprie Regioni.

  • Gli elementi vengono replicati singolarmente. Le tabelle globali che utilizzano MRSC non supportano la transazione. APIs

  • Una tabella globale MRSC deve essere implementata esattamente in tre Regioni. È possibile configurare una tabella globale MRSC con tre repliche o con due repliche e un testimone. Un testimone è un componente di una tabella globale MRSC che contiene dati recenti scritti su repliche di tabelle globali. Un testimone fornisce un’alternativa opzionale a una replica completa, supportando al contempo l’architettura di disponibilità di MRSC. Non è possibile eseguire operazioni di lettura o scrittura su un testimone. Un testimone non sostiene costi di archiviazione o scrittura. Un testimone si trova in una Regione diversa dalle due repliche.

  • Per creare una tabella globale MRSC, si aggiungono una replica e un testimone oppure si aggiungono due repliche a una tabella DynamoDB esistente che non contiene dati. Non è possibile aggiungere repliche aggiuntive a una tabella globale MRSC esistente. Non è possibile eliminare una singola replica o un testimone da una tabella globale MRSC. È possibile eliminare due repliche o eliminare una replica e un testimone da una tabella globale MRSC. Il secondo scenario converte la replica rimanente in una tabella DynamoDB a Regione singola.

  • È possibile determinare se una tabella globale MRSC ha un testimone configurato e in quale regione è configurato, dall'output dell' DescribeTable API. Il testimone è di proprietà e gestito da DynamoDB e non appare nella regione in cui è Account AWS configurato.

  • Le tabelle globali MRSC sono disponibili nei seguenti set di Regioni:

    • Set della Regione degli Stati Uniti: Stati Uniti orientali (Virginia settentrionale), Stati Uniti orientali (Ohio), Stati Uniti occidentali (Oregon)

    • Set della Regione Europa: Europa (Irlanda), Europa (Londra), Europa (Parigi), Europa (Francoforte)

    • Set della Regione Asia Pacifico: Asia Pacifico (Tokyo), Asia Pacifico (Seoul) e Asia Pacifico (Osaka)

  • Le tabelle globali MRSC non possono estendersi su set di Regioni. Ad esempio, una tabella globale MRSC non può contenere repliche di set di Regioni degli Stati Uniti e dell’UE.

  • Il valore Time to Live (TTL) non è supportato per le tabelle globali MRSC.

  • Gli indici secondari locali (LSIs) non sono supportati per le tabelle globali MRSC.

  • CloudWatch Le informazioni di Contributor Insights vengono riportate solo per la regione in cui si è verificata un'operazione.

  • La Regione locale accetta tutte le operazioni di lettura e scrittura purché esista una seconda Regione che ospita una replica o un testimone per stabilire il quorum. Se una seconda Regione non è disponibile, la Regione locale può fornire solo letture a coerenza finale.

  • Nel caso improbabile che una Regione vada completamente offline, quando tornerà online si aggiornerà automaticamente. Fino a quando non verranno recuperate, le operazioni di scrittura e le operazioni di lettura fortemente coerenti solo nella regione che sta recuperando restituiranno errori, mentre le richieste verso le altre regioni continueranno a funzionare normalmente. Alla fine, operazioni di lettura coerenti nella regione di recupero restituiranno i dati che finora sono stati propagati nella regione, con il consueto comportamento di coerenza locale tra il nodo leader e le repliche locali. Non è richiesta alcuna azione speciale per ripristinare la sincronizzazione delle tabelle.

Casi d’uso delle tabelle globali MREC DynamoDB

Le tabelle globali MREC sono caratterizzate dai seguenti vantaggi comuni:

  • Operazioni di lettura a bassa latenza. Posiziona una copia dei dati più vicino all’utente finale per ridurre la latenza di rete durante le operazioni di lettura. L’aggiornamento dei dati è in linea con l’aggiornamento del valore ReplicationLatency.

  • Operazioni di scrittura a bassa latenza. È possibile scrivere in una regione vicina per ridurre la latenza di rete e il tempo impiegato per eseguire la scrittura. Il traffico di scrittura deve essere instradato con attenzione per garantire l'assenza di conflitti. Le tecniche di routing sono descritte in dettaglio in Strategie di instradamento in DynamoDB.

  • Migrazione regionale senza interruzioni. È possibile aggiungere una nuova Regione ed eliminare quella vecchia per eseguire la migrazione di un’implementazione da una Regione all’altra senza tempi di inattività a livello di dati.

Le tabelle globali MREC e MRSC offrono entrambe questo vantaggio:

  • Resilienza e ripristino di emergenza migliorati. Se una Regione presenta prestazioni ridotte o un’interruzione totale, è possibile evacuarla. Evacuare significa spostare alcune o tutte le richieste destinate a quella Regione. L’utilizzo delle tabelle globali aumenta la disponibilità dello SLA di DynamoDB per il tempo di attività mensile dal 99,99% al 99,999%. L’utilizzo della MREC supporta un Obiettivo del punto di ripristino (RPO) e un Obiettivo del tempo di ripristino (RTO) misurati in secondi. L’utilizzo della MRSC supporta un RPO pari a zero.

    Ad esempio, Fidelity Investments ha presentato a re:Invent 2022 la modalità di utilizzo delle tabelle globali DynamoDB per il proprio sistema di gestione degli ordini. L’obiettivo era ottenere un’elaborazione affidabile a bassa latenza su una scala che non sarebbe possibile raggiungere con l’elaborazione on-premises, mantenendo al contempo la resilienza ai guasti nelle zone di disponibilità e nelle aree di disponibilità.

Se l’obiettivo è la resilienza e il disaster recovery, le tabelle MRSC hanno latenze di scrittura superiori e latenze per le operazioni a elevata consistenza di lettura più elevate, ma supportano un RPO pari a zero. Le tabelle globali MREC supportano un RPO pari al ritardo di replica tra le repliche, in genere di pochi secondi a seconda delle Regioni di replica.

Conclusioni e risorse

Le tabelle globali DynamoDB hanno pochissimi controlli ma richiedono comunque un’attenta considerazione. È necessario determinare la modalità di scrittura, il modello di instradamento e i processi di evacuazione. È necessario dotare l'applicazione della strumentazione necessaria in ogni regione ed essere pronti a modificare l'instradamento o eseguire un'evacuazione per salvaguardare l'integrità globale. Il vantaggio è avere un set di dati distribuito a livello globale con operazioni di lettura e scrittura a bassa latenza progettato per una disponibilità del 99,999%.

Per ulteriori informazioni sulle tabelle globali DynamoDB, consulta le seguenti risorse: