DynamoDB n'est pas une base relationnelle
C'est la premiere erreur que font les developpeurs qui viennent du monde SQL. DynamoDB exige de penser vos patterns d'acces avant de designer vos tables.
1. Commencez par les patterns d'acces
Avant de creer une table, listez toutes les queries que votre application doit faire :
- Recuperer un utilisateur par ID
- Lister les commandes d'un utilisateur
- Trouver les commandes par statut et date
C'est votre point de depart. Pas le modele de donnees.
2. Single-Table Design : quand l'utiliser
Le single-table design consiste a mettre toutes vos entites dans une seule table DynamoDB. C'est puissant mais pas toujours necessaire.
Utilisez-le quand :
- Vous avez des relations 1-N frequemment consultees ensemble
- Vous voulez minimiser le nombre de requetes
- Votre equipe est a l'aise avec le pattern
Evitez-le quand :
- Votre equipe debute sur DynamoDB
- Les entites sont rarement consultees ensemble
- La complexite du code depasse le gain en performance
3. GSI : votre arme secrete
Les Global Secondary Indexes permettent de querier vos donnees sous des angles differents sans duplicer les donnees.
- Limitez-vous a 5 GSI par table (hard limit AWS : 20)
- Chaque GSI a son propre cout de lecture/ecriture
- Utilisez des sparse indexes pour economiser
4. Gestion de la capacite
- On-Demand : pour les charges imprevisibles ou les debuts de projet
- Provisionne + Auto-Scaling : pour les charges stables et previsibles
- Reserved Capacity : -50% si vous vous engagez sur 1 ou 3 ans
5. Monitoring essentiel
Surveillez toujours :
- ConsumedReadCapacityUnits et ConsumedWriteCapacityUnits
- ThrottledRequests : ne doit jamais etre > 0 en production
- SuccessfulRequestLatency : visez < 10ms en P99
Conclusion
DynamoDB est extremement performant quand il est bien utilise. Le piege est de l'approcher comme une base SQL. Prenez le temps de modeliser correctement, et vous aurez une base qui tient des millions de requetes par jour pour quelques dollars.
Besoin d'aide sur DynamoDB ? Contactez-moi.