Quels sont les avantages et les inconvénients de DynamoDB par rapport aux autres bases de données NoSQL?
Nous utilisons le complément de base de données MongoDB sur Heroku pour notre produit SaaS. Maintenant que Amazon a lancé DynamoDB, un service de base de données en nuage, je me demandais en quoi cela modifiait le paysage des offres NoSQL?
En particulier pour les services en nuage ou les fournisseurs SaaS, comment utiliser DynamoDB sera-t-il meilleur ou pire que MongoDB? Y at-il des coûts, des performances, une évolutivité, une fiabilité, des pilotes, des avantages pour la communauté, etc. de l’utilisation de l’un contre l’autre?
Pour commencer, il sera entièrement géré par l'équipe d'experts d'Amazon. Vous pouvez donc parier qu'il évoluera très bien avec pratiquement aucune contribution de l'utilisateur final (développeur).
En outre, depuis sa création et sa gestion par Amazon, vous pouvez supposer qu’ils l’ont conçue pour fonctionner très bien avec leur infrastructure, de sorte que vous pouvez être sûr que les performances seront excellentes. En plus d'être spécifiquement conçus pour leur infrastructure, ils ont choisi d'utiliser les disques SSD comme stockage. Ainsi, dès le début, le débit du disque sera nettement supérieur à celui des autres magasins de données sur AWS qui sont sauvegardés sur disque dur.
Je n'ai encore vu aucun pilote et je pense qu'il est trop tôt pour dire comment la communauté réagira à cela, mais je suppose qu'Amazon aura des pilotes pour toutes les langues les plus populaires et que la communauté recevra probablement ce message - et créera à son tour pilotes et outils supplémentaires.
Je pense que la principale différence à prendre en compte est que MongoDB est un logiciel que vous pouvez installer n’importe où (y compris chez AWS, un autre service cloud ou en interne) où DynamoDB est un SaaS disponible exclusivement en tant que service hébergé chez Amazon ). Si vous souhaitez conserver la possibilité d’héberger votre application en interne, DynamoDB n’est pas une option. Si l'hébergement en dehors d'AWS n'est pas une considération, DynamoDB doit alors être votre choix par défaut, à moins que des fonctionnalités très spécifiques ne soient prises en compte.
Le lien suivant contient un tableau qui résume les attributs de DynamoDB et de Cassandra:
http://www.datastax.com/dev/blog/Amazon-dynamodb
Un élément à améliorer dans DynamoDB afin de devenir plus utilisable est la possibilité d’indexer des colonnes autres que la clé primaire.
UPDATE 1 (06/04/2013)
Le 18/04/2013, Amazon a annoncé la prise en charge des index secondaires locaux, qui rend DynamoDB f génial:
Utiliser MongoDB via un add-on pour Heroku transforme également MongoDB en un produit SaaS.
En réalité, on comparerait le service qu'un fournisseur choisi a comparé à ce qu'Amazon peut offrir au lieu de comparer une solution de persistance à une autre.
C'est très difficile à faire. Chaque fournisseur aura différents niveaux de service à différents prix et on pourrait envisager l'option de le faire fonctionner localement sur son propre matériel à des fins de développement, une option bienvenue.
Je dois être honnête; J'étais très enthousiaste lorsque j'ai entendu parler de la nouvelle DynamoDB et j'ai assisté au webinaire hier. Cependant, il est si difficile de prendre une décision maintenant, car tout ce qu'ils ont dit était encore très vague; Je n'ai aucune idée des fonctions qui seront autorisées/utilisées par leur service.
Ce que je sais, c’est que la mise à l’échelle est gérée automatiquement; Ce qui est assez impressionnant, mais il y a encore tellement d'inconnues qu'il est difficile de vraiment faire une bonne analyse jusqu'à ce que tous les faits soient connus et que nous puissions commencer à les utiliser.
Jusqu'ici, je pense toujours que mongo fonctionne beaucoup mieux pour moi (personnellement) dans le projet sur lequel j'ai travaillé.
Comme pour la plupart des décisions en matière de régimes à prestations déterminées, il s'agira vraiment de décider, projet par projet, de ce qui convient le mieux à vos besoins.
J'attends anxieusement plus d'informations sur le produit, pour le moment, même s'il est en version bêta et que je ne quitterais pas le navire pour adopter le dernier et le plus important des tests uniquement :)
Je pense que l'une des principales différences entre DynamoDB et les autres offres NoSQL réside dans le débit alloué - vous payez pour un niveau de débit spécifique sur une table et si vous conservez vos données bien partitionnées, vous pouvez toujours vous attendre à ce que ce débit soit atteint. Ainsi, à mesure que la charge de votre application augmente, vous pouvez évoluer et maintenir vos performances plus ou moins constantes.
Amazon DynamoDB semble être une solution NoSQL assez décente. C'est rapide et facile à utiliser. Hormis le fait d'avoir un compte AWS, aucune installation ni maintenance ne sont nécessaires. Le jeu de fonctionnalités et l'API sont actuellement relativement petits comparés à MongoDB/CouchDB/Cassandra, mais je m'attendrais probablement à ce que cela grandisse avec le temps, à mesure que les commentaires de la communauté des développeurs sont reçus. À l’heure actuelle, tous les kits de développement logiciel AWS officiels incluent un client DynamoDB.
Avantages
- Lightning Fast (utilise des disques SSD en interne)
- Vraiment (vraiment) fiable. (les chances d'échec en écriture sont plus faibles)
- Mise à l'échelle transparente (pas besoin de faire du sharding manuel)
- Fonctionne comme un service Web (pas de serveur, pas de configuration, pas d'installation)
- Facilement intégré avec d'autres fonctionnalités AWS (peut stocker la table entière dans S3 ou utiliser EMR, etc.)
- La réplication étant gérée en interne, les risques de perte accidentelle de données sont négligeables.
Les inconvénients
- Interrogation très (très) limitée.
- La numérisation est pénible (je me souviens qu'une fois, une numérisation Java avait duré 6 heures)
- débit prédéfini, ce qui signifie qu'une augmentation soudaine au-delà du débit défini sera réduite.
- le débit est partitionné lorsque la table est fragmentée en interne. (Ce qui signifie que si vous avez un débit de 1000 et qu'il est partitionné en deux et si vous ne lisez que les dernières données (d'une partie), votre débit de lecture est de 500 uniquement)
- Aucune jointure, indexation limitée autorisée (essentiellement 2).
- Pas de vues, déclencheurs, scripts ou procédures stockées.
C'est vraiment une bonne alternative au stockage de session dans une application évolutive. Une autre utilisation intéressante serait la journalisation/audit dans un système étendu. NON préférable pour une application riche en fonctionnalités avec des améliorations ou modifications fréquentes.