DynamoDB vs MongoDB NoSQL [fermé]

J'essaie de comprendre ce que je peux utiliser pour un futur projet, nous prévoyons de stocker environ 500k enregistrements par mois la première année et peut-être plus pour les années à venir, il s'agit d'une application verticale, il n'est donc pas nécessaire d'utiliser un 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 communauté mais d'un autre côté, nous avons un tout nouveau produit qui offre un service géré aux meilleures performances, je vais développer ceci application mais il n'y a pas de plan de maintenance (du moins pour le moment) donc je pense que ce sera un énorme avantage car amazon fournit un moyen élastique d'évoluer.

Ma principale préoccupation concerne la structure de la requête, je n'ai pas encore examiné les capacités de requête de dynamoDB, mais comme le stockage de données ak / v, je pense que cela pourrait être plus limité que mongo db.

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

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

Migrer de MongoDB vers AWS DynamoDB + SimpleDB

7 raisons pour lesquelles vous devriez utiliser MongoDB sur DynamoDB

3 raisons pour lesquelles vous devriez utiliser DynamoDB sur MongoDB

Je sais que c'est vieux, mais cela revient toujours lorsque vous recherchez la comparaison. Nous utilisions Mongo, nous sommes passés presque entièrement à Dynamo, qui est notre premier choix maintenant. Non 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 fragmentée Mongo, cela se complique. Vous pouvez vous rendre dans l'une des sociétés d'hébergement, mais ce n'est pas bon marché 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 à mettre à l'échelle automatiquement. Quand il est temps de mettre à niveau Dynamo, c'est fait pour vous. Tout cela représente beaucoup de stress précieux et de temps non dépensé. Si vous ne le faites pas

Nous allons donc maintenant sur Dynamo par défaut. Mongo peut-être, si la structure des données est suffisamment compliquée pour le justifier, mais alors nous retournerions 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 bien de ne pas avoir à s'en occuper. Vous codez. C'est tout.

Avec 500 000 documents, il n'y a aucune raison de procéder à une mise à l'é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 où trouver le support le plus en ligne.

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

Réponse courte: commencez avec SQL et ajoutez NoSQL uniquement lorsque / si nécessaire. (sauf si vous n'avez besoin de rien au-delà de requêtes très simples)

Mon expérience personnelle: je n'ai pas utilisé MongoDB pour les requêtes, mais depuis avril 2015, DynamoDB est toujours très paralysé lorsqu'il s'agit de tout ce qui va au-delà des requêtes clé / valeur les plus élémentaires. Je l'adore pour les éléments de base, mais si vous voulez un langage de requête, recherchez une véritable solution de base de données SQL.

Dans DynamoDB, vous pouvez interroger sur un hachage ou sur une clé de hachage et 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 trie les résultats, cela est pris en charge (à peine) par l'utilisation des index secondaires globaux 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 plutôt il vérifie 10 éléments et vous pouvez obtenir 0 résultats valides vous obligeant à continuer numérisation à partir de la touche Continuer - douleur dans le cou et consomme trop de votre quota de lecture de table pour un scénario simple.

Pour être précis sur le problème de limite avec les filtres dans la requête, cela provient de la documentation ( http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit ):

Dans une réponse, DynamoDB renvoie tous les résultats correspondants dans
la portée de la valeur limite. Par exemple, si vous émettez une requête
ou une requête Scan avec une valeur limite de 6 et sans filtre
expression, l'opération renvoie les six premiers éléments du 
table qui correspondent aux paramètres de la demande. Si vous fournissez également un
FilterExpression, l'opération renvoie les éléments dans le 
les six premiers éléments du tableau qui correspondent aux exigences du filtre.

Ma conclusion est que les requêtes impliquant 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 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 vous constaterez de mauvaises performances.

Avis d'expert: Lors du sommet AWS du 9 avril 2015, Brett Hollman, Manager, Solutions Architecture, AWS, dans son exposé sur la communication avec vos 10 premiers millions d'utilisateurs, préconise de commencer par une base de données SQL, puis d'utiliser NoSQL uniquement quand et si cela a du sens. Parce que 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.

Nous avons choisi une combinaison de Mongo / Dynamo pour un produit de santé. Fondamentalement, mongo permet une meilleure recherche, mais le Dynamo hébergé est excellent car il est conforme à la norme HIPAA sans aucun travail supplémentaire. Nous hébergeons donc la partie mongo sans données personnelles sur une configuration standard et permettons à amazon de gérer la partie HIPAA en termes d'infrastructure. Nous pouvons interroger certains éléments de mongo qui font apparaître des documents avec des pointeurs (ID) du document Dynamo associé.

La principale raison pour laquelle nous avons choisi de le faire en utilisant mongo au lieu d'héberger toute l'application sur dynamo était pour 2 raisons. Premièrement, nous devions effectuer des recherches basées sur la localisation, ce que mongo est excellent à l'époque et à l'époque, Dynamo ne l'était pas, mais ils ont maintenant une option.

Deuxièmement, certains documents n'étaient pas structurés et nous ne savions pas à l'avance quelles seraient les données, par exemple, disons qu'un utilisateur entre un document dans la collection "form" comme ceci: {"username": "user1", " email ":" me@me.com "}. Et un autre utilisateur met cela dans la même collection {"phone": "813-555-3333", "location": [28.1234, -83.2342]}. Avec mongo, nous pouvons rechercher n'importe lequel de ces champs dynamiques et inconnus à tout moment, avec Dynamo, vous pouvez le faire mais vous devrez créer un index chaque fois qu'un nouveau champ a été ajouté que vous souhaitez rechercher. Donc, si vous n'avez jamais eu de champ de téléphone dans votre document Dynamo auparavant et que tout à coup, quelqu'un l'ajoute, il est complètement inaccessible.

Maintenant, cela soulève un autre point dont vous avez parlé. Parfois, choisir la bonne solution pour le travail ne signifie pas toujours choisir le meilleur produit pour le travail. Par exemple, vous pouvez avoir un client qui a besoin et utilisera le système que vous avez créé pendant plus de 10 ans. Opter pour une solution SaaS / IaaS suffisamment bonne pour faire le travail peut être une meilleure option, car vous pouvez compter sur amazon pour entretenir et entretenir ses systèmes sur le long terme.

J'ai travaillé sur les deux et en quelque sorte fan des deux.

Mais vous devez comprendre quand utiliser quoi et dans quel but.

Je ne pense pas que ce soit une bonne idée de déplacer toute votre base de données vers DynamoDB, car l'interrogation est difficile sauf sur les clés primaires et secondaires, l'indexation est limitée et l'analyse dans DynamoDB est douloureuse.

J'opterais pour une sorte de base de données hybride, où de nombreuses données interrogeables devraient se trouver, MongoDB, avec toutes ses fonctionnalités, vous ne vous sentiriez jamais obligé de fournir des améliorations ou des modifications.

DynamoDB est ultra-rapide (plus rapide que MongoDB), donc DynamoDB est souvent utilisé comme alternative aux sessions dans des applications évolutives. Les meilleures pratiques DynamoDB suggèrent également que s'il y a beaucoup de données moins utilisées, déplacez-les vers une autre table.

Supposons donc que vous ayez un article ou un flux. Les gens sont plus susceptibles de chercher des trucs de la semaine dernière ou des trucs de ce mois-ci. les chances sont vraiment rares pour les gens de consulter des données datant de deux ans. À ces fins, DynamoDB préfère que les données soient stockées par mois ou par années dans différentes tables.

DynamoDB est parfaitement évolutif, ce que vous devrez faire manuellement dans MongoDB. Cependant, vous perdriez les performances de DynamoDB si vous ne comprenez pas la partition de débit et le fonctionnement de la mise à l'échelle en arrière-plan.

DynamoDB doit être utilisé là où la vitesse est critique, MongoDB en revanche a trop de mains et de fonctionnalités, ce qui manque à DynamoDB.

par exemple, vous pouvez avoir un jeu de répliques de MongoDB de telle sorte que l'une des répliques contienne une instance de données datant de 8 heures (ou autre). Vraiment utile, si vous avez gâché quelque chose de gros dans votre base de données et que vous souhaitez obtenir les données telles qu'elles étaient auparavant.

C'est mon avis cependant.

Gardez à l'esprit que je n'ai expérimenté qu'avec MongoDB ...

D'après ce que j'ai lu, DynamoDB a parcouru un long chemin en termes de fonctionnalités. Il s'agissait auparavant d'un magasin clé-valeur super basique avec des capacités de stockage et d'interrogation extrêmement limitées. Il a depuis grandi, prenant désormais en charge des tailles de documents plus grandes + le support JSON et les index secondaires globaux . L'écart entre ce que propose DynamoDB et MongoDB en termes de fonctionnalités se réduit chaque mois. Les nouvelles fonctionnalités de DynamoDB sont développées ici .

Une grande partie des comparaisons MongoDB et DynamoDB sont obsolètes en raison de l'ajout récent de fonctionnalités DynamoDB. Cependant, cet article offre d'autres points convaincants pour choisir DynamoDB, à savoir qu'il est simple, peu d'entretien et souvent peu coûteux. Une autre discussion ici sur les choix de bases de données était intéressante à lire, bien que légèrement ancienne.

À retenir: si vous effectuez des requêtes sérieuses sur la base de données ou travaillez dans des langues non prises en charge par DynamoDB, utilisez MongoDB. Sinon, restez avec DynamoDB.