Dal paper Dynamo a DynamoDB

Il paper "Dynamo: Amazon's Highly Available Key-value Store" del 2007 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 la maggior parte del macchinario.

DynamoDB si basa sul paper Dynamo?

In parte. DynamoDB prende il nome e gli obiettivi di fondo — prestazioni prevedibili e alta disponibilità su qualsiasi scala — dal paper Amazon Dynamo del 2007, e ha mantenuto quasi alla lettera l'idea dell'hashing della partition key. Ma è un sistema diverso e gestito: i vector clock, la membership a gossip e i quorum di lettura/scrittura regolabili del paper non ci sono più, sostituiti da internals 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 festivo, anche a costo di restituire una lettura stantia.
• DynamoDB ha mantenuto la forma, sostituito gli internals. Partizionato per un hash della chiave, replicato tra le AZ, scalato orizzontalmente — ma le viscere di risoluzione dei conflitti (vector clock, gossip, read-repair) non ci sono più.
• Non regoli più le manopole. N, R e W del paper sono diventati una sola scelta: ConsistentRead true o false. AWS possiede il resto.
• Il modello mentale ripaga comunque. Conoscere la discendenza spiega perché uno Scan è costoso e perché una lettura su un GSI può essere in ritardo — entrambi cadono dal design originale.

Cosa stava davvero risolvendo il paper

Il carrello di Amazon non poteva andare giù. Un database relazionale che rifiutava scritture sotto carico — o si bloccava su una replica fallita — era inaccettabile. Il paper Dynamo del 2007 scelse la disponibilità rispetto alla coerenza: accetta sempre la scrittura, riconcilia i disaccordi dopo. Quello scambio è 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 posizionava ogni nodo su un anello di hash. La posizione di una chiave è l'hash della sua 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. È il consistent hashing, ed è l'unica idea che DynamoDB ha mantenuto quasi alla lettera.

DynamoDB fa ancora l'hash della tua partition key per decidere quale partizione fisica memorizza l'item. Scegli una partition key a bassa cardinalità — diciamo STATUS con due valori — e ogni item con lo stesso valore finisce nella stessa partizione. È 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 riesce una volta che W di esse confermano, e una lettura consulta R di esse. Imposta R + W > N e qualsiasi lettura si sovrappone ad almeno un nodo che contiene la scrittura più recente — coerenza forte. Impostali più bassi e scambi freschezza per velocità e uptime.

Dynamo eseguiva quorum "sloppy": se un nodo target era giù, la scrittura andava a un sostituto e veniva riconsegnata dopo (hinted handoff). Le versioni in conflitto venivano etichettate 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 operare.

L'API del paper era due chiamate: get(key) e put(key, value). DynamoDB ha aggiunto una sort key, gli index e le query in cima allo stesso core 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 oggi

Il flusso qui sotto mette a confronto la scrittura a quorum del paper con 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 la discendenza trapela nel tuo codice

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

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

L'unica cosa da ricordare

Il paper ottimizzava per non dire mai di 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 nel single-table design, e ricorri a uno Scan solo quando devi davvero — l'anello rende una scansione completa della tabella costosa quanto sembra.

Prova DynoTable per ispezionare le tue partizioni, eseguire letture coerenti su richiesta e guardare un GSI recuperare sulle tue tabelle.