Question Quand à Redis? Quand MongoDB? [fermé]


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

Redis est très rapide, mais l’API est très «atomique». MongoDB va manger plus de ressources, mais l'API est très facile à utiliser et j'en suis très content.

Ils sont tous deux géniaux, et je veux utiliser Redis en déploiement autant que possible, mais c'est difficile à coder. Je veux utiliser MongoDB en 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?


467


origine


Réponses:


Je dirais que cela dépend du type d'équipe de développement et de l'application dont vous avez besoin.

Par exemple, si vous avez besoin de beaucoup de interroger, cela signifie principalement que vos développeurs utiliseront davantage Redis, où vos données pourraient être stockées dans diverses structures de données spécialisées, personnalisées pour chaque type d'objet pour plus d'efficacité. Dans MongoDB, les mêmes requêtes peuvent être plus faciles car la structure est plus cohérente pour toutes vos données. Par contre, à Redis, vitesse pure La 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 cache La couche peut probablement être mieux implémentée dans Redis. Pour des données plus schématisables, MongoDB est meilleur. [Note: MongoDB et Redis sont techniquement schemaless]

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

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


310



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 vous allez 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). En plus de cela, MongoDB est parfait pour le prototypage ou l'expérimentation. Ses performances ne sont pas si bonnes et ne peuvent être comparées à Redis.

  • Utilisez Redis pour accélérer votre application existante.

    Redis peut être facilement intégré en tant que LRU cache. Il est très rare d'utiliser Redis comme un système de base de données autonome (certaines personnes préfèrent le désigner comme un magasin "à valeur-clé"). Sites Web comme l'utilisation de Craigslist 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 en effet possible d'utiliser Redis en tant que système de base de données autonome.

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

    Redis fournit un tas de structures de données utiles (par exemple, Sets, Hashes, Lists), 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 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 qu'il fournit sont les blocs de construction des systèmes de base de données haute performance.

Quand utiliser Redis?

  • Mise en cache

    La mise en cache avec MongoDB n'a tout simplement pas beaucoup de sens. Ce serait trop lent.

  • Si vous avez le temps de réfléchir à votre conception de base de données.

    Vous ne pouvez pas simplement jeter vos documents dans Redis. Vous devez penser à la façon dont vous voulez stocker et organiser vos données. Un exemple sont les hachages dans Redis. Ils sont assez 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 hachage à un autre hachage (quelque chose comme clé: [identifiant du deuxième hachage]). Une autre idée serait de le stocker en JSON, ce qui semble contre-intuitif pour la plupart des gens avec un fond * SQL.

  • Si tu as besoin vraiment haute performance.

    Battre la performance Redis fournit est presque impossible. Imaginez que votre base de données soit aussi rapide que votre cache. C'est ce que l'on ressent lorsqu'on utilise Redis comme réal base de données.

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

    Redis n'est pas aussi difficile qu'auparavant. Par exemple, vous pouvez utiliser un type de serveur proxy afin de distribuer les données entre plusieurs instances Redis. La réplication maître-esclave n'est pas cette compliqué, mais la distribution des clés entre 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, les performances ne sont pas très bonnes. Gardez également à l'esprit 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! Modifier les tables dans un SGBD relationnel traditionnel est douloureusement coûteux et lent. 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 vous êtes prêt à consacrer du temps à l'optimisation et à l'organisation de vos données. - Utilisez MongoDB si vous avez besoin de construire un prototype sans trop vous soucier de votre base de données.

En lire plus:


236



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 si lent, "Je vais perdre mes fans parce qu'ils n'attendront pas 10 secondes pour une page." Vous avez soudainement réalisé qu'une page web a une URL constante (elle ne change jamais, whoa), une clé primaire si vous voulez, et ensuite vous vous souvenez que la mémoire est rapide alors que le disque est lent et que php est encore plus lent. :( Ensuite, vous créez un mécanisme de stockage 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" 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 crap.Vous êtes heureux.Vous voyez alors que d'autres l'ont fait - mais vous choisissez Redis parce que le un autre a des images confuses de chats, certains avec des crocs.

Mongo. Vous avez écrit un site. Zut 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, pourtant vous êtes là, en train d'écrire des déclarations stupides de sql ... pas seulement une, mais un peu partout. "sélectionnez ceci, sélectionnez ça". Mais en particulier, vous vous souvenez de l'irritante clause 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 pas leur travail et me donnent des procédures stockées?" Ensuite, vous oubliez un champ mineur comme middlename, puis vous devez supprimer la table, exporter toutes les 10G de données volumineuses et en créer une autre avec ce nouveau champ, puis importer les données - et cela se produit 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 imaginez que le nom de famille 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 SQL, s'il vous plaît pas de SQL, faites-le arrêter" mais up pops 'nosql' et puis vous lisez quelques trucs et il dit qu'il vide les données sans aucun schéma. Vous vous souvenez du fiasco de la semaine dernière qui a fait 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.


223



Peut-être que cette ressource est utile pour aider à décider entre les deux. Il traite également de plusieurs autres bases de données NoSQL et propose une courte liste de caractéristiques, ainsi qu'un "Ce que je voudrais l'utiliser pour" explication pour chacun d'eux.

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


16



Question difficile à répondre - comme avec 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 quelqu'un peut-il proposer une solution?

Vous devez les tester tous les deux pour voir lesquels d'entre eux sont satisfaits votre Besoins.

Cela dit, MongoDB ne nécessite aucun matériel coûteux. Comme toute autre solution de base de données, 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.


11



Redis est un en mémoire magasin de données, qui peut persister c'est l'état sur le disque (pour activer la récupération après le redémarrage). Toutefois, étant un magasin 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 que cela, comme Redis partage cet espace avec de nombreux autres processus sur le système, et si elle épuise l'espace mémoire du système, il sera probablement tué par le système d'exploitation.

Mongo est un basé sur le disque magasin de données, qui est le plus efficace quand il est ensemble de travail s'intègre dans la RAM physique (comme tous les logiciels). Être un données sur disque signifie qu'il n'y a pas de limites intrinsèques à la taille d'une base de données mongó cependant les options de configuration, l'espace disque disponible, et d'autres problèmes peuvent signifier que les bases tailles sur une certaine limite peuvent devenir impraticables ou inefficaces.

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


10



Toutes les réponses (au moment de cette écriture) assument chacun des Redis, MongoDB, et peut-être une base de données relationnelle basée sur SQL sont essentiellement le même outil: « stocker des 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. Pour comparer avec une base de données 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 sont de structure similaire aux 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, des tableaux ou des 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 de 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 a également un tableau de Accounts qui contiennent plusieurs index. Il est possible de demander un document où Accounts contient exactement un sous-ensemble de valeurs, tout d'un sous-ensemble de valeurs, ou tout de certains sous-ensembles de valeurs. Cela signifie que vous pouvez rechercher Accounts = ["379-1111", "379-2574"] et ne trouve pas ce qui précède vous pouvez rechercher Accounts includes ["379-1111"] et trouvez le document ci-dessus; et vous pouvez rechercher Accounts includes any of ["974-3785","414-6731"] et trouver le document ci-dessus et quel que soit le compte "974-3785", le cas échéant.

Les documents vont aussi loin que vous le souhaitez. PhoneNumber.Mobile pourrait contenir un tableau, ou même 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 essentiellement plates, relationnelles et structurées de manière rigide, il est préférable d'utiliser une base de données relationnelle. Encore une fois, le grand signe est de savoir si vos données sont les meilleures pour une collection de fichiers CSV interdépendants 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 une large gamme de données (plusieurs colonnes, les lignes ne sont pas pertinentes), il est logique 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 base de données graphique (où les données sont placées dans des nœuds, et 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 portée et la relation des données sont confrontées à des handicaps importants si elles sont regroupées sous un même modèle.

Redis: valeur-clé

Redis est, fondamentalement, un magasin de valeurs-clés. 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 voudrez éviter des centaines de recherches excessives dans un back-end, mais vous devrez déterminer quand vous aurez besoin d'une nouvelle recherche.

Le cas le plus évident d'invalidation est la mise à jour à l'écriture: si vous lisez user:Simon:lingots = NOTFOUND, Tu pourrais SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simon et stocker le résultat, 100, comme SET user:Simon:lingots = 100. Ensuite, quand vous attribuez Simon 5 lingots, vous lisez 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. Vous avez maintenant 105 dans votre base de données et dans Redis, et vous pouvez obtenir user:Simon:lingots sans interroger la base de données.

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 acquiert de l'expérience. Eh bien, maintenant vous avez plusieurs templates:Header:Simon, templates:StatsBox:Simon, templates:GrowthGraph:Simon, et ainsi de suite champs où vous avez mis en cache la sortie d'une demi-douzaine de requêtes de base de données à travers un moteur de modèle. Normalement, lorsque vous affichez ces pages, vous dites:

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

Parce que vous venez de mettre à jour les résultats de GetStatsFromDatabase("Simon"), vous devez laisser tomber templates:*:Simon hors de votre cache de valeur-clé. Lorsque vous essayez de rendre n'importe lequel de ces modèles, votre application récupère les données de votre base de données (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 faire des requêtes de base de données 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 Redis est un cache de valeur-clé, qui diffère d'une base de données 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 les performances, les endroits où vous écrivez tout dans un mélange de C et d'assemblage; La plupart des applications gèrent uniquement le cas généralisé et utilisent un système de mise en cache tel que Redis ou Memcached, qui est beaucoup plus rapide qu'une base de données SQL haute performance ou un magasin de documents.


10



Et vous ne devriez pas utiliser non plus 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 aussi vrai. MongoDB (si je me souviens bien) prétend battre memcache pour stocker et mettre en cache des documents tant que les configurations de la 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 préoccupation principale, tout est à propos de Redis. (ou tout autre magasin de valeur clé).


2



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

Redis est une base de données clé / valeur, et il utilise le stockage en mémoire qui le rend très rapide. C'est un bon candidat pour la mise en cache et le stockage temporaire des données (en mémoire) et comme la plupart des plates-formes cloud (comme Azure, AWS) le supportent, l'utilisation de la mémoire est évolutive.Mais si vous allez l'utiliser sur vos machines ressources limitées, considérez l'utilisation de la mémoire.

MongoDB, d'autre part, est une base de données 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é. Il est évolutif avec une stratégie de scale-out. Il utilise le disque comme support de stockage, les données seraient donc conservées.


2



Si votre projet a été modifié, vous avez suffisamment de mémoire vive sur votre environnement. La réponse est Redis. Notamment en prenant en compte les nouvelles fonctionnalités de Redis 3.2 avec cluster.


1