Quand utiliser Redis ? quand utiliser MongoDB ?

Question

Ce que je veux, ce n'est pas une comparaison entre Redis et MongoDB. Je sais qu'ils sont différents, que les performances et l'API sont totalement différentes.

Redis est très rapide, mais l'API est très "atomique". MongoDB consomme plus de ressources, mais l'API est très facile à utiliser et j'en suis très satisfait.

Ils sont tous deux géniaux, je veux utiliser Redis dans le déploiement autant que possible, mais il est difficile à coder. Je veux utiliser MongoDB dans le développement autant que possible, mais il faut une machine coûteuse.

Alors que pensez-vous de l'utilisation des deux ? Quand choisir Redis ? Quand choisir MongoDB ?

Answer 1

Je dirais que cela dépend du type d'équipe de développement que vous êtes et des besoins de votre application.

Par exemple, s'il y a plus de interrogation de requis, cela signifie surtout plus de travail dans Redis, où vous pouvez utiliser différentes structures de données pour répondre à vos requêtes. La même chose est plus facile dans MongoDB. D'un autre côté, ce travail supplémentaire dans Redis sera très probablement rentable avec vitesse pure .

MongoDB offre la simplicité, un apprentissage beaucoup plus réduit pour les personnes ayant une expérience de SQL. Alors que Redis offre une approche non traditionnelle, d'où un apprentissage plus important mais une grande flexibilité.

Par exemple, A cache peut probablement être mieux implémentée dans Redis, et pour des données plus schématisables, MongoDB pourrait être mieux.

Si vous voulez mon avis, mon choix personnel se porte sur Redis pour la plupart des besoins.

Enfin, j'espère que vous êtes tombés sur ce site. http://antirez.com/post/MongoDB-and-Redis.html

Answer 2

Je viens de remarquer que cette question est assez ancienne. Néanmoins, je considère que les aspects suivants méritent d'être ajoutés :

• Utilisez MongoDB si vous ne savez pas encore comment vous allez interroger vos données.

  MongoDB est adapté aux Hackathons, aux startups ou à chaque fois que vous ne savez pas comment vous allez interroger les données que vous avez insérées. MongoDB ne fait aucune hypothèse sur votre schéma sous-jacent. Si MongoDB est sans schéma et non relationnel, cela ne signifie pas qu'il n'y a pas de schéma du tout. Cela signifie simplement que votre schéma doit être défini dans votre application (par exemple, à l'aide de Mongoose). En outre, MongoDB est idéal pour le prototypage et les essais. Ses performances ne sont pas très bonnes et ne peuvent pas être comparées à celles de Redis.

• Utilisez Redis afin d'accélérer votre application existante.

  Redis peut être facilement intégré en tant que Cache LRU . Il est très rare d'utiliser Redis comme un système de base de données autonome (certaines personnes préfèrent l'appeler "key-value" -store). Des sites web comme Craigslist utilisent Redis à côté de leur base de données principale . Antirez (développeur de Redis) a démontré à l'aide de Lamernews qu'il est effectivement possible d'utiliser Redis comme un système de base de données autonome.

• Redis ne fait aucune supposition sur la base de vos données.

  Redis fournit un grand nombre de structures de données utiles (par exemple, des ensembles, des hachages, des listes), mais vous devez définir explicitement comment vous voulez stocker vos données. Pour résumer, Redis et MongoDB peuvent être utilisés pour réaliser des choses similaires. Redis est simplement plus rapide, mais ne convient pas au prototypage. C'est un cas d'utilisation pour lequel vous préférerez typiquement MongoDB. En outre, Redis est vraiment flexible. Les structures de données sous-jacentes qu'il fournit sont les éléments constitutifs des systèmes de bases de données hautes performances.

Quand utiliser Redis ?

• Mise en cache

  La mise en cache à l'aide de MongoDB n'a tout simplement pas beaucoup de sens. Elle serait trop lente.

• Si vous avez suffisamment de temps pour réfléchir à la conception de votre BD.

  Vous ne pouvez pas simplement jeter vos documents dans Redis. Vous devez penser à la manière dont vous voulez stocker et organiser vos données. Un exemple sont les hachages dans Redis. Ils sont très différents des objets imbriqués "traditionnels", ce qui signifie que vous devrez repenser la façon dont vous stockez les documents imbriqués. Une solution serait de stocker une référence à l'intérieur du hash vers un autre hash (quelque chose comme clé : [id du deuxième hachage] ). Une autre idée serait de les stocker en JSON, ce qui semble contre-intuitif pour la plupart des personnes ayant une formation *SQL.

• Si vous avez besoin vraiment haute performance.

  Battre les performances fournies par Redis est presque impossible. Imaginez que votre base de données soit aussi rapide que votre cache. C'est ce que l'on ressent en utilisant Redis en tant que réel base de données.

• Si vous ne vous souciez pas que beaucoup sur la mise à l'échelle.

  La mise à l'échelle de Redis n'est plus aussi difficile qu'avant. Par exemple, vous pouvez utiliser une sorte de serveur proxy afin de répartir les données entre plusieurs instances Redis. La réplication maître-esclave n'est pas que Ce n'est pas compliqué, mais la distribution de vos clés entre plusieurs instances Redis doit être effectuée sur le site de l'application (par exemple en utilisant une fonction de hachage, Modulo, etc.). En comparaison, la mise à l'échelle de MongoDB est beaucoup plus simple.

Quand utiliser MongoDB

• Prototypage, Startups, Hackathons

  MongoDB est parfaitement adapté au prototypage rapide. Néanmoins, les performances ne sont pas très bonnes. Gardez également à l'esprit que vous devrez très probablement définir une sorte de schéma dans votre application.

• Lorsque vous devez modifier votre schéma rapidement.

  Parce qu'il n'y a pas de schéma ! La modification des tables dans les SGBD relationnels traditionnels est douloureusement coûteuse et lente. MongoDB résout ce problème en ne faisant pas beaucoup d'hypothèses sur vos données sous-jacentes. Néanmoins, il essaie d'optimiser autant que possible sans vous demander de définir un schéma.

TL;DR - Utilisez Redis si les performances sont importantes et si vous êtes prêt à passer du temps à optimiser et organiser vos données. - Utilisez MongoDB si vous avez besoin de construire un prototype sans trop vous soucier de votre base de données.

Pour en savoir plus :

• Aspects intéressants à prendre en compte lors de l'utilisation Redis comme magasin de données principal

Answer 3

Cette ressource peut peut-être vous aider à choisir entre les deux. Elle aborde également plusieurs autres bases de données NoSQL, et propose une courte liste de caractéristiques, ainsi qu'une liste d'exemples de bases de données. "ce à quoi je l'utiliserais" explication pour chacun d'entre eux.

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Answer 4

Difficile de répondre à cette question - comme pour la plupart des solutions technologiques, cela dépend vraiment de votre situation et puisque vous n'avez pas décrit le problème que vous essayez de résoudre, comment peut-on proposer une solution ?

Vous devez les tester tous les deux pour voir lequel des deux satisfaits votre besoins.

Cela dit, MongoDB ne nécessite pas de matériel coûteux. Comme toute autre solution de base de données, elle fonctionnera mieux avec plus de CPU et de mémoire, mais ce n'est certainement pas une obligation, surtout pour les premiers développements.