197 votes

DynamoDB vs MongoDB NoSQL

J'essaie de comprendre ce que je peux utiliser pour un projet futur, nous prévoyons de stocker environ 500 000 enregistrements par mois au cours de la première année et peut-être plus au cours des années suivantes. Il s'agit d'une application verticale, il n'est donc pas nécessaire d'utiliser une base de données pour cela, c'est la raison pour laquelle j'ai décidé de choisir un stockage de données noSQL.

La première option qui m'est venue à l'esprit était mongo db car c'est un produit très mature avec beaucoup de soutien de la part de la communauté, mais d'un autre côté, nous avons un tout nouveau produit qui offre un service géré à haute performance, je vais développer cette application, mais il n'y a pas de plan de maintenance (du moins pour l'instant), donc je pense que ce sera un énorme avantage car Amazon fournit une façon élastique d'évoluer.

Ma principale préoccupation concerne la structure des requêtes. Je n'ai pas encore examiné les capacités de requête de dynamoDB, mais comme il s'agit d'un stockage de données k/v, je pense qu'elles pourraient être plus limitées que celles de mongo db.

Si quelqu'un a eu l'expérience de déplacer un projet de MongoDB à DynamoDB, tout conseil sera totalement apprécié.

4 votes

Si vous voulez des conseils sur la structure des requêtes, je vous suggère de fournir un exemple de votre schéma ainsi que vos cas d'utilisation pour accéder aux données. Sans ces éléments, il est difficile de porter un jugement sur l'adéquation.

0 votes

En effet, la façon dont vous interrogez les données peut avoir une influence considérable sur le choix de la base de données dorsale. Le degré de hiérarchisation serait ma première question.

3 votes

Je m'étonne que cette question n'ait pas déjà été fermée par les personnes du classement SO. Habituellement, les questions qui demandent des conseils sont fermées parce qu'elles ne demandent pas d'aide pour un problème très spécifique.

177voto

CargoMeister Points 2954

Je sais que c'est vieux, mais ça apparaît toujours quand on cherche la comparaison. Nous utilisions Mongo, nous sommes passés presque entièrement à Dynamo, qui est maintenant notre premier choix. Pas parce qu'il a plus de fonctionnalités, ce n'est pas le cas. Mongo a un meilleur langage de requête, vous pouvez indexer dans une structure, il y a beaucoup de petites choses. La supériorité de Dynamo réside dans ce que l'OP a déclaré dans son commentaire : c'est facile. Vous n'avez pas à vous occuper de serveurs. Lorsque vous commencez à mettre en place une solution Mongo sharded, cela devient compliqué. Vous pouvez vous adresser à l'une des sociétés d'hébergement, mais ce n'est pas donné non plus. Avec Dynamo, si vous avez besoin de plus de débit, il vous suffit de cliquer sur un bouton. Vous pouvez écrire des scripts pour augmenter automatiquement le débit. Quand il est temps de mettre Dynamo à niveau, c'est fait pour vous. Tout cela représente beaucoup de stress et de temps précieux non utilisé. Si vous n'avez pas de personnel dédié aux opérations, Dynamo est excellent.

Nous sommes donc maintenant sur Dynamo par défaut. Mongo peut-être, si la structure des données est assez compliquée pour le justifier, mais alors nous reviendrons probablement à une base de données SQL. Dynamo est obtus, vous devez vraiment réfléchir à la façon dont vous allez le construire, et vous utiliserez probablement Redis dans Elasticcache pour le faire fonctionner pour des choses complexes. Mais c'est vraiment agréable de ne pas avoir à s'en occuper. Vous codez. C'est tout.

74voto

Mason Zhang Points 1747

J'ai récemment migré mon MongoDB vers DynamoDB, et j'ai écrit 3 blogs pour partager mon expérience et mes données sur les performances et les coûts.

Migrer de MongoDB vers AWS DynamoDB + SimpleDB

7 raisons pour lesquelles vous devriez utiliser MongoDB plutôt que DynamoDB

3 raisons d'utiliser DynamoDB plutôt que MongoDB

65voto

Derick Points 14797

Avec 500 000 documents, il n'y a aucune raison de changer d'échelle. Un ordinateur portable typique avec un SSD et 8 Go de RAM peut facilement faire des dizaines de millions d'enregistrements, donc si vous essayez de choisir en raison de la mise à l'échelle, votre choix n'a pas vraiment d'importance. Je vous suggère de choisir ce que vous aimez le plus, et peut-être celui pour lequel vous pouvez trouver le plus de support en ligne.

0 votes

Oui, ma principale préoccupation concerne la mise à l'échelle et la maintenance au fil du temps. Pour être honnête, je pense que MongoDB peut faire le travail, mais je ne pense qu'à la maintenance à moyen et long terme.

11 votes

Derick, un autre facteur important de l'échelle est l'utilisation, pas seulement le nombre de documents ou la taille de la base de données. L'@jack ne se " sent " pas, mais repose sur les tests, y compris la plate-forme et le matériel du déploiement final ; une semaine passée à remplir de données quelques variantes de bases de données et à effectuer des analyses comparatives devrait permettre de prendre des décisions éclairées et d'éviter bien des soucis.

3 votes

Fournir un produit/service professionnel va bien au-delà d'une simple solution du type "ceci peut faire cela". Ce n'est pas parce qu'une machine bon marché peut faire tourner Linux, MongoDB et des millions d'enregistrements pour presque rien qu'elle est aussi performante dans le monde réel. 500K enregistrements (avec un schéma SIMPLE) seraient probablement un bon candidat pour DynamoDB simplement parce que le PO n'aurait pas de coût de maintenance (pour le matériel au moins) et la charge mensuelle serait probablement beaucoup moins que le coût d'un serveur au cours d'un an ou deux.

23voto

AnneTheAgile Points 2105

Pour des comparaisons rapides, j'aime beaucoup ce site web, qui propose de nombreuses pages de comparaison, par exemple AWS DynamoDB vs MongoDB ; http://db-engines.com/en/system/Amazon+DynamoDB%3BMongoDB

3 votes

Merci pour le lien ! Je n'ai jamais été auparavant sur le site db-engines.com. Super site !

17voto

Deemoe Points 617

Réponse courte : Commencez par SQL et n'ajoutez NoSQL qu'en cas de besoin. (sauf si vous n'avez besoin de rien d'autre que des requêtes très simples).

Mon expérience personnelle : Je n'ai pas utilisé MongoDB pour les requêtes, mais en avril 2015, DynamoDB est encore très handicapé quand il s'agit de quelque chose au-delà des requêtes clés/valeurs les plus basiques. Je l'aime pour les choses de base, mais si vous voulez un langage de requête, alors regardez vers une vraie solution de base de données SQL.

Dans DynamoDB, vous pouvez effectuer une requête sur un hachage ou sur un hachage et une clé de plage, et vous pouvez avoir plusieurs index globaux secondaires. Je fais des requêtes sur une seule table avec 4 paramètres de filtre possibles et je trie les résultats, ce qui est supporté (à peine) par l'utilisation des index globaux secondaires avec des expressions de filtre. Le problème survient lorsque vous essayez d'obtenir le total des résultats correspondant au filtre, vous ne pouvez pas simplement rechercher les 10 premiers éléments correspondant au filtre, mais il vérifie plutôt 10 éléments et vous pouvez obtenir 0 résultat valide, ce qui vous oblige à continuer à rechercher à partir de la clé continue - une douleur dans le cou et consomme trop de votre quota de lecture de table pour un scénario simple.

Pour être spécifique au problème de limite avec les filtres dans la requête, ceci est tiré de la documentation ( http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit ) :

In a response, DynamoDB returns all the matching results within
the scope of the Limit value. For example, if you issue a Query 
or a Scan request with a Limit value of 6 and without a filter
expression, the operation returns the first six items in the 
table that match the request parameters. If you also supply a
FilterExpression, the operation returns the items within the 
first six items in the table that match the filter requirements.

Ma conclusion est que les requêtes impliquant des FilterExpressions ne sont utilisables qu'en de très rares occasions et ne sont pas évolutives car chaque requête peut facilement lire la plupart ou la totalité de votre table, ce qui consomme beaucoup trop d'unités de lecture DynamoDB. Une fois que vous utilisez trop d'unités de lecture, vous serez étranglé et les performances seront médiocres.

Avis d'expert : Lors du sommet AWS du 9 avril 2015, Brett Hollman, responsable de l'architecture des solutions chez AWS, dans son exposé sur le scalling de vos 10 premiers millions d'utilisateurs, préconise de commencer avec une base de données SQL, puis d'utiliser NoSQL uniquement quand et si cela a du sens. Car tôt ou tard, vous aurez probablement besoin d'un serveur SQL quelque part dans votre pile. Ses diapositives sont ici : http://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users Voir la diapositive 28.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X