DynamoDB vs Amazon Neptune
DynamoDB et Amazon Neptune sont tous deux des bases de données AWS entièrement managées, mais ils modélisent les données de façons fondamentalement différentes. DynamoDB est un magasin clé-valeur et document que tu interroges par clé. Neptune est une base de données graphe dédiée qui stocke des nœuds et des arêtes (ou des triplets RDF) et parcourt directement les relations avec des langages de requête de graphe. Le choix se résume à savoir si les relations sont la chose principale que tu interroges.
Devrais-tu utiliser DynamoDB ou Neptune ?
Choisis DynamoDB pour un accès par clé à des enregistrements structurés à grande échelle, où les relations sont limitées et peuvent être modélisées avec des clés. Choisis Amazon Neptune quand les connexions sont au cœur de tes requêtes — traversées multi-sauts, plus court chemin, recommandations, réseaux de fraude, graphes de connaissances — où un modèle graphe exprime en une seule requête ce qui serait de nombreux allers-retours contre un magasin clé-valeur. C'est le degré de dépendance de tes requêtes aux relations qui tranche.
DynamoDB vs Amazon Neptune en un coup d'œil
| Caractéristique | DynamoDB | Amazon Neptune |
|---|---|---|
| Modèle de données | NoSQL clé-valeur et document ; éléments typés jusqu'à 400 KB dans des tables | Graphe — property graph (nœuds/arêtes avec propriétés) et RDF (triplets sujet-prédicat-objet) |
| Langage de requête / API | API native (GetItem, Query, Scan) plus PartiQL, un langage compatible SQL | Gremlin et openCypher pour les property graphs ; SPARQL pour les graphes RDF |
| Accès principal | Recherches par clé sur la clé de partition/tri ; relations modélisées via des clés | Traversée de relations — parcourir des arêtes sur de nombreux sauts en une seule requête |
| Relations | Pas de traversée native ; modélise avec une liste d'adjacence ou single-table design | Les arêtes sont de première classe ; les requêtes multi-sauts et de chemin sont natives et efficaces |
| Cohérence | À terme par défaut ; lectures fortement cohérentes disponibles par requête | Les lectures sont cohérentes au sein d'un cluster ; les répliques de lecture servent des lectures montées en charge |
| Modèle de montée en charge | Partitionnement automatique ; serverless on-demand ou capacité provisionnée | Instances de base de données provisionnées avec répliques de lecture, ou Neptune Serverless (capacité en NCU) qui autoscale |
| Transactions | Transactions ACID sur plusieurs éléments au sein d'une Région | Transactions ACID sur les mutations de graphe |
| Modèle tarifaire / ops | Paiement à la requête (on-demand) ou capacité provisionnée plus le stockage ; serverless | Heures d'instance (provisionné) ou heures NCU (Serverless), plus le stockage et les E/S ; réservé à AWS |
| Charges de travail idéales | Profils, sessions, paniers, événements — enregistrements par clé à grande échelle | Graphes sociaux, recommandations, détection de fraude, graphes de connaissances, graphes réseau/identité |
Quand DynamoDB est le meilleur choix
- Ton accès est basé sur des clés. Get-by-id, interroger une partition et filtrer au sein d'une partition se mappent naturellement à DynamoDB et restent rapides à n'importe quelle échelle.
- Les relations sont peu profondes ou bornées. Les liens un-à-plusieurs et plusieurs-à-plusieurs peuvent être modélisés avec des clés — une liste d'adjacence ou du single-table design — sans moteur de graphe.
- Tu veux la simplicité serverless et le paiement à la requête. La capacité on-demand n'a rien à dimensionner et descend à zéro lorsqu'elle est inactive.
- Tu ne fais pas de traversées profondes. Si tu parcours rarement plus d'un saut ou deux, les points forts d'une base de données graphe restent inutilisés.
Quand Neptune est le meilleur choix
- Les relations sont la requête. Les traversées multi-sauts — amis d'amis, plus court chemin, « qui est connecté à qui » — sont natives en Gremlin, openCypher ou SPARQL, là où un magasin clé-valeur aurait besoin de nombreuses lectures séquentielles.
- Tu as besoin d'un property graph ou de RDF. Neptune prend en charge les deux modèles et leurs langages de requête standard, adaptés aux graphes de connaissances et aux cas d'usage de données liées.
- Ton domaine a une forme de graphe. La détection de fraude, les moteurs de recommandation, les réseaux sociaux et les graphes d'identité/réseau s'expriment naturellement sous forme de nœuds et d'arêtes.
- Les schémas de traversée évoluent en permanence. De nouvelles questions de relations sont de nouvelles requêtes de graphe, pas une refonte de tes clés.
Une règle empirique utile : DynamoDB peut représenter des relations avec un modèle de liste d'adjacence, et cela suffit quand tu connais les traversées à l'avance et qu'elles restent peu profondes. Quand les traversées sont profondes, de profondeur variable ou ad hoc, le moteur de graphe de Neptune est conçu exactement pour cela et évite le coût des nombreux allers-retours du parcours d'arêtes dans un magasin clé-valeur.
Travailler avec DynamoDB
Si ta charge de travail est basée sur des clés et que tu modélises les relations avec une liste d'adjacence, DynoTable est un client de bureau natif pour DynamoDB sur macOS, Windows et Linux. Il lit ta chaîne d'identifiants AWS standard, donc tes données restent dans DynamoDB sans rien à migrer. Il parcourt et modifie des éléments en ligne, construit visuellement des conditions de clé et des filtres, et ajoute un SQL Workbench qui exprime des requêtes de forme relationnelle dans les règles de modèle d'accès de DynamoDB, plus un assistant IA sur tes propres identifiants AWS Bedrock.
Le DynamoDB Expression Builder gratuit génère les conditions de clé, filtres et expressions de mise à jour dont un modèle de liste d'adjacence a besoin, en forme SDK, CLI et PartiQL. DynoTable est une application commerciale à code fermé ; cette page décrit ce qu'elle fait, pas comment elle est construite.
FAQ
DynamoDB peut-il être utilisé comme base de données graphe ?
Partiellement. DynamoDB n'a pas de traversée de graphe native, mais tu peux modéliser des relations avec un modèle de liste d'adjacence ou du single-table design, ce qui fonctionne bien quand les traversées sont connues et peu profondes. Pour des traversées profondes, de profondeur variable ou ad hoc — plus court chemin, recommandations multi-sauts — une base de données graphe dédiée comme Neptune convient mieux car elle parcourt les arêtes nativement au lieu d'émettre de nombreuses lectures séparées.
Quels langages de requête Neptune prend-il en charge par rapport à DynamoDB ?
Neptune prend en charge Gremlin et openCypher pour les property graphs et SPARQL pour les graphes RDF. DynamoDB utilise son API native (GetItem, Query, Scan et opérations associées) plus PartiQL, un langage compatible SQL. Il n'y a aucun chevauchement dans le langage de requête — les modèles sont différents.
Quand dois-je choisir Neptune plutôt que DynamoDB ?
Choisis Neptune quand les connexions sont ce que tu interroges le plus : traversées multi-sauts, recherche de chemin, ou domaines centrés sur les relations comme la détection de fraude, les recommandations et les graphes de connaissances. Choisis DynamoDB quand l'accès se fait principalement par clé et que les relations sont assez limitées pour être modélisées avec des clés. Certaines architectures utilisent les deux — DynamoDB pour les enregistrements opérationnels et Neptune pour le graphe connecté par-dessus.
Voir aussi
- Modélise les relations dans DynamoDB avec les guides modèle de liste d'adjacence, un-à-plusieurs et plusieurs-à-plusieurs.
- Structure le tout avec le single-table design.
- Construis des expressions avec le DynamoDB Expression Builder gratuit.
- Télécharger DynoTable pour parcourir, interroger et modifier tes tables DynamoDB.
Dernière vérification le 2026-07-12 par rapport à la documentation officielle AWS DynamoDB et Amazon Neptune. Amazon Neptune et DynamoDB sont des services d'Amazon Web Services ; mentionnés ici à des fins d'identification uniquement.