DynamoDB vs MongoDB NoSQL

Question

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é.

Answer 1

Nous avons choisi une combinaison de Mongo/Dynamo pour un produit de santé. En fait, Mongo permet une meilleure recherche, mais l'hébergement de Dynamo est excellent car il est conforme à la loi HIPAA sans travail supplémentaire. Nous hébergeons donc la partie mongo sans données personnelles sur une configuration standard et laissons Amazon s'occuper de 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 correspondant.

La raison principale pour laquelle nous avons choisi d'utiliser mongo au lieu d'héberger l'ensemble de l'application sur Dynamo était pour deux raisons. Tout d'abord, nous avions besoin d'effectuer des recherches basées sur la localisation, ce pour quoi mongo est excellent, ce qui n'était pas le cas de Dynamo à l'époque, mais cette option existe désormais.

Deuxièmement, certains documents n'étaient pas structurés et nous ne savions pas à l'avance quelles seraient les données. Par exemple, disons que l'utilisateur a saisit un document dans la collection "form" comme ceci : {"nom d'utilisateur" : "user1", "email" : "me@me.com"}. Et un autre utilisateur met ceci 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 pouviez le faire mais vous deviez créer un index à chaque fois qu'un nouveau champ était ajouté et que vous vouliez pouvoir le rechercher. Ainsi, si vous n'avez jamais eu de champ téléphone dans votre document Dynamo auparavant et que tout à coup, quelqu'un l'ajoute, il est totalement impossible de le rechercher.

Cela soulève un autre point que 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 du système que vous avez créé et qui l'utilisera pendant plus de 10 ans. Choisir une solution SaaS/IaaS qui est suffisamment bonne pour faire le travail peut être une meilleure option, car vous pouvez compter sur Amazon pour avoir entretenu et maintenu ses systèmes sur le long terme.

Answer 2

J'ai travaillé sur les deux et je suis un peu fan des deux.

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

Je ne pense pas que ce soit une bonne idée de déplacer toutes vos bases de données vers DynamoDB, car les requêtes sont difficiles, sauf sur les clés primaires et secondaires, l'indexation est limitée et le balayage dans DynamoDB est douloureux.

J'opterais pour une sorte de base de données hybride, où les données pouvant être interrogées de manière extensive sont disponibles. MongoDB, avec toutes ses fonctionnalités, vous ne vous sentirez jamais contraint d'apporter des améliorations ou des modifications.

DynamoDB est rapide comme l'éclair (plus rapide que MongoDB), c'est pourquoi DynamoDB est souvent utilisé comme alternative aux sessions dans les applications évolutives. Les meilleures pratiques de DynamoDB suggèrent également que si les données sont nombreuses et moins utilisées, il faut les déplacer vers une autre table.

Supposons donc que vous ayez un article ou un flux. Les gens sont plus enclins à rechercher les articles de la semaine dernière ou de ce mois-ci. Il est très rare que les gens consultent des données vieilles de deux ans. Pour ces raisons, DynamoDB préfère que les données soient stockées par mois ou par année dans des tables différentes.

DynamoDB est apparemment extensible, ce que vous devrez faire manuellement dans MongoDB. Cependant, vous perdrez en performance avec DynamoDB si vous ne comprenez pas la partition du débit et comment l'extensibilité fonctionne en arrière-plan.

DynamoDB doit être utilisé lorsque la vitesse est essentielle. MongoDB, en revanche, a trop de mains et de fonctionnalités, ce qui fait défaut à DynamoDB.

Par exemple, vous pouvez disposer d'un ensemble de répliques de MongoDB de telle sorte que l'une des répliques contienne une instance de données datant de 8 (ou autre) heures. C'est très utile si vous avez fait une grosse erreur dans votre base de données et que vous voulez récupérer les données telles qu'elles étaient avant.

Mais c'est mon opinion.

Answer 3

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

D'après ce que j'ai lu, DynamoDB a beaucoup évolué en termes de fonctionnalités. Auparavant, il s'agissait d'un magasin de clés et de valeurs super basique avec des capacités de stockage et d'interrogation extrêmement limitées. Il s'est développé depuis et prend désormais en charge documents de plus grande taille + support JSON et indices secondaires mondiaux . L'écart entre ce que DynamoDB et MongoDB offrent en termes de fonctionnalités se réduit chaque mois. Les nouvelles fonctionnalités de DynamoDB sont développées sur les points suivants ici .

La plupart des comparaisons entre MongoDB et DynamoDB sont dépassées en raison de l'ajout récent de fonctionnalités à DynamoDB. Cependant, ce poste propose d'autres arguments convaincants pour choisir DynamoDB, à savoir qu'il est simple, qu'il nécessite peu de maintenance et qu'il est souvent peu coûteux. Une autre discussion ici des 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 des bases de données ou si vous travaillez dans des langues non prises en charge par DynamoDB, utilisez MongoDB. Sinon, restez fidèle à DynamoDB.