DynamoDB Letture fortemente o infine coerenti

Aggiorna un elemento, lo rileggi immediatamente e ottieni il vecchio valore. La scrittura riuscito: un attimo dopo la stessa lettura restituisce il nuovo valore. Niente è rotto: hai raggiunto la lettura predefinita coerenza eventuale di DynamoDB e puoi disattivarla su richiesta.

Questa è una delle poche manopole di correttezza che DynamoDB ti offre direttamente e ha un prezzo reale allegato. Farlo bene significa sapere cosa garantisce ciascuna modalità, cosa costa e dove le letture forti semplicemente non sono disponibili.

Qual è la differenza tra le letture forti e coerenza eventuale in DynamoDB?

Una lettura coerenza eventuale (l'impostazione predefinita) è servita da qualsiasi replica, quindi può restituire brevemente dati non aggiornati subito dopo una scrittura, ma costa la metà. Una lettura coerenza forte, attivata per richiesta con ConsistentRead=true, viene instradata al leader della partizione e riflette sempre ogni scrittura impegnata, al doppio della capacità di lettura.

Coerenza eventuale (predefinito): potrebbe restituire brevemente dati non aggiornati subito dopo una scrittura. Modalità di lettura più economica.
Coerenza forte: riflette sempre ogni scrittura eseguita prima della lettura. Attivazione per richiesta con ConsistentRead=true.
Le letture potenti costano eventualmente 2×. Una lettura coerenza forte consuma il doppio del capacità di lettura di un coerenza eventuale per gli stessi dati.
Non ovunque. Ottieni letture forti sulla tabella base e su Locale Secondario Indice. Un Global Secondary Indice è solo opzionale — senza attivazione.
Predefinito su eventuale. Raggiungi il forte solo quando leggi ciò che hai appena scritto i dati e i dati obsoleti per un momento sarebbero sbagliati.

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

Supponiamo che tu gestisca account utente. Un utente modifica la propria email di notifica, scrive la tua app l'aggiornamento e la schermata di conferma rilegge immediatamente il profilo per mostrare il nuovo indirizzo. Con la modalità di lettura predefinita, la rilettura può arrivare a una replica non ha ancora ricevuto la modifica, quindi l'utente vede la sua vecchia email e presume che salvataggio fallito.

La finestra è piccola (in genere meno di un secondo) e si chiude da sola. Ma "solitamente corretto" non è sufficiente per una conferma di lettura dopo scrittura. Questo è esattamente il caso per cui esiste una forte coerenza.

Perché si verifica la coerenza finale

DynamoDB archivia ogni partizione su tre nodi di storage: uno primario e due repliche: su zone di disponibilità separate. Una scrittura viene riconosciuta una volta atterrata sul primario e su una replica; quindi si propaga al terzo nodo in modo asincrono.

Le letture, per distribuire il carico, possono essere servite da qualsiasi dei tre nodi. Un eventualmente una lettura coerente potrebbe colpire un nodo che non ha ancora ricevuto la tua scrittura più recente, quindi è così restituisce un valore leggermente obsoleto. Una lettura coerenza forte viene instradata al leader per la partizione, che contiene sempre gli ultimi dati impegnati, quindi mai restituisce risultati obsoleti.

Quel ritardo di replica è l'intera differenza. Spiega anche il 2×costo: le letture efficaci non possono essere bilanciate nel carico tra le repliche come possono fare le letture finali, quindi DynamoDB li costa al doppio della capacità.

Il costo, reso concreto

Le letture vengono misurate in Unità di capacità di lettura (RCU), ciascuna delle quali copre fino a 4 KB. Un telecomando acquista una lettura coerenza forte o due letture coerenza eventuale di 4 KB elemento. Quindi, capovolgere ConsistentRead=true su un percorso di lettura caldo raddoppia il suo costo di lettura un endpoint ad alto traffico che è un elemento pubblicitario che noterai.

Modella la differenza per le dimensioni dei tuoi articoli e richiedi le tariffe con Calcolatore dei prezzi DynamoDB prima di effettuare strong legge il tuo valore predefinito: raramente vale la pena pagare due volte su tutta la linea.

Dove sono (e non sono) disponibili letture forti

Leggi contro	Coerenza forte?
Tavolo basso	Sì: attiva `ConsistentRead=true`
Secondario locale Indice (LSI)	Sì, stessa attivazione della tabella base
Secondario globale Indice (GSI)	No — solo eventuale, senza override

Un GSI mantiene la propria copia dei dati, replicati dalla tabella di base in modo asincrono, quindi non potrà mai offrire una lettura forte. Se un modello di accesso è autentico necessita di lettura dopo scrittura e avevi intenzione di servirlo da un GSI, questo è un segnale per servirlo invece dal tavolo base o da un LSI.

Insidie + passaggi successivi

Non impostare letture forti come impostazione predefinita. La maggior parte delle letture tollerano uno stallo inferiore al secondo finestra; pagare 2× ovunque è una spesa sprecata.
Non aspettarti la lettura dopo la scrittura da un GSI. È possibile in base alla progettazione: vedere perché un GSI è coerenza eventuale.
Le transazioni sono molto leggere. TransactGetItems è sempre coerenza forte — vedere Transazioni DynamoDB.
La coerenza interagisce con la capacità. Il moltiplicatore 2× si lega direttamente Pianificazione dei costi su richiesta o con provisioning.

Desideri esplorare le tabelle e gli indici DynamoDB senza scrivere chiamate API? Scarica DynoTable e controlla direttamente i tuoi dati.

Confronto RCU funzionante

Due letture dello stesso elemento da 6 KB sulla tabella di base:

Modalità	Blocchi da 4 KB	RCU consumato	Quando utilizzare
Coerenza forte	2 (6 KB arrotondati per eccesso)	2 RCU	Schermate di conferma dopo la tua scrittura
Coerenza eventuale	2	1 RCU	Cruscotti, elenchi, analisi

Con 1.000 letture di questo tipo al secondo, la modalità forte costa circa il doppio di quella on-demand leggi la spesa della modalità eventuale: modella il delta nel file calcolatore dei prezzi prima di lanciare un hot percorso verso ConsistentRead=true a livello globale.

Coerenza BatchGetItem

Ciascuna voce della tabella in BatchGetItem può impostare ConsistentRead in modo indipendente. A dashboard che carica un profilo utente (forte) e le relative impostazioni (eventi) can mescolare i flag in una chiamata batch, ancora soggetto alla lettura forte per tabella regole di disponibilità (non forte su GSI).

Lettura dopo scrittura nel codice dell'applicazione

Modello per la conferma dell'aggiornamento del profilo:

UpdateItem con nuova email.
GetItem immediato con ConsistentRead: true sul tavolo di base.

Lo step 2 costa 2× l'RCU di un'eventuale lettura ma garantisce la conferma lo schermo corrisponde alla scrittura. Salta letture forti sulle aggregazioni di sfondo che tollerare un ritardo inferiore al secondo.

Impostazioni predefinite DynoTable

Le letture esplorative in DynoTable utilizzano query sulla tabella base coerenza eventuale a meno che non si opti per una semantica più forte nelle impostazioni avanzate, che corrisponde alla maggior parte casi d'uso del dashboard. Dopo aver messo in scena una scrittura, viene visualizzato l'aggiornamento dell'editor degli elementi valori impegnati dalla risposta positiva senza una coerenza separata attivare/disattivare per il percorso comune.

Utilizzare il generatore di query per generare letture di esempio ConsistentRead impostato in modo esplicito durante la copia del codice SDK nei servizi che necessitano garanzie di lettura dopo scrittura.

Nota su Global Tables

Le Global Tables si replicano in modo asincrono tra le regioni. La coerenza forte si applica all'interno della replica di una regione, non a livello globale. Una scrittura in us-east-1 non lo è immediatamente leggibile in eu-west-1: pianifica di conseguenza l'UX tra regioni. Vedere tabelle globali per le aspettative sul ritardo di replica.