Vom Dynamo-Paper zu DynamoDB

Das Paper „Dynamo: Amazon's Highly Available Key-value Store" von 2007 und das DynamoDB, das du heute aufrufst, teilen einen Namen und ein Ziel — vorhersehbare Leistung in jeder Größenordnung — aber sie sind nicht dasselbe System. Das Paper beschrieb einen internen, letztendlich konsistenten Speicher, den du selbst betrieben hast. DynamoDB ist ein verwalteter Dienst, der die Lektionen behielt und die meiste Mechanik über Bord warf.

Basiert DynamoDB auf dem Dynamo-Paper?

Teilweise. DynamoDB übernimmt seinen Namen und seine Kernziele — vorhersehbare Leistung und hohe Verfügbarkeit in jeder Größenordnung — aus dem Amazon-Dynamo-Paper von 2007, und es behielt die Idee des Partition-Key-Hashings fast wortgetreu. Aber es ist ein anderes, verwaltetes System: Die Vector Clocks, die Gossip-Mitgliedschaft und die einstellbaren Lese-/Schreib-Quoren des Papers sind verschwunden, ersetzt durch AWS-eigene Interna.

• Das Paper löste Verfügbarkeit, nicht Ergonomie. Seine Aufgabe war es, während einer Feiertags-Traffic-Spitze niemals einen Schreibvorgang abzulehnen, selbst um den Preis, einen veralteten Lesevorgang zurückzugeben.
• DynamoDB behielt die Form, ersetzte die Interna. Partitioniert nach einem Hash des Schlüssels, über AZs repliziert, horizontal skaliert — aber die Konfliktauflösungs-Innereien (Vector Clocks, Gossip, Read-Repair) sind verschwunden.
• Du stellst die Knöpfe nicht mehr ein. N, R und W aus dem Paper wurden zu einer Wahl: ConsistentRead true oder false. AWS besitzt den Rest.
• Das mentale Modell zahlt sich weiterhin aus. Die Abstammung zu kennen erklärt, warum ein Scan teuer ist und warum ein GSI-Lesevorgang nachhinken kann — beides ergibt sich aus dem ursprünglichen Design.

Was das Paper eigentlich löste

Amazons Warenkorb durfte nicht ausfallen. Eine relationale Datenbank, die Schreibvorgänge unter Last ablehnte — oder bei einem ausgefallenen Replikat blockierte — war inakzeptabel. Das Dynamo-Paper von 2007 wählte Verfügbarkeit vor Konsistenz: den Schreibvorgang immer akzeptieren, Uneinigkeiten später abgleichen. Dieser Kompromiss ist die Wurzel von allem Folgenden.

Um das ohne einen einzelnen Master zu tun, musste Dynamo zwei Fragen selbst beantworten: wo lebt ein Schlüssel, und wie viele Kopien müssen sich einig sein, bevor ein Lese- oder Schreibvorgang zählt?

Consistent Hashing: wo ein Schlüssel lebt

Das Paper platzierte jeden Knoten auf einem Hash-Ring. Die Position eines Schlüssels ist der Hash seines Schlüssels; er gehört dem nächsten Knoten im Uhrzeigersinn und wird auf die folgenden N-1 Knoten repliziert. Einen Knoten hinzuzufügen oder zu entfernen ordnet nur die Schlüssel seiner Nachbarn neu — nicht den ganzen Datensatz. Das ist Consistent Hashing, und es ist die eine Idee, die DynamoDB fast wortgetreu behielt.

DynamoDB hasht immer noch deinen Partition Key, um zu entscheiden, welche physische Partition das Item speichert. Wähle einen Partition Key mit geringer Kardinalität — sagen wir STATUS mit zwei Werten — und jedes Item mit demselben Wert landet in derselben Partition. Das ist der Hot-Partition-Footgun, und es ist eine direkte Folge des Rings: Der Hash schickt identische Schlüssel an identische Heime.

Quorum: wie viele Kopien sich einig sein müssen

Der zweite Knopf des Papers war ein Quorum. Mit N Replikaten gelingt ein Schreibvorgang, sobald W von ihnen bestätigen, und ein Lesevorgang befragt R von ihnen. Setze R + W > N, und jeder Lesevorgang überschneidet sich mit mindestens einem Knoten, der den neuesten Schreibvorgang hält — starke Konsistenz. Setze sie niedriger und du tauschst Aktualität gegen Geschwindigkeit und Verfügbarkeit.

Dynamo betrieb „sloppy" Quoren: Wenn ein Zielknoten ausgefallen war, ging der Schreibvorgang an einen Stellvertreter und wurde später zurückgereicht (Hinted Handoff). Widersprüchliche Versionen wurden mit Vector Clocks getaggt und von der Anwendung beim Lesen abgeglichen.

Was DynamoDB behielt versus änderte

DynamoDB erbte die Ziele und die Partitionierung und löschte dann die Teile, die das Original schwer zu betreiben machten.

Die API des Papers waren zwei Aufrufe: get(key) und put(key, value). DynamoDB fügte einen Sort Key, Indizes und Queries auf demselben Key-Value-Kern hinzu — weshalb ein Query günstig ist (eine Partition) und ein Scan nicht (er läuft durch jede Partition, die der Ring je erzeugt hat).

Wie ein Schreibvorgang wandert, damals und heute

Der Ablauf unten stellt den Quorum-Schreibvorgang des Papers dem verwalteten von DynamoDB gegenüber. Die Form reimt sich; die Verantwortung wanderte von deinem Code zu AWS.

Im Paper besaßt du die Quorum-Mathematik und das Merge; in DynamoDB ist diese ganze untere Hälfte verwaltet, und du wählst nur ConsistentRead pro Anfrage.

Wo die Abstammung in deinen Code durchsickert

Der Standard der letztendlichen Konsistenz ist das Paper, das durchscheint. Ein Global Secondary Index wird asynchron repliziert, sodass ein frisch geschriebenes Item für einen Moment im Index fehlen kann — derselbe „später abgleichen"-Handel, nur auf der Index-Ebene. Siehe GSI vs. LSI, wann diese Verzögerung eine Rolle spielt.

Du kaufst starke Konsistenz auf zwei Wegen zurück. Nutze ConsistentRead: true bei einem Basistabellen-Lesevorgang (er wird zur Leader-Kopie geleitet), oder sichere einen Schreibvorgang mit einer ConditionExpression ab, sodass er nur landet, wenn der aktuelle Zustand des Items passt. Skizziere eine im DynamoDB Expression Builder — zum Beispiel attribute_not_exists(PK), um ein PutItem zu einer reinen Einfüge-Operation zu machen, dem modernen Ersatz für die Konflikterkennung des Papers.

Die eine Sache, die man sich merken sollte

Das Paper optimierte darauf, nie Nein zu einem Schreibvorgang zu sagen. DynamoDB erbte diese Voreingenommenheit, weshalb seine Standardeinstellungen Verfügbarkeit begünstigen und starke Lesevorgänge mehr kosten. Modelliere deine Schlüssel für Single-Partition-Querys, wie in Single-Table-Design, und greife nur dann zu einem Scan, wenn du wirklich musst — der Ring macht einen vollständigen Tabellendurchlauf so teuer, wie es klingt.

Probier DynoTable aus, um deine Tabellen und ihre GSIs zu durchsuchen und dann JOINs und GROUP BY über deine eigenen Daten in der SQL Workbench auszuführen.