DynamoDB vs MongoDB NoSQL
J'essaie de comprendre ce que je peux utiliser pour un futur projet. Nous prévoyons de stocker environ 500 000 enregistrements par mois la première année et peut-être davantage pour les prochaines années. 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 bénéficiant de l’appui de la communauté, mais de l’autre côté, nous avons un tout nouveau produit offrant un service géré de haute performance, je vais développer ce logiciel. application, mais il n’existe pas de plan de maintenance (du moins pour le moment), je pense donc que ce sera un énorme avantage, car Amazon offre une manière flexible de s’adapter à l’échelle.
Ma principale préoccupation concerne la structure de la requête. Je n’ai pas encore examiné les fonctionnalités de requête dynamoDB, mais comme c’est un stockage k/v, j’estime 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 tout à fait apprécié.
J'ai récemment migré MongoDB vers DynamoDB et j'ai écrit 3 blogs pour partager une expérience et des données sur les performances, le coût.
Migration de MongoDB vers AWS DynamoDB + SimpleDB
Je sais que c'est vieux, mais ça revient quand on cherche la comparaison. Nous utilisions Mongo et avons presque entièrement migré vers Dynamo, notre premier choix à présent. 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 le PO a déclaré dans son commentaire: c’est facile. Vous ne devez vous occuper d'aucun serveur. Lorsque vous commencez à configurer une solution fragmentée en Mongo, cela devient compliqué. Vous pouvez vous adresser à 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 à jour 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 spécialisé, le dynamo est excellent.
Nous allons donc maintenant sur Dynamo par défaut. Mongo peut-être, si la structure de données est suffisamment compliquée pour le justifier, mais nous reviendrions probablement à une base de données SQL. Le dynamo est obtus, vous devez vraiment penser à 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’occuper de ça. Vous codez. C'est ça.
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. Par conséquent, 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 aussi l'endroit où vous pouvez trouver le plus d'assistance en ligne.
Pour les 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 uniquement lorsque/si nécessaire. (sauf si vous n'avez besoin de rien d'autre que de simples requêtes)
Mon expérience personnelle: je n’ai pas utilisé MongoDB pour les requêtes, mais à partir d’avril 2015, DynamoDB est encore très handicapé en ce qui concerne les requêtes clé/valeur les plus élémentaires. Je l’aime pour les choses de base, mais si vous voulez un langage de requête, choisissez une vraie 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 je trie les résultats, ceci est supporté (à 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. Il vérifie plutôt 10 éléments et vous pouvez obtenir 0 résultat valide, ce qui vous oblige à conserver numérisation à partir de la touche Continuer - Douleur au cou et consomme trop de votre quota de lecture de table pour un scénario simple.
Pour préciser le problème des 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 demande d'analyse avec une valeur limite de 6 et sans expression de filtre , L'opération renvoie les six premiers éléments de la table Qui correspondre aux paramètres de la demande. Si vous fournissez également un FilterExpression, l'opération renvoie les éléments figurant dans 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 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 surpris et constaterez des performances médiocres.
Opinion d'expert: lors du sommet AWS du 9 avril 2015, Brett Hollman, responsable de l'architecture des solutions chez AWS, a expliqué aux principaux 10 millions d'utilisateurs ses défenseurs en commençant par une base de données SQL, puis en utilisant NoSQL uniquement lorsque cela s'avérait judicieux. 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-tourvotre-first-10-million-users Voir la diapositive 28.
Nous avons choisi une combinaison de Mongo/Dynamo pour un produit de santé. Fondamentalement, le mongo permet une meilleure recherche, mais le Dynamo hébergé est génial 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 amènent des documents avec des pointeurs (ID) du document Dynamo pouvant être associé.
La raison principale pour laquelle nous avons choisi d'utiliser mongo au lieu d'accueillir l'intégralité de l'application sur dynamo était pour deux raisons. Premièrement, nous devions effectuer des recherches basées sur la localisation, ce qui est génial à l’époque et à l’époque, ce n’était pas le cas de Dynamo, 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 "formulaire" comme ceci: {"nom d'utilisateur": "utilisateur1", " email ":" [email protected] "}. Et un autre utilisateur le place dans la même collection {"phone": "813-555-3333", "location": [28.1234, -83.2342]}. Avec mongo, nous pouvons rechercher n’importe quel de ces champs dynamiques et inconnus à tout moment. Avec Dynamo, vous pouvez le faire, mais vous devez créer un index à chaque fois qu’un nouveau champ est ajouté et que vous souhaitez effectuer une recherche. Donc, si vous n'avez jamais eu de numéro de téléphone dans votre document Dynamo auparavant et que tout d'un coup, quelqu'un l'a ajouté, il est complètement impossible à 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 et utilisera le système que vous avez créé depuis plus de 10 ans. Utiliser une solution SaaS/IaaS suffisamment bonne pour faire le travail peut être une meilleure option, car vous pouvez compter sur Amazon pour entretenir et maintenir leurs systèmes à 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, car interroger est difficile, sauf sur les clés primaires et secondaires, l'indexation est limitée et l'analyse dans DynamoDB est pénible.
J'opterais pour une sorte de base de données hybride, où MongoDB devrait contenir de nombreuses données pouvant faire l'objet de requêtes, avec toutes ses fonctionnalités que vous ne vous sentiriez jamais obligé d'apporter des améliorations ou des modifications.
DynamoDB est ultra-rapide (plus rapide que MongoDB). DynamoDB est donc souvent utilisé comme alternative aux sessions d'applications évolutives. Les meilleures pratiques de DynamoDB suggèrent également que, s'il y a beaucoup de données moins utilisées, déplacez-les dans un autre tableau.
Supposons donc que vous avez des articles ou des flux. Les gens sont plus susceptibles de rechercher des trucs de la semaine dernière ou de ce mois-ci. les chances sont vraiment rares pour les personnes de consulter des données de deux ans. Pour ce faire, DynamoDB préfère que les données soient stockées par mois ou par année dans différentes tables.
DynamoDB est sans égal évolutif, ce que vous devrez faire manuellement dans MongoDB. Toutefois, si vous ne comprenez pas la partition de débit et le fonctionnement de la mise à l'échelle en arrière-plan, vous perdriez des performances de DynamoDB.
DynamoDB doit être utilisé lorsque la vitesse est essentielle, mais 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 autre). Vraiment utile, si vous avez raté quelque chose dans votre base de données et que vous voulez obtenir les données telles quelles.
C'est mon avis cependant.
N'oubliez pas que je n'ai expérimenté que 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 super-base de valeurs-clés avec des capacités de stockage et d'interrogation extrêmement limitées. Il a depuis pris de l'ampleur et prend désormais en charge formats de document plus importants + support JSON et index secondaires globaux . L'écart entre les fonctionnalités offertes par DynamoDB et MongoDB se réduit au fil des mois. Les nouvelles fonctionnalités de DynamoDB sont développées sur here .
Une grande partie des comparaisons entre 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 s’agit d’une solution simple, qui nécessite peu d’entretien et qui est souvent peu coûteuse. ne autre discussion ici des choix de bases de données était intéressant à lire, bien que légèrement ancien.
Ma conclusion: si vous faites des requêtes sérieuses dans la base de données ou travaillez dans des langues non prises en charge par DynamoDB, utilisez MongoDB. Sinon, restez avec DynamoDB.