Introduction
Amazon DynamoDB, service NoSQL serverless d'AWS lancé en 2012, reste en 2026 le pilier des applications à haute scalabilité comme celles de Netflix ou Duolingo, gérant des trillions de requêtes quotidiennes. Contrairement aux bases SQL relationnelles, DynamoDB excelle dans les workloads imprévisibles grâce à son modèle clé-valeur et document, avec une latence sub-milliseconde et une disponibilité à 99,999%.
Ce tutoriel expert, sans une ligne de code, décortique sa théorie profonde : de la modélisation de données single-table à l'optimisation des Global Secondary Indexes (GSI), en passant par le provisioned vs on-demand capacity. Vous apprendrez à anticiper les hot partitions, à exploiter les DynamoDB Streams pour l'event-driven architecture, et à intégrer TTL pour la gestion des données éphémères.
Pourquoi c'est crucial en 2026 ? Avec l'essor de l'IA générative et des microservices, 70% des nouvelles apps AWS optent pour DynamoDB pour son zero-management et son intégration native avec Lambda, AppSync ou Step Functions. Ce guide, structuré des fondations aux patterns avancés, vous armera pour des designs résilients face à des pics de trafic x1000. Prêt à penser comme un architecte AWS certifié ? (128 mots)
Prérequis
- Maîtrise avancée d'AWS (au moins Solutions Architect Professional)
- Connaissances en NoSQL (Cassandra, MongoDB) et modélisation de données
- Expérience avec des workloads à fort throughput (>10k ops/sec)
- Familiarité avec les concepts CAP (Consistency, Availability, Partition tolerance)
- Notions de event sourcing et CQRS
Fondamentaux : Clés de partition et tri
Au cœur de DynamoDB repose le modèle de table unique avec Partition Key (PK) et Sort Key (SK) optionnelle. Imaginez la PK comme un 'sharding hash' : DynamoDB distribue les items sur 1000+ partitions physiques via un hash interne, évitant les hotspots si la cardinalité est élevée (>10M items/partition). Exemple concret : pour un e-commerce, PK = USER# permet d'isoler les users ; SK = ORDER# trie chronologiquement les commandes.
Composite keys brillent en single-table design : un item USER#123#PROFILE (PK=USER#123, SK=PROFILE) cohabite avec USER#123#ORDER#456 sur la même table, réduisant les joins à zéro. Analogie : comme un classeur unique où chaque onglet (PK) regroupe des sous-dossiers triés (SK).
En 2026, avec DAX (cache in-memory), les reads chauds tombent à <1ms, mais une PK mal choisie (ex: timestamp croissant) crée des hot partitions : 80% du throughput sur 1% des partitions, throttlant tout. Toujours viser une taille de partition >10GB et >1 requête/seconde en moyenne. Étude de cas : Lyft a migré de Cassandra vers DynamoDB en redesignant ses PK géo-hashées, divisant les coûts par 3.
Modélisation de données : Single-Table Design
Single-table design est la philosophie experte : une table polyvalente pour tous les entités liées, évitant les multi-table queries coûteuses. Principe : chaque item porte un attributs générique (ex: type: 'USER' | 'ORDER' | 'PRODUCT' dans SK).
Exemple concret pour un SaaS analytics :
| PK | SK | Attributes |
|---|---|---|
| ----------------- | --------------------- | ----------------------------- |
| TENANT#abc123 | USER#john@email.com | name, role, createdAt |
| TENANT#abc123 | ORDER#456#2026-01-01 | amount, status, user_email |
| TENANT#abc123 | METRIC#views#daily | count, date |
Query PK='TENANT#abc123' SK begins_with 'USER#' → tous les users du tenant en une opération (1 RCU). Avantage : atomicité des transactions PartiQL sur items liés.
Défi : over-fetching. Solution : projections sparse (seuls les attributs nécessaires). En 2026, avec PartiQL SELECT, filurez comme SELECT name FROM table WHERE PK='...', mais limitez à 4KB/item. Cas réel : Pokémon GO utilise ce pattern pour 1B+ events/jour, avec PK=REGION#
Capacités et scaling : Provisioned vs On-Demand
DynamoDB offre deux modes : Provisioned Capacity (fixe RCU/WCU) vs On-Demand (auto-scaling pay-per-request). En 2026, On-Demand domine pour les spiky workloads (ex: Black Friday), scalant à 40k RCU/seconde par table sans config.
RCU/WCU décryptés : 1 RCU = 1 strongly consistent read de 4KB (ou 2 eventually consistent). Écrivez >4KB ? Fractionnez en multiples WCU (1 WCU = 1KB écrit). Analogie : comme un pipeline : RCU=lectures, WCU=écritures, Burst Pool (300s de capacité extra) pour pics.
Auto-scaling : cible 70% utilisation, min/max 10x. Exemple : app IoT avec 1k→100k devices : provisionnez 10k RCU base + auto-scaling. Piège : On-Demand coûte 25% plus cher au-delà de 2.5x moyenne ; switcher vers Provisioned pour prod stable.
Métriques CloudWatch : ConsumedReadCapacityUnits, ThrottledRequests >0.1% = alerte. Cas : Adobe a économisé 40% en migrant vers On-Demand + reserved capacity (1-3 ans, -70%).
Index secondaires : GSI et LSI avancés
Local Secondary Index (LSI) : Même PK, SK alternatif, créé à la table init. Limite 10 LSI/table, projections all/keys/partial. Idéal pour queries intra-partition : ex: PK=USER#123, LSI sur status trié.
Global Secondary Index (GSI) : PK/SK indépendants, scaling propre (RCU séparés). Jusqu'à 20 GSI/table (50 en 2026 preview). Exemple : table orders (PK=ORDER#id, SK=date), GSI1 (PK=CUSTOMER#id, SK=ORDER#status) pour 'tous les pending d'un user'.
Coût : chaque GSI duplique les données → +stockage/projections. Stratégie experte : GSI cascading (GSI2 pointe vers GSI1 via attributs). Backfilling (populate existants) prend heures/jours ; utilisez On-Demand pour tests.
Étude : DoorDash scale 100 GSI pour analytics temps-réel, avec Point-In-Time Recovery (PITR) pour undo. En 2026, GSI Accelerator (preview) prédit hot indexes via ML.
Fonctionnalités avancées : Streams, TTL et Transactions
DynamoDB Streams : Capture mutations (INSERT/UPDATE/DELETE) en <2s, shards parallèles. Intégrez à Lambda pour CDC (Change Data Capture) vers S3/Elasticsearch. Shard iterator : TRIM_HORIZON (tout) vs LATEST. Analogie : journal WAL pour event sourcing.
TTL (Time To Live) : Auto-delete items après timestamp (ex: sessions <24h). Économise 50% stockage logs ; gratuit (pas de WCU).
Transactions : ACID sur 100 items max (4MB total), TransactWriteItems/GetItems. Coût x2-10 RCU ; utilisez pour bookings (débit atomique stock+order).
Cas : Capital One streams vers Kinesis pour fraud detection temps-réel, TTL sur raw data. En 2026, Enhanced Streams supporte fan-out natif.
Bonnes pratiques
- Single-table only : Visez <5 entités liées ; documentez avec schéma ASCII/PlantUML.
- PK haute cardinalité : Ajoutez entropy (random suffix, hash) ; testez avec 1M inserts simulés.
- GSI lean : Projections KEYS_ONLY par défaut ; limitez à 5 GSI actifs.
- Capacity planning : Utilisez Capacity Calculator AWS ; provisionnez 2x pic + burst.
- Monitoring pro : CloudWatch Contributor Insights pour top hot keys ; X-Ray pour traces end-to-end.
- Data modeling workshop : Itere 3 rounds : requirements → draft → load test.
Erreurs courantes à éviter
- Hot partitions : PK=concurrent timestamp → 90% throttle ; solution : PK=UUID ou composite.
- Scan operations : Coûteux (1RCU/1KB) ; remplacez par Query avec FilterExpression optimisé.
- GSI sous-provisionnés : Writes throttlés si >RCU GSI ; doublez toujours RCU GSI vs table.
- Ignore DAX : Sans cache, p95 latency >10ms ; déployez cluster 3 nodes multi-AZ pour reads >70%.
- No PITR : Perte données irréversible ; activez toujours (point-in-time à 35 jours, +0.2$/GB/mois).
Pour aller plus loin
Plongez plus profond avec les ressources officielles :
- DynamoDB Developer Guide
- NoSQL Workbench pour modélisation visuelle
- AWS re:Invent talks 2025 : "Advanced Single-Table Patterns"
Formations expertes : Découvrez nos formations AWS avancées chez Learni – certification DynamoDB Specialist incluse. Livre recommandé : DynamoDB Applied Design Patterns (2024 edition).