DynamoDB Global Tables

Una global table è una singola tabella DynamoDB replicata su più region AWS, dove ogni replica è scrivibile. DynamoDB le mantiene sincronizzate automaticamente — ottieni letture e scritture locali a bassa latenza in ogni region più disaster recovery cross-region, senza gestire una tua replica.

Nello scenario dell'audit log, un cliente UE richiede che i suoi dati risiedano in eu-west-1, mentre il resto gira in us-east-1. E in quanto log critico per la compliance, deve sopravvivere a un'interruzione regionale completa. Una global table risponde a entrambi con una sola feature.

Cosa sono le DynamoDB Global Tables?

Le DynamoDB Global Tables sono una singola tabella replicata su più region AWS, dove ogni replica è leggibile e scrivibile. DynamoDB le sincronizza automaticamente tramite replica asincrona con coerenza finale, risolvendo i conflitti con il criterio last-writer-wins. Ottieni letture e scritture locali a bassa latenza per ogni region più disaster recovery cross-region, a sostegno dello SLA di disponibilità del 99,999% di DynamoDB.

• Multi-region, active-active. Ogni replica è completamente leggibile e scrivibile; le scritture in qualsiasi region si propagano alle altre.
• La replica è asincrona ed eventualmente coerente tra le region — di solito entro un secondo, ma non istantanea.
• I conflitti si risolvono last-writer-wins. Scritture concorrenti sullo stesso Item in due region si riconciliano sulla più recente.
• Sostiene lo SLA di disponibilità del 99,999% — una global table multi-region è la configurazione a più alta disponibilità di DynamoDB.

Il problema: una sola region non basta

Una tabella single-region ha due limiti che l'audit log non può accettare. Primo, la residenza dei dati: gli eventi di un cliente UE devono essere memorizzati in UE, ma la tua app gira negli USA. Secondo, il disaster recovery: se us-east-1 ha un'interruzione, un audit log single-region è illeggibile e non scrivibile per tutta la durata — esattamente quando hai più bisogno del record di cosa è successo.

Costruire l'uno o l'altro da solo — replica cross-region, failover, gestione dei conflitti — è un progetto grande e soggetto a errori. Le global tables lo rendono una scelta di configurazione.

Come funzionano le global tables

Aggiungi una region replica alla tabella; DynamoDB crea lì una copia e mantiene tutte le repliche sincronizzate. Secondo le FAQ AWS DynamoDB, le global tables forniscono replica multi-region con fino al 99,999% di disponibilità, e la replica di ogni region serve letture e scritture locali.

Due regole di consistenza definiscono il comportamento:

• La replica cross-region è asincrona. Una scrittura in us-east-1 viene confermata localmente, poi propagata a eu-west-1 — di solito entro un secondo, ma una lettura nell'altra region subito dopo una scrittura potrebbe non vederla ancora. (Le letture fortemente coerenti funzionano comunque, ma solo dentro una singola region.)
• I conflitti sono last-writer-wins. Se lo stesso Item viene scritto in due region quasi nello stesso momento, DynamoDB tiene la scrittura con il timestamp più recente e scarta l'altra.

Un esempio pratico: una replica UE che è anche DR

Aggiungi eu-west-1 come replica della tabella audit-log. Ora:

L'app del cliente UE scrive e legge dalla replica locale eu-west-1 — bassa latenza e dati residenti in-region. La stessa replica che soddisfa la residenza fa anche da disaster recovery: se us-east-1 va giù, la replica eu-west-1 conserva ancora il log completo e serve il traffico; fai failover su di essa.

Poiché l'audit log è append-only e partizionato per tenant, il last-writer-wins è sostanzialmente un non-problema qui — gli eventi di un dato tenant sono scritti da una sola region e le chiavi degli eventi sono univoche, quindi due region raramente fanno race sullo stesso Item. Non è fortuna; è il motivo per cui un log append-only è uno degli abbinamenti più puliti per le global tables. Un counter mutabile, al contrario, richiederebbe cura sotto scritture cross-region concorrenti.

Fallo in DynoTable

Dopo aver aggiunto una replica vuoi confermare che i dati siano davvero atterrati nella nuova region e corrispondano alla sorgente — che la replica UE contenga davvero gli eventi di acme, con gli attributi giusti, e non sia in ritardo.

DynoTable si connette a qualsiasi region con le sue credenziali, così puoi puntare una finestra a us-east-1 e un'altra a eu-west-1 e confrontare gli Item dello stesso tenant fianco a fianco per verificare la replica.

Puoi prototipare le Query per-region che eseguirai contro ogni replica nel DynamoDB Expression Builder.

Trappole e prossimi passi

• Non fare read-your-own-write tra region. Il lag di replica significa che una scrittura in una region potrebbe non comparire in un'altra per ~un secondo. Non scrivere negli USA per poi leggere subito dalla UE aspettandoti il dato; la coerenza forte è solo single-region.
• Il last-writer-wins scarta dati silenziosamente. Per Item mutabili scritti in modo concorrente in due region, il perdente viene scartato senza errore. Design append-only o single-writer-per-Item (come questo audit log) evitano il problema; uno stato mutabile condiviso richiede un design consapevole dei conflitti.
• Ogni replica costa. Ogni region memorizza una copia completa e fattura la propria capacità e storage — una replica più o meno raddoppia il costo. Aggiungi region per una reale esigenza di residenza o DR, non di default.
• I backup sono per-replica. Una global table ripristinata diventa una tabella indipendente — pianifica il recovery per region. Vedi backup e point-in-time recovery.

Le global tables proteggono dalla perdita di una region. L'ultima preoccupazione operativa è proteggersi dalla perdita dei dati — un deploy sbagliato o una cancellazione accidentale — con backup e point-in-time recovery.

Scarica DynoTable per connetterti a più region e verificare che le tue repliche global-table contengano gli stessi dati.