DynamoDB vs MongoDB NoSQL

Je sais que c'est vieux, mais il arrive quand vous recherchez la comparaison. Nous utilisions Mongo, avons déménagé 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 est dans ce que l'OP a déclaré dans son commentaire: c'est facile. Vous n'avez pas à vous occuper des serveurs. Lorsque vous commencez à mettre en place une solution Mongo sharded, il devient compliqué. Vous pouvez aller à 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 à l'échelle automatiquement. Quand il est temps de mettre à niveau Dynamo, il est fait pour vous. C'est tout beaucoup de stress précieux et de temps non dépensé. Si vous n'avez pas de personnes spécialisées dans les opérations, Dynamo est excellent.

Donc, nous allons maintenant sur Dynamo par défaut. Mongo peut-être, si la structure de données est assez compliquée pour justifier il, mais nous reviendrions probablement à une base de données SQL. Dynamo est obtus, vous devez vraiment penser à la façon dont vous allez le construire, et probablement vous utiliserez Redis dans Elasticcache pour le faire fonctionner pour des choses complexes. Mais c'est sûr qu'il est agréable de ne pas avoir à prendre soin d'elle. Vous code. C'est tout.

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

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

Réponse courte: commencez par SQL et ajoutez NoSQL seulement quand / 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 en avril 2015, DynamoDB est toujours très paralysé quand il s'agit de n'importe quoi au-delà des requêtes clés/valeurs les plus élémentaires. Je l'aime pour les choses de base, mais si vous voulez un langage de requête, regardez une VRAIE solution de base de données SQL.

Dans DynamoDB, vous pouvez interroger sur un hachage ou sur un hachage et une plage clé, 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, Ceci est pris en charge (à peine) grâce à 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 il vérifie 10 éléments et vous pouvez obtenir 0 Résultats valides vous forçant à continuer à re-scanner à partir de la touche continue-douleur dans le cou et consomme trop de votre table lire quota pour un scénario simple.

Pour être précis sur le problème de limite avec les filtres dans la requête, cela provient des documents (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 FilterExpressions ne sont utilisables que dans 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 limité et verrez de mauvaises performances.

Avis D'Expert: lors du sommet AWS le 9 avril 2015 Brett Hollman, Manager, Solutions Architecture, AWS dans son discours sur scalling à vos 10 premiers millions d'utilisateurs préconise de commencer par une base de données SQL, puis en utilisant NoSQL seulement 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 génial parce que son HIPAA conforme sans aucun travail supplémentaire. Nous hébergeons donc la partie mongo sans données personnelles sur une configuration standard et permettons à amazon de traiter 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 relatable.

La principale raison pour laquelle nous avons choisi pour ce faire, utiliser mongo au lieu d'héberger toute l'application sur dynamo était pour 2 raisons. Tout d'abord, nous avions besoin de préformer les recherches basées sur la localisation que mongo est génial et à L'époque, Dynamo n'était pas, mais ils ont une option maintenant.

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

Maintenant, cela amène un autre point dans lequel vous avez mentionné. 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. Aller avec un SaaS/IaaS solution qui est assez bon pour faire le travail peut être une meilleure option que vous pouvez compter sur amazon à avoir conservé leurs systèmes sur le long terme.

J'ai travaillé sur les deux et genre de 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, raison pour laquelle 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'irais pour une sorte hybride de DB, où des données étendues pouvant être interrogées devraient être là est MongoDB, avec toute sa fonctionnalité que vous ne sentiriez jamais contraints de fournir des améliorations ou des modifications.

DynamoDB est rapide comme l'éclair (plus rapide que MongoDB) donc DynamoDB est souvent utilisé comme une alternative aux sessions dans les applications évolutives. Les meilleures pratiques de DynamoDB suggèrent également que s'il y a beaucoup de données qui sont 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 visiter deux ans les anciennes données. À ces fins, DynamoDB préfère avoir des données stockées par mois ou par années dans différentes tables.

DynamoDB est apparemment évolutif, quelque chose que vous devrez faire manuellement dans MongoDB. cependant, vous perdriez sur les performances de DynamoDB, si vous ne comprenez pas la partition de débit et comment la mise à l'échelle fonctionne derrière la scène.

DynamoDB devrait être utilisé lorsque la vitesse est critique, MongoDB d'autre part a trop de mains et de fonctionnalités, quelque chose DynamoDB manquer.

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 de 8(ou autre) heures. Vraiment utile, si vous avez foiré quelque chose de grand dans votre base de données et que vous voulez obtenir les données telles qu'elles sont avant.

C'est mon avis cependant.

Gardez à l'esprit, 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. C'était un magasin de clés-valeurs super-basique avec des capacités de stockage et d'interrogation extrêmement limitées. Il a depuis augmenté, maintenant en prenant en charge plus grandes tailles de documents + support JSON et indices secondaires globaux . L'écart entre ce que DynamoDB et MongoDB offre en termes de fonctionnalités diminue chaque mois. Les nouvelles fonctionnalités de DynamoDB sont développés sur ici.

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

Mes plats à emporter: si vous faites des requêtes de base de données sérieuses ou si vous travaillez dans des langues non pris en charge par DynamoDB, utilisez MongoDB. Sinon, restez avec DynamoDB.