Letture a coerenza forte vs eventuale in DynamoDB

Aggiorni un item, lo rileggi subito e ottieni il vecchio valore. La scrittura è andata a buon fine — un istante dopo la stessa lettura restituisce il nuovo valore. Niente è rotto: hai colpito la lettura eventualmente coerente predefinita di DynamoDB, e puoi rinunciarvi per singola richiesta.

È una delle poche manopole di correttezza che DynamoDB ti mette direttamente in mano, e ha un prezzo concreto. Usarla bene significa sapere cosa garantisce ciascuna modalità, quanto costa e dove le letture forti semplicemente non sono disponibili.

Qual è la differenza tra letture a coerenza forte ed eventuale in DynamoDB?

Una lettura eventualmente coerente (il default) è servita da una replica qualsiasi, quindi subito dopo una scrittura può restituire brevemente dati obsoleti, ma costa la metà. Una lettura fortemente coerente, attivata per singola richiesta con ConsistentRead=true, viene instradata al leader della partizione e riflette sempre ogni scrittura committata — al 2× della capacità di lettura.

• Eventualmente coerente (il default) — subito dopo una scrittura può restituire brevemente dati obsoleti. È la modalità di lettura più economica.
• Fortemente coerente — riflette sempre ogni scrittura committata prima della lettura. Si attiva per richiesta con ConsistentRead=true.
• Le letture forti costano 2× quelle eventuali. Una lettura fortemente coerente consuma il doppio della capacità di lettura di una eventualmente coerente sugli stessi dati.
• Non ovunque. Ottieni letture forti sulla tabella base e su un Local Secondary Index. Una Global Secondary Index è solo eventuale — nessuna opt-in.
• Default all'eventuale. Ricorri al forte solo quando rileggi i dati che hai appena scritto e una manciata di millisecondi di obsolescenza sarebbe un errore.

Il problema: una lettura che non vede l'ultima scrittura

Diciamo che gestisci account utente. Un utente cambia la propria email di notifica, la tua app scrive l'aggiornamento e la schermata di conferma rilegge subito il profilo per mostrare il nuovo indirizzo. Con la modalità di lettura predefinita, quella rilettura può atterrare su una replica che non ha ancora ricevuto la modifica — così l'utente vede la sua vecchia email e pensa che il salvataggio sia fallito.

La finestra è piccola (tipicamente ben sotto il secondo) e si chiude da sola. Ma "di solito corretto" non basta per una conferma read-after-write. È esattamente il caso per cui esiste la coerenza forte.

Perché si verifica la coerenza eventuale

DynamoDB memorizza ogni partizione su tre nodi di storage — uno primario e due repliche — in Availability Zone separate. Una scrittura è riconosciuta quando atterra sul primario e su una replica; poi si propaga al terzo nodo in modo asincrono.

Le letture, per distribuire il carico, possono essere servite da uno qualsiasi dei tre nodi. Una lettura eventualmente coerente può colpire un nodo che non ha ancora ricevuto la tua scrittura più recente — quindi restituisce un valore leggermente obsoleto. Una lettura fortemente coerente viene instradata al leader della partizione, che detiene sempre i dati committati più recenti, quindi non restituisce mai risultati obsoleti.

Quel ritardo di replica è l'intera differenza. Spiega anche il costo 2×: le letture forti non possono essere bilanciate sulle repliche come quelle eventuali, quindi DynamoDB le tariffa al doppio della capacità.

Il costo, reso concreto

Le letture si misurano in Read Capacity Unit (RCU), ciascuna copre fino a 4 KB. Una RCU compra una lettura fortemente coerente o due letture eventualmente coerenti di un item da 4 KB. Quindi attivare ConsistentRead=true su un percorso di lettura caldo ne raddoppia il costo di lettura — su un endpoint ad alto traffico è una voce di costo che noterai.

Modella la differenza per le tue dimensioni di item e i tuoi tassi di richiesta con il calcolatore dei prezzi DynamoDB prima di rendere le letture forti il tuo default — raramente vale la pena pagare il doppio su tutta la linea.

Dove le letture forti sono (e non sono) disponibili

Una GSI mantiene una propria copia dei dati, replicata dalla tabella base in modo asincrono, quindi non può mai offrire una lettura forte. Se un access pattern ha davvero bisogno del read-after-write e pensavi di servirlo da una GSI, è un segnale per servirlo invece dalla tabella base o da una LSI.

Trappole e prossimi passi

• Non rendere le letture forti il default. La maggior parte delle letture tollera una finestra di obsolescenza sub-secondo; pagare 2× ovunque è spesa sprecata.
• Non aspettarti il read-after-write da una GSI. È eventuale per progetto — vedi perché una GSI è eventualmente coerente.
• Le transazioni leggono in modo forte. TransactGetItems è sempre fortemente coerente — vedi transazioni DynamoDB.
• La coerenza interagisce con la capacità. Il moltiplicatore 2× si lega direttamente alla pianificazione dei costi on-demand vs provisioned.

Vuoi esplorare le tue tabelle e i tuoi indici DynamoDB senza scrivere chiamate API? Scarica DynoTable e ispeziona i tuoi dati direttamente.