Quand utiliser DynamoDB (et quand non)

DynamoDB est une base de données fantastique pour les charges pour lesquelles elle est conçue, et frustrante pour le reste. La question décisive n'est pas « est-ce que c'est à l'échelle du web ? » — c'est « est-ce que je connais mes patterns d'accès à l'avance, et sont-ils basés sur la clé ? » Réussis ça et DynamoDB te donne des lectures en quelques millisecondes à n'importe quelle échelle ; rate-le et tu te battras pour toujours contre l'absence de jointures et de requêtes ad hoc.

Quand faut-il utiliser DynamoDB ?

Utilise DynamoDB quand tes patterns d'accès sont connus, basés sur la clé et à fort volume, et que tu veux une latence prévisible en quelques millisecondes à n'importe quelle échelle sans aucun serveur à gérer. Évite-la pour les requêtes ad hoc, les jointures complexes ou l'analytique sur tout le jeu de données, et quand les données sont peu volumineuses avec des formes de requête en constante évolution.

• Utilise DynamoDB quand tes patterns d'accès sont connus, basés sur la clé et à fort volume — et que tu veux une latence prévisible à n'importe quelle échelle sans serveur à gérer.
• Évite-la quand tu as besoin de requêtes ad hoc, de jointures riches ou d'analytique sur tout le jeu de données, ou quand les données sont petites et que les formes de requête n'arrêtent pas de changer.
• Le compromis central : DynamoDB t'oblige à concevoir pour tes requêtes à l'avance ; en retour, elle ne ralentit jamais quand tu grandis.
• Ce n'est pas une base relationnelle avec une syntaxe différente — la modéliser comme telle est la source de douleur n°1.

Les signaux qui favorisent DynamoDB

DynamoDB brille quand la plupart de ces points sont vrais :

• Tu connais tes patterns d'accès à l'avance. Tu peux lister les requêtes exactes que l'application fait (« récupérer un utilisateur par id », « lister les commandes d'un utilisateur du plus récent au plus ancien ») et elles ne changent pas sur un coup de tête. DynamoDB se modélise autour de ces requêtes.
• L'accès est basé sur la clé. Tu recherches les items par une clé de partition connue, pas en scannant pour des combinaisons arbitraires d'attributs.
• L'échelle et la latence prévisible comptent. DynamoDB délivre des performances constantes en quelques millisecondes que la table contienne mille items ou un milliard.
• Tu veux zéro charge opérationnelle. Pas d'instances, pas de bascule, pas de vacuuming — c'est entièrement géré et ça descend jusqu'à zéro en on-demand.
• Le débit d'écriture est élevé et en pics. Journaux d'événements, télémétrie IoT, état de session/panier, classements — des charges à fortes écritures avec une clé claire.

Les signaux contre

Opte plutôt pour une base relationnelle (ou un moteur de recherche/d'analytique) quand :

• Tes requêtes sont ad hoc. Les analystes découpent les données par colonnes arbitraires, ou les besoins changent chaque semaine. La flexibilité du SQL l'emporte ; DynamoDB demanderait un nouvel index par pattern.
• Tu as besoin de vraies jointures et agrégations sur tout le jeu de données. Reporting, business intelligence, « somme du chiffre d'affaires par région par mois » — c'est un travail OLAP/relationnel.
• Le jeu de données est petit et à faible trafic. Quelques milliers de lignes sur une appli d'admin tranquille ne tirent aucun bénéfice de l'échelle de DynamoDB et perdent la commodité du SQL.
• Tu ne peux pas encore prédire les patterns d'accès. Produit en phase initiale qui cherche encore sa forme ? Un schéma relationnel que tu peux ré-interroger librement est plus indulgent jusqu'à ce que les patterns se stabilisent.

Compter le coût avant de t'engager

La tarification de DynamoDB suit les lectures, les écritures et le stockage — pas les heures d'instance — donc elle est peu chère pour les charges en pics et serverless, et peut être onéreuse pour des scans lourds soutenus. Modélise ton vrai mix lecture/écriture avec le calculateur de tarifs DynamoDB avant de t'engager ; une charge qui semble convenir techniquement devrait aussi tenir la route côté coût.

Une fois que tu as décidé que ça convient

Le travail se déplace vers la modélisation. DynamoDB récompense la conception de la table autour de tes requêtes — voir comment modéliser des données dans DynamoDB et le single-table design — et explicitement quand ne pas opter pour le single-table.

Pièges et étapes suivantes

• Ne modélise pas DynamoDB comme une base relationnelle — des tables normalisées que tu joins à la lecture, c'est l'anti-pattern qu'elle punit le plus durement.
• Ne la choisis pas pour l'analytique — associe-la à un store analytique (ou exporte vers l'un d'eux) pour le reporting plutôt que de scanner.
• Pas sûr des patterns d'accès ? Attends. Adopter DynamoDB avant de connaître tes requêtes, c'est choisir la seule base qui exige que tu les connaisses.
• À voir aussi : query vs scan montre ce que « l'accès basé sur la clé » t'apporte vraiment.

Envie d'explorer une table DynamoDB avant de parier ton appli dessus ? Télécharge DynoTable et connecte-toi à tes données directement.