De l'article Dynamo à DynamoDB

L'article de 2007 « Dynamo : Amazon's Highly Available Key-value Store » et le DynamoDB que tu appelles aujourd'hui partagent un nom et un objectif — des performances prévisibles à n'importe quelle échelle — mais ce ne sont pas le même système. L'article décrivait un magasin interne, à cohérence à terme, que tu exploitais toi-même. DynamoDB est un service géré qui a gardé les leçons et jeté la majeure partie de la machinerie.

DynamoDB est-il basé sur l'article Dynamo ?

En partie. DynamoDB tire son nom et ses objectifs fondamentaux — des performances prévisibles et une haute disponibilité à l'échelle — de l'article Dynamo d'Amazon de 2007, et il a gardé presque à l'identique l'idée du hachage de la clé de partition. Mais c'est un système différent et géré : les horloges vectorielles de l'article, l'appartenance par gossip et les quorums de lecture/écriture ajustables ont disparu, remplacés par des internes détenus par AWS.

• L'article résolvait la disponibilité, pas l'ergonomie. Son job était de ne jamais refuser une écriture pendant un pic de trafic des fêtes, même au prix d'une lecture périmée.
• DynamoDB a gardé la forme, remplacé les internes. Partitionné par un hachage de la clé, répliqué entre AZ, mis à l'échelle horizontalement — mais les tripes de résolution de conflit (horloges vectorielles, gossip, réparation à la lecture) ont disparu.
• Tu ne règles plus les boutons. N, R et W de l'article sont devenus un seul choix : ConsistentRead vrai ou faux. AWS possède le reste.
• Le modèle mental paie toujours. Connaître la lignée explique pourquoi un Scan est cher et pourquoi une lecture de GSI peut être en retard — les deux découlent de la conception d'origine.

Ce que l'article résolvait vraiment

Le panier d'achat d'Amazon ne pouvait pas tomber. Une base de données relationnelle qui refusait des écritures sous charge — ou se bloquait sur un réplica défaillant — était inacceptable. L'article Dynamo de 2007 a choisi la disponibilité plutôt que la cohérence : toujours accepter l'écriture, réconcilier les désaccords plus tard. Ce compromis est la racine de tout ce qui suit.

Pour faire ça sans maître unique, Dynamo devait répondre seul à deux questions : où vit une clé, et combien de copies doivent être d'accord avant qu'une lecture ou une écriture ne compte ?

Hachage cohérent : où vit une clé

L'article plaçait chaque nœud sur un anneau de hachage. La position d'une clé est le hachage de sa clé ; elle est détenue par le nœud suivant dans le sens horaire, et répliquée sur les N-1 nœuds suivants. Ajouter ou retirer un nœud ne redistribue que les clés de ses voisins — pas tout le jeu de données. C'est le hachage cohérent, et c'est l'unique idée que DynamoDB a gardée presque à l'identique.

DynamoDB hache toujours ta clé de partition pour décider quelle partition physique stocke l'élément. Choisis une clé de partition à faible cardinalité — disons STATUS avec deux valeurs — et chaque élément de même valeur atterrit dans la même partition. C'est le footgun de la partition à chaud, et c'est une conséquence directe de l'anneau : le hachage envoie des clés identiques vers des foyers identiques.

Quorum : combien de copies doivent être d'accord

Le second bouton de l'article était un quorum. Avec N réplicas, une écriture réussit une fois que W d'entre eux l'acquittent, et une lecture consulte R d'entre eux. Fixe R + W > N et toute lecture recoupe au moins un nœud détenant l'écriture la plus récente — forte cohérence. Fixe-les plus bas et tu échanges la fraîcheur contre de la vitesse et de la disponibilité.

Dynamo faisait des quorums « laxistes » : si un nœud cible était en panne, l'écriture allait vers un remplaçant et lui était rendue plus tard (hinted handoff). Les versions en conflit étaient étiquetées avec des horloges vectorielles et réconciliées par l'application à la lecture.

Ce que DynamoDB a gardé versus changé

DynamoDB a hérité des objectifs et du partitionnement, puis a supprimé les parties qui rendaient l'original difficile à exploiter.

L'API de l'article se résumait à deux appels : get(key) et put(key, value). DynamoDB a ajouté une clé de tri, des index et des requêtes par-dessus le même cœur clé-valeur — ce qui explique pourquoi un Query est bon marché (une partition) et un Scan non (il parcourt chaque partition que l'anneau a jamais créée).

Comment une écriture voyage, hier et aujourd'hui

Le flux ci-dessous oppose l'écriture par quorum de l'article à l'écriture gérée de DynamoDB. La forme rime ; la responsabilité s'est déplacée de ton code vers AWS.

Dans l'article, tu possédais le calcul du quorum et la fusion ; dans DynamoDB, toute cette moitié inférieure est gérée, et tu ne choisis que ConsistentRead par requête.

Où la lignée fuit dans ton code

Le défaut de cohérence à terme est l'article qui transparaît. Un index secondaire global est répliqué de façon asynchrone, donc un élément fraîchement écrit peut manquer de l'index un instant — le même marché « réconcilier plus tard », juste à la couche de l'index. Voir GSI vs LSI pour savoir quand ce retard compte.

Tu rachètes de la forte cohérence de deux manières. Utilise ConsistentRead: true sur une lecture de table de base (elle route vers la copie leader), ou protège une écriture avec une ConditionExpression pour qu'elle n'atterrisse que si l'état actuel de l'élément correspond. Esquisse-en une dans le DynamoDB expression builder — par exemple attribute_not_exists(PK) pour faire d'un PutItem une opération d'insertion uniquement, le remplaçant moderne de la détection de conflit de l'article.

La seule chose à retenir

L'article optimisait pour ne jamais dire non à une écriture. DynamoDB a hérité de ce biais, d'où le fait que ses défauts favorisent la disponibilité et que les lectures fortes coûtent plus cher. Modélise tes clés pour des Query mono-partition, comme dans single-table design, et ne sors un Scan que lorsque tu le dois vraiment — l'anneau rend un parcours de table complète aussi cher qu'il en a l'air.

Essaie DynoTable pour parcourir tes tables et leurs GSI, puis lancer des JOIN et des GROUP BY sur tes propres données dans le SQL Workbench.