Dal paper Dynamo a DynamoDB

Il paper del 2007 "Dynamo: Amazon's Highly Available Key-value Store" e il DynamoDB che chiami oggi condividono un nome e un obiettivo — prestazioni prevedibili a qualsiasi scala — ma non sono lo stesso sistema. Il paper descriveva uno store interno, eventualmente coerente, che gestivi tu stesso. DynamoDB è un servizio gestito che ha mantenuto le lezioni e buttato via gran parte del macchinario.

DynamoDB si basa sul paper Dynamo?

In parte. DynamoDB prende il nome e gli obiettivi fondamentali — prestazioni prevedibili e alta disponibilità su scala — dal paper Amazon Dynamo del 2007, e ha mantenuto quasi alla lettera l'idea dell'hashing della chiave di partizione. Ma è un sistema diverso e gestito: i vector clock, la membership via gossip e i quorum di lettura/scrittura regolabili del paper sono spariti, sostituiti da meccanismi interni di proprietà di AWS.

• Il paper risolveva la disponibilità, non l'ergonomia. Il suo compito era non rifiutare mai una scrittura durante un picco di traffico natalizio, anche al costo di restituire una lettura stantia.
• DynamoDB ha mantenuto la forma, sostituito i meccanismi interni. Partizionato tramite un hash della chiave, replicato tra AZ, scalato orizzontalmente — ma le viscere della risoluzione dei conflitti (vector clock, gossip, read-repair) sono sparite.
• Non regoli più le manopole. N, R e W del paper sono diventati un'unica scelta: ConsistentRead true o false. AWS possiede il resto.
• Il modello mentale rende comunque. Conoscere il lignaggio spiega perché uno Scan è costoso e perché una lettura da GSI può ritardare — entrambe discendono dal design originale.

Cosa stava davvero risolvendo il paper

Il carrello della spesa di Amazon non poteva andare giù. Un database relazionale che rifiutava scritture sotto carico — o si bloccava su una replica guasta — era inaccettabile. Il paper Dynamo del 2007 scelse la disponibilità rispetto alla coerenza: accetta sempre la scrittura, riconcilia i disaccordi dopo. Quel compromesso è la radice di tutto ciò che segue.

Per farlo senza un singolo master, Dynamo doveva rispondere a due domande da solo: dove vive una chiave, e quante copie devono concordare prima che una lettura o una scrittura conti?

Consistent hashing: dove vive una chiave

Il paper collocava ogni nodo su un anello di hash. La posizione di una chiave è l'hash della chiave; è posseduta dal nodo successivo in senso orario, e replicata ai successivi N-1 nodi. Aggiungere o rimuovere un nodo rimescola solo le chiavi dei suoi vicini — non l'intero dataset. Questo è il consistent hashing, ed è l'unica idea che DynamoDB ha mantenuto quasi alla lettera.

DynamoDB continua a fare l'hash della tua chiave di partizione per decidere quale partizione fisica memorizza l'Item. Scegli una chiave di partizione a bassa cardinalità — diciamo STATUS con due valori — e ogni Item con lo stesso valore finisce nella stessa partizione. Questo è il footgun della hot partition, ed è una conseguenza diretta dell'anello: l'hash manda chiavi identiche a case identiche.

Quorum: quante copie devono concordare

La seconda manopola del paper era un quorum. Con N repliche, una scrittura ha successo una volta che W di esse danno l'ack, e una lettura consulta R di esse. Imposta R + W > N e ogni lettura si sovrappone ad almeno un nodo che detiene la scrittura più recente — coerenza forte. Impostali più bassi e barati freschezza per velocità e uptime.

Dynamo eseguiva quorum "sloppy": se un nodo target era giù, la scrittura andava a un sostituto e veniva restituita più tardi (hinted handoff). Le versioni in conflitto venivano marcate con vector clock e riconciliate dall'applicazione in lettura.

Cosa DynamoDB ha mantenuto rispetto a cosa ha cambiato

DynamoDB ha ereditato gli obiettivi e il partizionamento, poi ha cancellato le parti che rendevano l'originale difficile da gestire.

L'API del paper erano due chiamate: get(key) e put(key, value). DynamoDB ha aggiunto una chiave di ordinamento, indici e query sopra lo stesso nucleo key-value — ed è per questo che una Query è economica (una partizione) e uno Scan no (percorre ogni partizione che l'anello abbia mai creato).

Come viaggia una scrittura, allora e ora

Il flusso qui sotto contrappone la scrittura a quorum del paper a quella gestita di DynamoDB. La forma fa rima; la responsabilità si è spostata dal tuo codice ad AWS.

Nel paper possedevi la matematica del quorum e il merge; in DynamoDB tutta quella metà inferiore è gestita, e scegli solo ConsistentRead per richiesta.

Dove il lignaggio trapela nel tuo codice

Il default della coerenza eventuale è il paper che traspare. Un indice secondario globale viene replicato in modo asincrono, quindi un Item appena scritto può mancare dall'indice per un momento — lo stesso patto "riconcilia dopo", solo a livello di indice. Vedi GSI vs LSI per quando quel ritardo conta.

Ricompri la coerenza forte in due modi. Usa ConsistentRead: true su una lettura della tabella di base (instrada alla copia leader), oppure proteggi una scrittura con una ConditionExpression così che vada a buon fine solo se lo stato corrente dell'Item corrisponde. Abbozzane una nel DynamoDB expression builder — ad esempio attribute_not_exists(PK) per rendere un PutItem un'operazione di solo inserimento, il sostituto moderno della rilevazione dei conflitti del paper.

L'unica cosa da ricordare

Il paper ottimizzava per non dire mai no a una scrittura. DynamoDB ha ereditato quella tendenza, ed è per questo che i suoi default favoriscono la disponibilità e perché le letture forti costano di più. Modella le tue chiavi per Query su singola partizione, come in single-table design, e affidati a uno Scan solo quando devi davvero — l'anello rende un percorso completo della tabella costoso quanto sembra.

Prova DynoTable per sfogliare le tue tabelle e i loro GSI, poi esegui JOIN e GROUP BY sui tuoi dati nel SQL Workbench.