🍃 Amazon DynamoDB (NoSQL Key-Value & Document Store)

Checklist avant mise en Production

Architecture : DynamoDB au centre de tout

DynamoDB est souvent le "Hub" de stockage des architectures Serverless.

L'outil indispensable : NoSQL Workbench

Ne modélisez pas sur un tableau blanc ou Excel. Utilisez l'outil officiel AWS (Gratuit, Mac/Win/Linux).

Résumé des Anti-Patterns (Ce qu'il ne faut pas faire)

La Guerre du JSON : DynamoDB vs DocumentDB

Les deux stockent du JSON. Mais la philosophie est radicalement différente.

Matrice de Décision

Migration Lift & Shift d'un MongoDB existant ? -> DocumentDB.
Nouveau projet Cloud-Native optimisé ? -> DynamoDB.

Vitesse vs Durabilité : Le Cache et la Base

DynamoDB est rapide (ms), mais Redis est ultra-rapide (µs). Sont-ils concurrents ?

⛔ Quand NE PAS utiliser DynamoDB

DynamoDB n'est pas un marteau pour tous les clous. Voici les cas où vous allez souffrir.

Réduire la facture sans réduire la perf

Quel mode choisir selon votre Business ?

Les pièges à éviter

• Les Scans : Un développeur fait un Scan complet de la table toutes les 5 minutes pour compter les users.
  -> Facture explosive car il lit TOUTE la table à chaque fois.
  -> Solution : Utiliser DynamoDB Streams + Lambda pour incrémenter un compteur.
• GSI Inutiles : Vous ajoutez un index "au cas où".
  -> Vous payez le stockage ET les écritures (WCU) pour cet index, même si personne ne le lit.
• Réseau NAT Gateway : Vos Lambdas dans un VPC privé accèdent à DynamoDB via la NAT Gateway.
  -> Vous payez le traitement des données NAT (0.045$/GB).
  -> Solution : Utiliser un VPC Gateway Endpoint (Gratuit).

Snapshots Complets : À la demande & AWS Backup

Utile pour l'archivage long terme, la conformité légale ou avant une mise en prod risquée.

PITR (Point-in-Time Recovery) : Le "Ctrl+Z" ultime

Protège contre les erreurs humaines ("Oups, j'ai supprimé la table" ou "Mon script a corrompu les données").

⚠️ Architecture : Le Piège de la Restauration

Impact sur le RTO (Recovery Time Objective)

Votre procédure de DR doit prévoir le basculement de l'application :

1. Lancer le Restore (Temps : ~20min à plusieurs heures selon la taille).
2. Option 1 (DNS/Config) : Changer la variable d'env DYNAMODB_TABLE_NAME dans les Lambdas/EC2 pour pointer vers la nouvelle table.
3. Option 2 (Route53) : Si vous utilisez Global Tables, faire un failover vers une autre région saine.

Note : La nouvelle table n'a PAS les alarmes, les tags, ni les politiques IAM de l'ancienne. Utilisez l'IaC (Terraform/CDK) pour réappliquer la config.

Export to S3 : Analytics sans Impact

Comment faire des GROUP BY ou des analyses BI sur vos données NoSQL ?

Fine-Grained Access Control (FGAC) : La "Row-Level Security"

Comment autoriser un utilisateur mobile à accéder uniquement à ses propres données dans une table partagée ?
Réponse : Les Conditions IAM.

                            {
                            "Effect": "Allow",
                            "Action": [ "dynamodb:GetItem", "dynamodb:Query" ],
                            "Resource": "arn:aws:dynamodb:region:id:table/AppTable",
                            "Condition": {
                            "ForAllValues:StringEquals": {
                            "dynamodb:LeadingKeys": ["${www.amazon.com:user_id}"],
                            "dynamodb:Attributes": ["Name", "Email", "Orders"]
                            }
                            }
                            }

Chiffrement au Repos (Encryption at Rest)

Toutes les tables DynamoDB sont chiffrées. Vous ne pouvez pas le désactiver. Mais vous pouvez choisir la clé.

Stratégies d'Isolation : "Blast Radius"

Comment empêcher qu'un script de test supprime la base de prod ?

VPC Endpoints (Réseau)

Par défaut, DynamoDB est accessible via Internet public (sécurisé par IAM).
Pour une sécurité maximale, utilisez un VPC Gateway Endpoint.

Chiffrement Côté Client (Banking/Santé)

Même avec KMS (Server-Side), les admins AWS ou les admins de votre compte *pourraient* théoriquement voir les données s'ils ont les droits.
Pour une confidentialité absolue (Zero Trust), chiffrez la donnée avant de l'envoyer.

DynamoDB Encryption Client

Une librairie AWS open-source.

• Fonctionnement : Chiffre les valeurs des attributs (ex: le numéro de carte bleue) mais laisse la Clé Primaire en clair (pour permettre le routing).
• Transparence : Le SDK déchiffre automatiquement à la lecture si l'app a la clé.
• Sécurité : La donnée stockée sur DynamoDB est un blob binaire illisible pour quiconque n'a pas la clé privée.

Transactions ACID (Multi-Item / Multi-Table)

Depuis 2018, DynamoDB n'est plus "juste" NoSQL. Il supporte des transactions complexes "Tout ou Rien".

Le Problème du "Lost Update"

Alice lit un document (v1). Bob lit le même document (v1). Alice sauvegarde (v2). Bob sauvegarde (v2).
Résultat : Les modifications d'Alice sont écrasées par Bob.

Solution : Optimistic Locking avec numéro de version

1. Ajouter un attribut version (nombre) à chaque item.
2. À chaque lecture, récupérer la version actuelle.
3. À chaque écriture, envoyer la version lue et demander d'incrémenter.

Condition Expressions : La logique au niveau stockage

Ne faites pas "Read-Then-Write" dans votre code (lent et risqué). Envoyez la condition à DynamoDB.

Note : Si la condition échoue, vous ne payez que 1 WCU (coût de vérification), pas le coût de l'écriture complète.

Idempotence : Gérer les pannes réseaux

Si vous envoyez une requête TransactWrite et que vous avez un timeout réseau (pas de réponse), l'écriture a-t-elle réussi ? Vous ne savez pas.

Structure Single-Table : Noms Génériques

Pour stocker des Users et des Produits dans la même table, il faut abstraire les noms de colonnes.

Pattern : Relation 1-N (Père-Fils)

Le cas classique E-Commerce : Un Client a des Commandes, qui ont des Paiements.

Table : Données stockées

Requêtes Magiques

• Tout récupérer (User + Orders + Payments) : Query(PK="USER#101").
• Juste les commandes : Query(PK="USER#101", SK BEGINS_WITH("ORDER#")).
• Commandes de 2023 : Query(PK="USER#101", SK BEGINS_WITH("ORDER#2023")).

Pattern : Séries Temporelles (Logs, Feed)

Objectif : Afficher les 10 derniers événements d'un capteur IoT ou d'un réseau social.

Pattern : Adjacency List (Many-to-Many)

Exemple : Des Étudiants s'inscrivent à des Cours.

Technique : On copie la SK dans le GSI-PK et la PK dans le GSI-SK. Cela permet d'interroger la relation dans les deux sens.

La "Hash Key" : Le GPS de la donnée

Comment DynamoDB sait-il sur quelle partition (parmi 10 000) se trouve votre item ? Grâce à la fonction de hachage.

Hot Partition : L'Ennemi de la Performance

Une "Hot Partition" est une partition physique qui reçoit plus de trafic qu'elle ne peut en supporter (1000 WCU), alors que les autres partitions sont vides.

Causes Fréquentes

Adaptive Capacity : La réponse d'AWS

Depuis 2019, DynamoDB tente de corriger automatiquement les partitions chaudes.

Technique Expert : Write Sharding

Comment gérer un compteur de votes pour l'élection présidentielle (1 Million writes/sec) sur une seule clé ?

Algorithme de Write Sharding

Lecture (Scatter-Gather) : Pour avoir le total, l'application doit lire les 100 partitions (BatchGetItem ou Query parallèle) et faire la somme.
Coût : Complexité applicative en lecture, mais performance d'écriture infinie.

Mode On-Demand : La tranquillité d'esprit

Mode Provisioned : L'optimisation FinOps

Vous définissez un nombre de WCU/RCU min et max. L'Auto Scaling ajuste la capacité entre les deux.

Le Piège de l'Autoscaling (Lag)

Solution : Pour les événements prévisibles (Black Friday), utilisez le Scheduled Scaling pour augmenter la capacité avant le pic.

Le Cycle de Vie d'une Table

La bonne stratégie n'est pas statique, elle évolue avec votre produit.

Maths : Quand basculer ?

Provisioned est moins cher, MAIS si votre autoscaling est mal réglé (sur-provisionning), vous payez pour du vide.

La Partition Key (PK) : L'Adresse Physique

La Sort Key (SK) : L'Ordre Logique

Si la PK détermine "Sur quelle étagère" est le livre, la SK détermine "À quelle place" sur l'étagère.

Item Collections : Le "Cluster" de données

L'ensemble des items ayant la même PK forme une Item Collection.

Exemple E-Commerce (Table Unique)

Quelle API utiliser ?

Comprendre la différence est vital pour la performance et le coût.

Le Cœur du Design : La Clé Primaire

Il n'y a que deux façons de définir une clé primaire. Ce choix dicte comment vous pourrez accéder à vos données.

Types Scalaires & Complexes

DynamoDB supporte un jeu riche de types de données pour modéliser des documents complexes.

La Limite des 400 KB

Autres Limites Importantes

• Profondeur JSON : Max 32 niveaux d'imbrication (Maps dans Maps).
• Taille Clé Partition (PK) : Max 2048 octets.
• Taille Clé de Tri (SK) : Max 1024 octets.

Key Overloading : Des noms génériques

Dans une table unique, la colonne de clé primaire va contenir des IDs d'utilisateurs, de commandes, de produits... On ne peut pas l'appeler UserID.

Cas Pratique : E-Commerce (Client + Commandes)

Objectif : Stocker un client, ses commandes, et le détail des produits, tout en permettant des accès rapides.

Visualisation de la Table

Item Collections : Le "JOIN" gratuit

Faut-il utiliser Single-Table partout ?

Non. C'est un pattern expert qui a des inconvénients majeurs.

Verdict : Utilisez le Single-Table pour les applications à très fort trafic (Hyper-Scale). Pour une petite app CRUD ou un MVP, le Multi-Table est souvent plus simple et suffisant.

Projections : Optimiser le Stockage et les WCU

Puisque le GSI est une copie, vous payez le stockage et l'écriture en double. L'attribut Projection définit ce que vous copiez.

Le Piège Mortel : GSI Throttling

Scénario Catastrophe

1. Table Principale : Provisionnée à 1000 WCU.
2. GSI "Email" : Provisionné à 5 WCU (oubli de config).
3. Vous lancez un import massif de données.
4. Le GSI sature instantanément.
5. Résultat : Vos PutItem sur la Table Principale échouent avec ProvisionedThroughputExceeded, même si la table est large.

Solution : Toujours configurer l'Autoscaling du GSI de la même manière que la Table, ou utiliser le mode On-Demand partout.

Design Pattern : Inverted Index

Pattern classique pour gérer les relations Many-to-Many (ex: Auteurs <-> Livres).

Design Pattern : GSI Overloading

Au lieu de payer pour 5 indexes différents, on en crée un seul "Générique" et on y met des données différentes selon l'entité.

Avantage : Vous ne payez qu'un seul GSI, mais il sert à toute l'application. C'est le cœur du "Single Table Design".

Anatomie d'une "Hot Partition"

Cela arrive quand la distribution de vos clés n'est pas uniforme.

Adaptive Capacity : Le "Pompier" d'AWS

Heureusement, DynamoDB est intelligent. Si une partition chauffe, le système réagit automatiquement.

Solutions Architecturales

Exemple de code : Write Sharding

                    // Écriture (Répartition sur 5 shards)
                    const shardId = Math.floor(Math.random() * 5) + 1;
                    const pk = `CANDIDATE_A_${shardId}`;
                    await dynamo.putItem({ PK: pk, Vote: 1 });

                    // Lecture (Aggrégation)
                    // Il faut faire 5 GetItem (ou 1 BatchGetItem) et sommer les résultats.

Comment réagir au Throttling ?

Ne relancez pas la requête immédiatement ! Vous ne feriez qu'aggraver l'embouteillage.

Le Langage DynamoDB

Contrairement à SQL, la structure est flexible, mais la Clé Primaire est rigide.

                            {
                            "PK": "USER#123",          // Partition Key
                            "SK": "PROFILE",           // Sort Key
                            "Nom": "Alice",
                            "Email": "alice@aws.com",
                            "Roles": ["Admin", "Editor"], // Liste
                            "Address": {               // Map (JSON imbriqué)
                            "City": "Paris",
                            "Zip": "75001"
                            }
                            }

Le Choc Culturel : SQL vs NoSQL

N'essayez pas d'utiliser DynamoDB comme MySQL, vous allez échouer.

Consistance des Lectures & Transactions

Puisque la donnée est répliquée sur 3 zones, quand je lis, est-ce que je vois la dernière version ?

Quand l'utiliser (et quand FUIR)

Comprendre PK (Partition Key) et SK (Sort Key)

C'est la décision de design la plus importante.

Opérations possibles sur la SK

Grâce à la Sort Key, vous pouvez faire des requêtes puissantes sans scanner toute la table :

L'Ennemi Public n°1 : Hot Partitions

Si tout le monde lit/écrit la même PK en même temps, vous créez un embouteillage sur UNE SEULE partition physique.

Single Table Design (STD) : Le Graal

En SQL, on fait 1 Table = 1 Entité (User, Order, Product). En DynamoDB expert, on met TOUT dans une seule table.

Technique Avancée : Write Sharding

Comment gérer un compteur de votes pour "Candidat A" lors d'une émission TV (1 Million votes/sec) ?
Une seule PK "CANDIDAT_A" exploserait la limite de 1000 WCU.

La Solution : Ajouter du hasard

• Écriture : Répartie sur 100 partitions. Capacité totale = 100 * 1000 WCU = 100 000 WCU.
• Lecture : On doit lire les 100 items et faire la somme (Scatter-Gather).

Provisioned vs On-Demand : Le Guide de Choix

Throttling & Burst Capacity

La vérité sur l'Autoscaling

En mode Provisioned, l'Autoscaling n'est PAS instantané. C'est un piège classique.

• Scale Out (Montée) : Prend quelques minutes pour réagir. Si votre trafic passe de 100 à 10 000 en 5 secondes (Pub TV), l'Autoscaling sera trop lent -> Throttling massif. Pour ces cas-là, utilisez On-Demand.
• Scale In (Descente) : AWS attend 15 à 60 minutes de calme avant de réduire la capacité. C'est pour éviter l'oscillation (Yo-Yo effect).
• Target Tracking : La configuration standard est "Cible 70%". DynamoDB essaiera de garder votre consommation à 70% de la limite provisionnée.

Calculatrice FinOps : Cas Réel

Scénario : Une app écrit 1 million d'items de 1KB par jour.

GSI (Global Secondary Index) : L'outil à tout faire

Permet de requêter la table selon un axe totalement différent (Nouvelle PK, Nouvelle SK).

LSI (Local Secondary Index) : Pourquoi l'éviter ?

Le LSI est un "vieux" concept de DynamoDB. Il partage la même PK que la table, mais change la SK.

Verdict : En 2024, utilisez des GSI dans 99% des cas. N'utilisez LSI que si vous avez une exigence absolue de consistance forte sur l'index.

GSI Overloading : La magie du Single-Table

Pattern : Sparse Index (Index "A trous")

DynamoDB n'indexe un item QUE si l'item possède la clé de l'index. S'il ne l'a pas, l'item est ignoré par l'index.

Connecter Lambda : Attention aux Pièges

Lambda ne "reçoit" pas les données. C'est le service Lambda (Daemon) qui "poll" le stream et invoque votre fonction.

La Solution : Partial Batch Failure

CQRS : DynamoDB + OpenSearch

Problème : DynamoDB est nul pour la recherche textuelle ("Trouver les produits contenant 'rouge'").
Solution : Utiliser les Streams pour synchroniser vers OpenSearch (Elastic).

Archivage & Analytique (S3)

Ne faites JAMAIS de Scan complet sur votre table de prod pour faire de la BI. Cela consomme toute la capacité.

Le Pipeline Moderne (Zero-Code)

• Source : Activer "Kinesis Data Streams" sur la table DynamoDB.
• Transport : Connecter Kinesis Firehose au stream.
• Transformation : Firehose convertit le JSON en Parquet (via une petite Lambda ou Glue).
• Destination : Bucket S3 (Data Lake).
• Analyse : Requêter S3 avec Amazon Athena (SQL).

EventBridge Pipes : Le Filtrage Serverless

Une nouvelle fonctionnalité (2023) qui simplifie la connexion Stream -> Lambda.

PITR (Point-in-Time Recovery) : Le Filet de Sécurité

⚠️ Le Grand Piège de la Restauration

La Procédure de Crise (RTO - Recovery Time Objective)

1. Lancer le Restore vers MaTable_Restored (Prend du temps selon la taille, ~20min pour 100GB).
2. Option A (Swap) : Changer la config de l'application pour pointer vers MaTable_Restored. (Rapide mais perte des données écrites *pendant* la panne).
3. Option B (Merge) : Scanner MaTable_Restored et réinjecter les items manquants dans MaTable_Originale. (Lent et complexe).

La table restaurée n'a PAS les Auto-Scaling, IAM Policies, ou Alarmes de l'originale. Il faut tout reconfigurer (IaC indispensable).

Export to S3 : ETL sans serveur

Comment faire de l'analytique sur DynamoDB sans tuer la prod ? En exportant vers S3.

Import from S3 : Migration Massive

Vous migrez de MongoDB ou Cassandra vers DynamoDB ? N'écrivez pas un script Python qui fait des PutItem un par un.

Le Piège : Concurrence & "Last Writer Wins"

Que se passe-t-il si Alice (à Paris) et Bob (à Tokyo) modifient le MÊME item à la MÊME seconde ?

Stratégies DR : RPO & RTO proches de zéro

Global Tables est l'outil ultime pour le Plan de Reprise d'Activité (PRA).

L'Addition SVP : Ça coûte cher ?

Oui. Multiplier les régions multiplie les coûts d'écriture.
Le concept clé est le Replicated Write Capacity Unit (rWCU).

Attention : Une table Global Table coûte environ N fois le prix d'une table simple (où N = nombre de régions), plus le coût du transfert inter-région.

Avant de cliquer sur "Add Region"

Reserved Capacity : L'arme absolue (-77%)

TTL (Time To Live) : Le Nettoyeur Gratuit

Supprimer des items avec DeleteItem coûte des WCU (donc de l'argent). Le TTL permet de supprimer des items expirés GRATUITEMENT.

Coûts Réseau : Le Tueur Silencieux

Si vos Lambda/EC2 sont dans un VPC privé et accèdent à DynamoDB via une NAT Gateway, vous payez des frais de traitement de données (0.045$/GB).

La Solution : Gateway VPC Endpoint

Chasse au Gaspillage : Top 5 des erreurs

Les Types de Données Supportés

DynamoDB utilise un format JSON typé spécifique (Marshalled JSON).

"Schemaless" ne veut pas dire "Anarchie"

La Limite Fatidique : 400 KB

Un item DynamoDB (Nom de colonnes + Valeurs) ne peut pas dépasser 400 Kilo-octets. C'est une limite dure (Hard Limit).

Clé Primaire Simple (Partition Key Only)

Clé Primaire Composite (Partition Key + Sort Key)

C'est ici que réside la puissance de DynamoDB. Elle permet de modéliser des relations 1-N (Un User a N Commandes).

La Puissance du "Query"

Avec une SK, vous pouvez utiliser l'opérateur Query :

Item Collections : Le concept de "Dossier"

Une Item Collection est l'ensemble de tous les items partageant la même Partition Key, mais avec des Sort Keys différentes.

Les Commandements du Design