DynamoDB : table, clés et lectures

À la fin de ce tutoriel, vous créerez une table DynamoDB avec partition key (et sort key), insererez des items, ferez des GetItem / Query / Scan, et comprendrez capacité on-demand vs provisioned — en ca-central-1.

Niveau : Débutant → Intermédiaire · Temps estimé : 50–60 min · Versions testées : DynamoDB 2026, AWS CLI v2 · Dernière vérification : 2026-09-10 · Region : ca-central-1

← Précédent : RDS · → Suivant : SNS/SQS · Hub : Démarrer avec AWS

Prérequis

• Profil lab, notions IAM
• Différence SQL (RDS) vs NoSQL clé-valeur / document

Coût estimé : on-demand sur quelques items ≈ cents. Supprimez la table en fin de lab. Évitez les Scan massifs en prod.

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1

Ce que nous allons construire

Table lab-orders
├── PK: pk (S)        ex. USER#42
├── SK: sk (S)        ex. ORDER#1001
├── Attributs: total, status
└── Billing: PAY_PER_REQUEST

(Schéma — alt : « Table DynamoDB PK/SK et item order ».)

Étape 1 — Quand DynamoDB vs RDS

Besoin	Choix typique
Jointures complexes, SQL	RDS / Aurora
Accès clé connue, scale horizontal énorme	DynamoDB
Sessions, paniers, leaderboards	DynamoDB
Reporting ad-hoc	RDS / Redshift / Athena sur export

Modèle de données : dénormalisé, accès via patterns de clés — pas de JOIN.

Étape 2 — Clés de partition et de tri

• Partition key (PK) : détermine la partition ; haute cardinalité.
• Sort key (SK) optionnelle : ordonne / range query dans la partition.
• Composite USER#id + ORDER#id = pattern single-table fréquent.

Mauvaise PK (ex. status=PENDING pour tout) = hot partition.

Étape 3 — Créer la table (on-demand)

aws dynamodb create-table 
  --table-name lab-orders 
  --attribute-definitions 
    AttributeName=pk,AttributeType=S 
    AttributeName=sk,AttributeType=S 
  --key-schema 
    AttributeName=pk,KeyType=HASH 
    AttributeName=sk,KeyType=RANGE 
  --billing-mode PAY_PER_REQUEST 
  --tags Key=Name,Value=lab-orders

aws dynamodb wait table-exists --table-name lab-orders

Provisioned (RCU/WCU) : utile pour trafic prévisible + réservation ; on-demand pour labs et spiky.

Étape 4 — PutItem

aws dynamodb put-item --table-name lab-orders --item '{
  "pk": {"S": "USER#42"},
  "sk": {"S": "ORDER#1001"},
  "total": {"N": "49.90"},
  "status": {"S": "NEW"}
}'

aws dynamodb put-item --table-name lab-orders --item '{
  "pk": {"S": "USER#42"},
  "sk": {"S": "ORDER#1002"},
  "total": {"N": "12.00"},
  "status": {"S": "PAID"}
}'

Types courants : S string, N number (stocké en string JSON), BOOL, M map, L list.

Étape 5 — GetItem, Query, Scan

# Get exact
aws dynamodb get-item --table-name lab-orders 
  --key '{"pk":{"S":"USER#42"},"sk":{"S":"ORDER#1001"}}'

# Query tous les orders d'un user (efficace)
aws dynamodb query --table-name lab-orders 
  --key-condition-expression "pk = :pk" 
  --expression-attribute-values '{":pk":{"S":"USER#42"}}'

# Scan (évite en prod à grande échelle)
aws dynamodb scan --table-name lab-orders --limit 10

Query = PK obligatoire (+ SK optionnelle).
Scan = toute la table (coût + lenteur).

Étape 6 — GSI / LSI (aperçu certif)

Index	Quand
LSI	Même PK, autre SK ; créé avec la table ; share throughput
GSI	Autre PK/SK ; asynchrone ; billing séparé

Exemple : GSI status-index pour lister par status — mais attention cardinalité basse (NEW) = hot key.

Étape 7 — Cohérence et capacité

• Lecture eventually consistent (défaut) vs strong (x2 RCU en provisioned).
• Timeouts / retries : SDK gèrent le backoff sur ProvisionedThroughputExceededException.
• TTL attribut pour expirer sessions automatiquement.

aws dynamodb describe-table --table-name lab-orders 
  --query 'Table.{Status:TableStatus,Keys:KeySchema,Mode:BillingModeSummary}'

PartiQL (option)

DynamoDB comprend un SQL-like limité :

aws dynamodb execute-statement   --statement "SELECT * FROM "lab-orders" WHERE pk = 'USER#42'"

Utile pour explorer ; les apps restent souvent sur l’API Query pour le contrôle fin des coûts.

Pagination

Query/Scan renvoient LastEvaluatedKey : bouclez avec ExclusiveStartKey jusqu’à épuisement. Ne supposez jamais qu’une seule page contient tout.

IAM least privilege

Politique minimale lab : dynamodb:PutItem|GetItem|Query sur arn:aws:dynamodb:ca-central-1:ACCOUNT:table/lab-orders. Évitez Scan + * en prod.

Étape 8 — Vérification

Checklist : table ACTIVE · 2 items USER#42 · Query renvoie 2 · GetItem OK · vous savez pourquoi Scan ≠ Query.

Point-in-time recovery & backups

Activez PITR pour les tables prod (coût stockage incremental). Snapshots on-demand avant migration de schéma (GSI). En lab, laissez PITR off pour limiter la facture, puis delete-table immédiatement après les tests.

DynamoDB Local

Pour itérer sans cloud : DynamoDB Local / Test containers. Les quotas et latences réelles diffèrent — validez toujours une passe en ca-central-1 avant une mise en prod.

Nettoyage

aws dynamodb delete-table --table-name lab-orders

Comparer rapidement les coûts lecture

En mode provisioned, une lecture strongly consistent de 4 KB consomme 1 RCU ; eventually = 0,5 RCU. Les items > 4 KB multiplient les unités. D’où l’intérêt de projections courtes et d’éviter Scan. En on-demand vous payez à la requête — le mauvais pattern reste cher, juste autrement.

Erreurs fréquentes

Symptôme	Cause	Correction
ValidationException key	Mauvais type N/S	Aligner AttributeDefinitions
Query sans PK	API	Toujours égalité sur HASH
Facture Scan	Full table prod	Redesign clés / GSI
Hot partition	PK à faible cardinalité	Surcharge clé (suffixe) / redesign

Single-table design (idée)

Plutôt que users + orders + invoices en 3 tables SQL, DynamoDB regroupe souvent plusieurs types d’items sous la même table avec des préfixes PK/SK différents (USER#, ORDER#, INVOICE#). Avantage : une seule requête Query pour la « page client ». Inconvénient : design upfront plus difficile — commencez simple (ce lab) avant le single-table avancé.

Transactions & conditions

TransactWriteItems apporte all-or-nothing limité ; ConditionExpression évite d’écraser un item (optimistic locking avec attribut version). Utile panier / stock.

DynamoDB Streams & Integractions (aperçu)

Streams → Lambda pour fan-out ; DAX pour cache microseconde ; Global Tables multi-Region. Hors lab de base, très fréquents en architecture event-driven.

UpdateItem et ConditionExpression

Après les Put, mettez à jour un attribut sans réécrire tout l’item :

aws dynamodb update-item --table-name lab-orders 
  --key '{"pk":{"S":"USER#42"},"sk":{"S":"ORDER#1001"}}' 
  --update-expression "SET #s = :s" 
  --expression-attribute-names '{"#s":"status"}' 
  --expression-attribute-values '{":s":{"S":"SHIPPED"},":expected":{"S":"NEW"}}' 
  --condition-expression "#s = :expected" 
  --return-values ALL_NEW

Si le statut n’est plus NEW, vous obtenez ConditionalCheckFailedException — c’est l’optimistic locking de base (attribut version en prod). Utile panier / stock / workflow.

Query avec begins_with sur la SK

Pattern classique single-table : tous les orders d’un user, ou une plage :

aws dynamodb query --table-name lab-orders 
  --key-condition-expression "pk = :pk AND begins_with(sk, :prefix)" 
  --expression-attribute-values '{":pk":{"S":"USER#42"},":prefix":{"S":"ORDER#"}}'

Autres opérateurs SK : BETWEEN, >, <. Un FilterExpression s’applique après la lecture (vous payez les items lus puis filtrés) — ne remplace pas une bonne clé / GSI.

On-demand vs provisioned (choix SA)

Critère	On-demand (PAY_PER_REQUEST)	Provisioned (RCU/WCU)
Lab / spiky	Idéal	Risque throttle ou sur-provision
Trafic stable 24/7	Souvent plus cher	Souvent moins cher + Auto Scaling
Capacité réservée	Non	Oui (Reserved capacity possible)
Ops	Minimal	Dimensionner / alarmes throttle

En ca-central-1, gardez on-demand pour ce lab. Passez provisioned seulement si vous mesurez un plateau prévisible.

Lab bonus (5–8 min) — Query + Update + describe

aws dynamodb query --table-name lab-orders 
  --key-condition-expression "pk = :pk" 
  --expression-attribute-values '{":pk":{"S":"USER#42"}}' 
  --projection-expression "pk,sk,#s,total" 
  --expression-attribute-names '{"#s":"status"}'

aws dynamodb describe-table --table-name lab-orders 
  --query 'Table.{ItemCount:ItemCount,Size:TableSizeBytes,ARN:TableArn}'

Objectif : voir projection (moins d’attributs = moins de charge utile) et métriques table. Puis delete-table immédiatement.

Scénario examen classique

« Une app mobile doit lire le profil utilisateur par userId en quelques ms à très grande échelle ; les managers veulent aussi lister les commandes PENDING (faible cardinalité). » → table avec PK userId (ou USER#id) pour le path chaud ; GSI éventuel sur status avec prudence (hot partition si tout est PENDING) — souvent mieux un GSI status + createdAt ou un design sparse. Pas de Scan full-table comme solution « SQL WHERE ». Pas de RDS si le pattern d’accès est 100 % clé connue.

Checklist lab anti-facture DynamoDB

1. Mode on-demand ; pas de provisioned 1000 WCU « pour aller plus vite ».
2. Tags Name=lab-orders ; limitez Put/Query à quelques items.
3. Interdiction pédagogique : Scan sans Limit sur une table non-lab.
4. PITR off en lab ; delete-table dès la fin (vérifier absences d’autres tables lab-*).
5. IAM : pas de dynamodb:* sur * — scopez la table ARN ca-central-1.

Capacité en une minute (provisioned)

• 1 RCU ≈ 1 lecture strongly consistent de ≤ 4 KB / s (eventually = 2 lectures de 4 KB).
• 1 WCU ≈ 1 écriture ≤ 1 KB / s.
• Item 10 KB en strong read ≈ 3 RCU (arrondi supérieur). D’où projections courtes et clés bien conçues : le mauvais accès coûte cher même en on-demand (par requête / unité demandée).

Quiz (5 questions)

1. Une Query DynamoDB exige : – A. Uniquement un Scan filter
– B. La partition key (égalité)
– C. SQL JOIN

2. On-demand billing convient surtout à : – A. Uniquement du HPC GPU
– B. Trafic variable / labs
– C. Remplacer S3

3. Un Scan sur une grosse table : – A. Est toujours gratuit
– B. Lit toute la table (coût/latence)
– C. Remplace GetItem

4. Un GSI sert surtout à : – A. Remplacer IAM
– B. Interroger avec une autre clé (PK/SK différente)
– C. Chiffrer S3

5. ConditionExpression sur UpdateItem permet surtout de : – A. Ignorer toutes les erreurs réseau
– B. Éviter d’écraser un item si l’état attendu ne match pas
– C. Créer automatiquement un VPC

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

Pour aller plus loin

• DynamoDB
• Best practices for keys
• Query vs Scan
• Conditional updates
• Global Secondary Indexes

Maillage série AWS (P1)

← Précédent	RDS
→ Suivant	SNS et SQS
Aussi	Lambda · IAM