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

Par exemple, si vous avez besoin de beaucoup d’ interrogations , cela signifie surtout que vos développeurs auront plus de mal à utiliser Redis, où vos données pourraient être stockées dans diverses structures de données spécialisées, personnalisées pour chaque type d’object. Dans MongoDB, les mêmes requêtes peuvent être plus faciles car la structure est plus cohérente pour toutes vos données. D’un autre côté, dans Redis, la rapidité de réponse à ces requêtes est le résultat du travail supplémentaire lié à la diversité des structures avec lesquelles vos données peuvent être stockées.

MongoDB offre une simplicité, une courbe d’apprentissage beaucoup plus courte pour les développeurs ayant une expérience DB et SQL traditionnelle. Cependant, l’approche non traditionnelle de Redis nécessite plus d’efforts pour apprendre, mais une plus grande flexibilité.

Par exemple. Une couche de cache peut probablement être mieux implémentée dans Redis. Pour plus de données schématiques, MongoDB est mieux. [Note: MongoDB et Redis sont techniquement sans schemal]

Si vous me demandez, mon choix personnel est Redis pour la plupart des exigences.

Enfin, j’espère que vous avez maintenant vu http://antirez.com/post/MongoDB-and-Redis.html

Je viens de remarquer que cette question est assez ancienne. Néanmoins, j’estime que les aspects suivants méritent d’être ajoutés:

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

  MongoDB convient aux hackathons, aux startups ou à chaque fois que vous ne savez pas comment interroger les données que vous avez insérées. MongoDB ne fait aucune hypothèse sur votre schéma sous-jacent. Bien que MongoDB soit sans schemaless 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, en utilisant Mongoose). De plus, MongoDB est idéal pour le prototypage ou les essais. Ses performances ne sont pas excellentes et ne peuvent être comparées à celles de Redis.

• Utilisez Redis pour 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 firebase database autonome (certaines personnes préfèrent l’utiliser comme magasin de clés). Des sites Web comme Craigslist utilisent Redis à côté de leur firebase database principale . Antirez (développeur de Redis) a démontré à l’aide de Lamernews qu’il est en effet possible d’utiliser Redis en tant que système de firebase database autonome.

• Redis ne fait aucune hypothèse basée sur vos données.

  Redis fournit un ensemble de structures de données utiles (par exemple, Ensembles, Hash, Listes), mais vous devez définir explicitement comment vous souhaitez stocker vos données. En résumé, Redis et MongoDB peuvent être utilisés pour obtenir des résultats similaires. Redis est simplement plus rapide, mais pas adapté au prototypage. C’est un cas d’utilisation où vous préférez généralement MongoDB. De plus, Redis est vraiment flexible. Les structures de données sous-jacentes fournies constituent les éléments constitutifs des systèmes de firebase database hautes performances.

Quand utiliser Redis?

• Mise en cache

  Caching utilisant MongoDB n’a tout simplement pas beaucoup de sens. Ce serait trop lent.

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

  Vous ne pouvez pas simplement jeter vos documents dans Redis. Vous devez penser à la manière dont vous souhaitez stocker et organiser vos données. Un exemple sont les hachages dans Redis. Ils sont très différents des objects “traditionnels” nesteds, ce qui signifie que vous devrez repenser la manière dont vous stockez les documents nesteds. Une solution serait de stocker une référence dans le hachage à un autre hachage (quelque chose comme la clé: [id of second hash] ). Une autre idée serait de le stocker en tant que JSON, ce qui semble contre-intuitif pour la plupart des gens ayant un fond * SQL.

• Si vous avez besoin de performances vraiment élevées.

  Battre la performance fournie par Redis est presque impossible. Imaginez que votre firebase database soit aussi rapide que votre cache. C’est ce que l’on ressent lorsqu’on utilise Redis comme une véritable firebase database.

• Si vous ne vous souciez pas autant de la mise à l’échelle.

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

Quand utiliser MongoDB

• Prototypage, Startups, Hackathons

  MongoDB est parfaitement adapté au prototypage rapide. Néanmoins, la performance n’est pas très bonne. N’oubliez pas que vous devrez probablement définir une sorte de schéma dans votre application.

• Lorsque vous devez changer votre schéma rapidement.

  Parce qu’il n’y a pas de schéma! La modification des tables dans les SGBD relationnels traditionnels est extrêmement 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 obliger à définir un schéma.

TL; DR – Utilisez Redis si les performances sont importantes et que vous souhaitez 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 firebase database.

Lectures complémentaires:

• Aspects intéressants à prendre en compte lors de l’utilisation de Redis en tant que magasin de données primaire

Redis. Disons que vous avez écrit un site en php; pour une raison quelconque, il devient populaire et il est en avance sur son temps ou a du porno sur lui. Vous vous rendez compte que ce php est tellement lent, “je vais perdre mes fans parce qu’ils n’attendent tout simplement pas 10 secondes pour une page.” Vous réalisez soudain qu’une page Web a une URL constante (elle ne change jamais, whoa), une clé primaire si vous voulez, et vous vous rappelez que la mémoire est rapide lorsque le disque est lent et que php est encore plus lent. 🙁 Ensuite, vous façonnez un mécanisme de stockage en utilisant la mémoire et cette URL que vous appelez une “clé” tandis que le contenu de la page Web que vous décidez d’appeler la “valeur”. C’est tout ce que vous avez – clé et contenu. Vous aimez Richard Dawkins parce qu’il est génial, vous cachez votre code HTML comme les écureuils cachent leurs noix, vous n’avez pas besoin de réécrire votre code php, vous êtes heureux, vous voyez que d’autres l’ont fait – mais vous choisissez Redis un autre a des images confuses de chats, certains avec des crocs.

Mongo. Vous avez écrit un site. Vous avez écrit beaucoup, et dans n’importe quelle langue. Vous vous rendez compte qu’une grande partie de votre temps est consacrée à l’écriture de ces clauses SQL nauséabondes. Vous n’êtes pas un dba, et pourtant vous êtes en train d’écrire des déclarations SQL stupides … pas juste une mais paniquer partout. “sélectionnez cette option, sélectionnez-la”. Mais en particulier, vous vous souvenez de la clause irritante WHERE. Où le nom de famille est égal à “thornton” et le film est égal à “mauvais père”. Urgh. Vous pensez, “pourquoi ces dbas ne font-ils que leur travail et me donnent des procédures stockées?” Ensuite, vous oubliez un champ mineur comme middlename, puis vous devez laisser tomber la table, exporter toutes les 10G de big data et en créer une autre avec ce nouveau champ et importer les données – cela se passe 10 fois au cours des 14 prochains jours. Continuez à vous souvenir des conneries comme les salutations, les titres et en ajoutant une clé étrangère avec des adresses. Ensuite, vous pensez que lastname devrait être lastName. Presque un changement par jour. Alors vous dites darnit. Je dois commencer et écrire un site Web / système, peu importe ce modèle de données bs. Donc, vous google, “je déteste écrire du SQL, s’il vous plaît pas de SQL, faites-le s’arrêter” mais apparaît “nosql” et ensuite vous lisez des trucs et il dit juste des données sans aucun schéma. Vous vous souvenez du fiasco de la semaine dernière en laissant tomber plus de tables et de sourire. Ensuite, vous choisissez mongo parce que certains grands comme “airbud” le site de location apt l’utilise. Doux. Plus aucun modèle de données ne change car vous avez un modèle que vous continuez à changer.

Peut-être que cette ressource est utile pour aider à décider entre les deux. Il aborde également plusieurs autres bases de données NoSQL, et propose une courte liste de caractéristiques, accompagnée d’une explication de «ce que je voudrais l’utiliser» pour chacune d’elles.

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

Question difficile à répondre – comme pour la plupart des solutions technologiques, cela dépend vraiment de votre situation et comme 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 lesquels répondent à vos besoins.

Cela dit, MongoDB ne nécessite aucun matériel coûteux. Comme toute autre solution de firebase database, elle fonctionnera mieux avec davantage de processeurs et de mémoire, mais n’est certainement pas une nécessité, en particulier pour les premiers développements.

Redis est un magasin de données en mémoire , qui peut persister dans son état sur le disque (pour permettre la récupération après le redémarrage). Cependant, être un stockage de données en mémoire signifie que la taille du magasin de données (sur un seul nœud) ne peut pas dépasser l’espace mémoire total sur le système (RAM physique + espace d’échange). En réalité, ce sera beaucoup moins le cas, car Redis partage cet espace avec de nombreux autres processus sur le système, et s’il épuise l’espace mémoire du système, il sera probablement supprimé par le système d’exploitation.

Mongo est un magasin de données sur disque , qui est le plus efficace lorsqu’il fonctionne dans la RAM physique (comme tous les logiciels). Etre une firebase database sur disque signifie qu’il n’ya pas de limites insortingnsèques à la taille d’une firebase database Mongo. Toutefois, les options de configuration, l’espace disque disponible et d’autres problèmes peuvent

Redis et Mongo peuvent être regroupés pour assurer la haute disponibilité, la sauvegarde et augmenter la taille globale du magasin de données.

Toutes les réponses (au moment de la rédaction de cet article) supposent que Redis, MongoDB et peut-être une firebase database relationnelle basée sur SQL sont essentiellement le même outil: “stocker les données”. Ils ne considèrent pas les modèles de données du tout.

MongoDB: données complexes

MongoDB est un magasin de documents. Comparer avec une firebase database relationnelle pilotée par SQL: les bases de données relationnelles simplifient les fichiers CSV indexés, chaque fichier étant une table; les magasins de documents simplifient les fichiers JSON indexés, chaque fichier étant un document, avec plusieurs fichiers regroupés.

Les fichiers JSON ont une structure similaire à celle des fichiers XML et YAML, et aux dictionnaires comme en Python. Pensez donc à vos données dans ce type de hiérarchie. Lors de l’indexation, la structure est la clé: un document contient des clés nommées, qui contiennent d’autres documents, tableaux ou valeurs scalaires. Considérez le document ci-dessous.

 { _id: 0x194f38dc491a, Name: "John Smith", PhoneNumber: Home: "555 999-1234", Work: "555 999-9876", Mobile: "555 634-5789" Accounts: - "379-1111" - "379-2574" - "414-6731" } 

Le document ci-dessus a une clé, PhoneNumber.Mobile , qui a la valeur 555 634-5789 . Vous pouvez rechercher dans une collection de documents où la clé, PhoneNumber.Mobile , a une certaine valeur; ils sont indexés.

Il possède également un tableau de Accounts contenant plusieurs index. Il est possible d’interroger un document où Accounts contient exactement un sous-ensemble de valeurs, un sous-ensemble de valeurs ou un sous-ensemble de valeurs. Cela signifie que vous pouvez rechercher des Accounts = ["379-1111", "379-2574"] et ne pas trouver ce qui précède; vous pouvez rechercher des Accounts includes ["379-1111"] et trouver le document ci-dessus; et vous pouvez rechercher des Accounts includes any of ["974-3785","414-6731"] et trouvez le document ci-dessus et n’importe quel document incluant le compte “974-3785”, le cas échéant.

Les documents vont aussi loin que vous le souhaitez. PhoneNumber.Mobile peut contenir un tableau, voire un sous-document ( PhoneNumber.Mobile.Work et PhoneNumber.Mobile.Personal ). Si vos données sont hautement structurées, les documents sont une étape importante par rapport aux bases de données relationnelles.

Si vos données sont généralement plates, relationnelles et structurées de manière rigide, vous avez intérêt à utiliser une firebase database relationnelle. Encore une fois, le grand signe est de savoir si vos données modélisent au mieux une collection de fichiers CSV liés entre eux ou une collection de fichiers XML / JSON / YAML.

Pour la plupart des projets, vous devrez faire des compromis, en acceptant une solution de rechange mineure dans certaines petites zones où SQL ou les magasins de documents ne correspondent pas; Pour certains grands projets complexes stockant un large éventail de données (de nombreuses colonnes, les lignes ne sont pas pertinentes), il serait judicieux de stocker certaines données dans un modèle et d’autres données dans un autre modèle. Facebook utilise à la fois SQL et une firebase database graphique (où les données sont placées dans des nœuds et où les nœuds sont connectés à d’autres nœuds). Craigslist utilisait MySQL et MongoDB, mais cherchait à se déplacer entièrement sur MongoDB. Ce sont des endroits où la scope et la relation des données sont confrontées à des handicaps importants si elles sont regroupées sous un seul modèle.

Redis: Valeur-clé

Redis est, au fond, un magasin clé-valeur. Redis vous permet de lui donner une clé et de rechercher une valeur unique. Redis lui-même peut stocker des chaînes, des listes, des hachages et quelques autres choses. Cependant, il ne fait que rechercher son nom.

L’invalidation du cache est l’un des problèmes difficiles de l’informatique; l’autre nomme les choses. Cela signifie que vous utiliserez Redis lorsque vous voulez éviter des centaines de recherches excessives sur votre back-end, mais vous devrez déterminer à quel moment vous avez besoin d’une nouvelle recherche.

Le cas d’invalidation le plus évident est la mise à jour à l’écriture: si vous lisez l’ user:Simon:lingots = NOTFOUND , vous pouvez SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simon et stocker le result, 100 , comme SET user:Simon:lingots = 100 . Ensuite, lorsque vous atsortingbuez 5 lingots à Simon, vous lisez l’ user:Simon:lingots = 100 , SET user:Simon:lingots = 105 , et UPDATE Store s INNER JOIN UserProfile u ON s.UserID = u.UserID SET s.Lingots = 105 WHERE u.Username = Simon . Maintenant, vous avez 105 dans votre firebase database et dans Redis, et vous pouvez obtenir l’ user:Simon:lingots sans interroger la firebase database.

Le second cas met à jour les informations dépendantes. Disons que vous générez des morceaux d’une page et mettez leur sortie en cache. L’en-tête indique l’expérience, le niveau et la quantité d’argent du joueur. la page Profil du joueur contient un bloc qui affiche ses statistiques; et ainsi de suite. Le joueur gagne de l’expérience. Eh bien, maintenant vous avez plusieurs templates:Header:Simon , templates:StatsBox:Simon , templates:GrowthGraph:Simon , etc. où vous avez mis en cache la sortie d’une demi-douzaine de requêtes de firebase database exécutées par un moteur de template. Normalement, lorsque vous affichez ces pages, vous dites:

 $t = GetSsortingngFromRedis("templates:StatsBox:" + $playerName); if ($t == null) { $t = BuildTemplate("StatsBox.tmpl", GetStatsFromDatabase($playerName)); SetSsortingngInRedis("Templates:StatsBox:" + $playerName, $t); } print $t; 

Comme vous venez de mettre à jour les résultats de GetStatsFromDatabase("Simon") , vous devez supprimer les templates:*:Simon hors de votre cache valeur-clé. Lorsque vous essayez de rendre l’un de ces modèles, votre application récupère les données de votre firebase database (PostgreSQL, MongoDB) et les insère dans votre modèle. Ensuite, il stockera le résultat dans Redis et, espérons-le, ne prendra pas la peine de créer des requêtes de firebase database et des modèles de rendu la prochaine fois qu’il affichera ce bloc de sortie.

Redis vous permet également de faire des files d’attente de messages avec abonnement éditeur, etc. C’est un autre sujet entièrement. Le point ici est que Redis est un cache de valeur-clé, qui diffère d’une firebase database relationnelle ou d’un magasin de documents.

Conclusion

Choisissez vos outils en fonction de vos besoins. Le plus grand besoin est généralement le modèle de données, car cela détermine la complexité et la vulnérabilité de votre code. Les applications spécialisées s’appuieront sur la performance, des endroits où vous écrivez tout dans un mélange de C et d’Assemblée; La plupart des applications se contentent de gérer le cas généralisé et d’utiliser un système de mise en cache tel que Redis ou Memcached, qui est beaucoup plus rapide qu’une firebase database SQL hautes performances ou un magasin de documents.

Et vous ne devriez pas utiliser si vous avez beaucoup de RAM. Redis et MongoDB viennent au prix d’un outil généraliste. Cela introduit beaucoup de frais généraux.

Il y avait le dicton que Redis est 10 fois plus rapide que Mongo. Cela pourrait ne plus être vrai. MongoDB (si je me souviens bien) a déclaré avoir battu memcache pour stocker et mettre en cache des documents tant que les configurations de mémoire sont les mêmes.

De toute façon. Redis bon, MongoDB est bon. Si vous vous souciez des sous-structures et que vous avez besoin d’agrégation, optez pour MongoDB. Si le stockage des clés et des valeurs est votre principale préoccupation, c’est tout à propos de Redis. (ou tout autre magasin de valeur clé).

Redis et MongoDB sont deux bases de données non relationnelles, mais elles appartiennent à des catégories différentes.

Redis est une firebase database Key / Value, qui utilise le stockage en mémoire, ce qui la rend extrêmement rapide. C’est un bon candidat pour la mise en cache d’objects et le stockage de données temporaire (en mémoire) et comme la plupart des plates-formes cloud (telles qu’Azure, AWS) le prennent en charge, son utilisation de la mémoire est évolutive. ressources limitées, considérez l’utilisation de la mémoire.

MongoDB est une firebase database de documents. C’est une bonne option pour conserver de gros textes, des images, des vidéos, etc. et presque tout ce que vous faites avec des bases de données, à l’exception des transactions. Par exemple, si vous souhaitez développer un blog ou un réseau social, MongoDB est un choix approprié. C’est évolutif avec la stratégie de montée en charge. Il utilise le disque comme support de stockage, de sorte que les données seraient conservées.

Si votre projet a été modifié, vous avez suffisamment de mémoire vive sur votre environnement. La réponse est Redis. En particulier en tenant compte de la nouvelle version de Redis 3.2 avec la fonctionnalité de cluster.