DynamoDB vs MongoDB NoSQL

J’ai récemment migré mon MongoDB vers DynamoDB et écrit 3 blogs pour partager des expériences 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 d’utiliser DynamoDB sur MongoDB

Je sais que c’est vieux, mais ça revient quand on cherche la comparaison. Nous utilisions Mongo, nous sums presque entièrement passés à Dynamo, 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 à configurer une solution fragmentée Mongo, cela 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 pour mettre à l’échelle automatiquement. Quand il est temps de mettre à niveau Dynamo, c’est fait pour vous. C’est beaucoup de stress précieux et de temps non dépensé. Si vous n’avez pas de personnel dédié, Dynamo est excellent.

Donc, nous allons maintenant sur Dynamo par défaut. Mongo peut-être, si la structure des données est suffisamment compliquée pour le justifier, mais nous retournerions probablement à une firebase database 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 sur des choses complexes. Mais c’est bien de ne pas avoir à en prendre soin. Vous codez C’est tout.

Avec 500 000 documents, il n’y a aucune raison de faire évoluer les choses. Un ordinateur portable typique avec un SSD et 8 Go de RAM peut facilement faire 10 sur des millions de disques, donc si vous essayez de choisir en raison de la mise à l’échelle, votre choix importe peu. 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 beaucoup ce site Web, qui comporte de nombreuses pages de comparaison, par exemple AWS DynamoDB vs MongoDB; http://db-engines.com/fr/system/Amazon+DynamoDB%3BMongoDB

Réponse courte: Commencez avec SQL et ajoutez NoSQL seulement quand / si nécessaire. (à moins que vous n’ayez 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 à la date d’avril 2015, DynamoDB était encore très handicapé quand il s’agissait de rien de plus que les requêtes clé / valeur les plus élémentaires. Je l’aime pour les trucs de base, mais si vous voulez un langage de requête, cherchez une vraie firebase database SQL.

Dans DynamoDB, vous pouvez interroger un hachage ou 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 parameters de filtre possibles et en sortingant les résultats, ceci est supporté (à peine) par l’utilisation des index secondaires globaux avec des expressions de filtre. Le problème survient lorsque vous essayez d’obtenir le résultat total 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 vous obligeant à continuer numérisation à partir de la clé continue – douleur dans le cou et consum trop de votre quota de lecture de table pour un scénario simple.

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

 Dans une réponse, DynamoDB renvoie tous les résultats correspondants dans
 la scope de la valeur limite.  Par exemple, si vous émettez une requête 
 ou une demande d'parsing avec une valeur limite de 6 et sans filtre
 expression, l'opération renvoie les six premiers éléments du 
 tableau correspondant aux parameters de la requête.  Si vous fournissez également un
 FilterExpression, l'opération retourne les éléments dans le 
 les six premiers éléments du tableau correspondant aux exigences du filtre.

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, ce qui consum beaucoup trop d’unités de lecture DynamoDB. Une fois que vous avez utilisé trop d’unités de lecture, vous êtes étranglé et vous constatez de mauvaises performances.

Opinion d’experts: Au sumt AWS du 9 avril 2015, Brett Hollman, directeur, Architecture de solutions, AWS, dans son exposé sur l’éclatement des 10 premiers millions d’utilisateurs, préconise de commencer avec une firebase database SQL, puis d’utiliser NoSQL uniquement lorsque cela est nécessaire. Parce que tôt ou tard, vous aurez probablement besoin d’un serveur SQL quelque part dans votre stack. 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 sa conformité à HIPAA est sans travail supplémentaire. Nous hébergeons donc la partie mongo sans données personnelles dans une configuration standard et autorisons amazon à 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 correspondant.

La principale raison pour laquelle nous avons choisi de le faire en utilisant mongo au lieu d’héberger l’application entière sur la dynamo était pour 2 raisons. Tout d’abord, nous devions effectuer des recherches basées sur l’emplacement, ce que mongo est génial à ce moment-là, mais 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 que l’utilisateur a un document dans la collection “form” comme ceci: {“username”: “user1″, ” email “: [email protected]“}. 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 dynamics et inconnus, avec Dynamo, vous pouvez le faire, mais vous devez créer un index chaque fois qu’un nouveau champ est ajouté à votre recherche. Donc, si vous n’avez jamais eu de champ téléphonique dans votre document Dynamo auparavant, puis soudainement, quelqu’un l’ajoute, c’est complètement impossible à trouver.

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

J’ai travaillé sur les deux et le genre de fan des deux.

Mais vous devez comprendre quand utiliser quoi et à quelle fin.

Je ne pense pas que ce soit une bonne idée de déplacer toute votre firebase database vers DynamoDB, la raison étant que l’interrogation est difficile sauf sur les clés primaires et secondaires. L’indexation est limitée et l’parsing dans DynamoDB est pénible.

Je choisirais une sorte de firebase database hybride, où de nombreuses données pouvant être interrogées devraient exister sous MongoDB, avec toutes ses fonctionnalités, vous ne vous sentiriez jamais obligé de fournir des améliorations ou des modifications.

DynamoDB est très rapide (plus rapide que MongoDB), donc DynamoDB est souvent utilisé comme alternative aux sessions dans les applications évolutives. Les meilleures pratiques de DynamoDB suggèrent également que si de nombreuses données sont moins utilisées, déplacez-les vers une autre table.

Alors, supposons que vous ayez des articles ou des stream. Les gens sont plus susceptibles de chercher les articles de la semaine dernière ou ceux de ce mois-ci. les chances sont vraiment rares que les personnes visitent 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ée dans différentes tables.

DynamoDB est sans aucun doute évolutif, ce 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 le fonctionnement de la mise à l’échelle.

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

Par exemple, vous pouvez avoir un jeu de réplicas de MongoDB de telle sorte que l’un des réplicas contienne une instance de données de 8 heures (ou peu importe). Vraiment utile, si vous avez gâché quelque chose de gros dans votre firebase database et que vous voulez obtenir les données comme avant.

C’est mon opinion cependant.

Gardez à l’esprit, j’ai seulement expérimenté avec MongoDB …

D’après ce que j’ai lu, DynamoDB a parcouru un long chemin en termes de fonctionnalités. Auparavant, il s’agissait d’un magasin clé-valeur de base 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 document plus importantes + support JSON et indices secondaires globaux . L’écart entre ce que propose DynamoDB et MongoDB en termes de fonctionnalités diminue avec chaque mois. Les nouvelles fonctionnalités de DynamoDB sont développées ici .

La plupart des comparaisons entre MongoDB et DynamoDB sont obsolètes en raison de l’ajout récent des fonctionnalités de DynamoDB. Cependant, cet article offre d’autres points convaincants pour choisir DynamoDB, à savoir qu’il est simple, nécessite peu de maintenance et est souvent peu coûteux. Une autre discussion sur les choix de bases de données était intéressante à lire, quoique légèrement ancienne.

Mon point à prendre: si vous effectuez des requêtes sérieuses sur des bases de données ou travaillez dans des langues non sockets en charge par DynamoDB, utilisez MongoDB. Sinon, restz avec DynamoDB.