Quand redis? Quand faire MongoDB?
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érents.
Redis est très rapide, mais l'API est très "atomique". MongoDB consommera plus de ressources, mais l’API est très très facile à utiliser, et j’en suis très heureux.
Ils sont tous les deux géniaux et je veux utiliser Redis autant que possible en déploiement, mais c'est difficile à coder. Je souhaite utiliser MongoDB en développement autant que je le peux, mais cela nécessite une machine coûteuse.
Alors, que pensez-vous de l'utilisation des deux? Quand choisir Redis? Quand choisir MongoDB?
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 de querying, cela signifie généralement que vos développeurs auront davantage de travail à 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'objet pour l'efficacité. Dans MongoDB, les mêmes requêtes pourraient être plus faciles, car la structure est plus cohérente dans vos données. D'autre part, dans Redis, la vitesse de la réponse à ces questions est la récompense du travail supplémentaire que représente la gestion de la variété de structures dans lesquelles vos données peuvent être stockées.
MongoDB offre une simplicité, une courbe d’apprentissage beaucoup plus courte pour les développeurs expérimentés en bases de données et SQL. Cependant, l'approche non traditionnelle de Redis nécessite plus d'efforts d'apprentissage, mais une plus grande flexibilité.
Par exemple. Une couche cache peut probablement être mieux implémentée dans Redis. MongoDB, c'est mieux. [Note: MongoDB et Redis sont techniquement sans schèmes]
Si vous me le demandez, mon choix personnel est Redis pour la plupart des besoins.
Enfin, j'espère que vous avez déjà 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 vous allez 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 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, en utilisant Mongoose). En outre, MongoDB est idéal pour le prototypage ou l’essai. 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 cache LR . Il est très rare d'utiliser Redis en tant que système de base de données autonome (certaines personnes préfèrent s'y référer en tant que magasin "clé-valeur"). Des sites Web comme Craigslist utilisent Redis situé à côté de leur base de données principale . Antirez (développeur de Redis) a démontré à l'aide de Lamernews qu'il était effectivement 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 ensemble de structures de données utiles (ensembles, hachages, listes, par exemple), mais vous devez définir explicitement comment vous souhaitez stocker vos données. En résumé, Redis et MongoDB peuvent être utilisés pour réaliser des choses similaires. Redis est tout simplement plus rapide, mais ne convient pas au prototypage. C'est un cas d'utilisation où vous préférez généralement MongoDB. En plus de cela, Redis est vraiment flexible. Les structures de données sous-jacentes qu'il fournit sont les éléments constitutifs de systèmes DB hautes performances.
Quand utiliser Redis?
Caching
Mettre en cache en utilisant MongoDB n'a tout simplement pas de sens. Ce serait trop lent.
Si vous avez assez de temps pour réfléchir à votre conception de base de données.
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 hashes à Redis. Ils sont assez différents des objets "traditionnels", imbriqués, 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 dans le hachage vers un autre hachage (quelque chose comme la clé : [id of second hash] ). Une autre idée serait de le stocker au format JSON, ce qui semble contre-intuitif pour la plupart des personnes possédant un * arrière-plan SQL.
Si vous avez besoin vraiment de hautes performances.
Battre la performance fournie 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 lorsque l'on utilise Redis comme base de données réelle .
Si vous ne vous souciez pas de ce que beaucoup sur la mise à l'échelle.
Redisquer n'est plus aussi difficile qu'avant. Par exemple, vous pouvez utiliser un type de serveur proxy pour répartir les données entre plusieurs instances Redis. La réplication maître-esclave n’est pas aussi compliquée , mais la distribution de vos clés entre plusieurs instances Redis doit être effectuée sur le site de l’application (par exemple, à l’aide d’une fonction de hachage, de Modulo, etc.). Mettre à l'échelle 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 si bonnes. N'oubliez pas non plus que vous devrez probablement définir une sorte de schéma dans votre application.
Lorsque vous avez besoin de changer votre schéma rapidement.
Parce qu'il n'y a pas de schéma! Modifier des tables dans un SGBD relationnel traditionnel est douloureusement lent et coûteux. 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 si vous êtes prêt à consacrer du temps à l'optimisation et à l'organisation de vos données. - Utilisez MongoDB si vous devez construire un prototype sans trop vous préoccuper de votre base de données.
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 elle. Vous réalisez que ce php est tellement lent: "Je vais perdre mes fans parce qu'ils n'attendront tout simplement pas une page pendant 10 secondes". Vous réalisez soudainement qu'une page Web a une URL constante (elle ne change jamais, whoa), une clé primaire si vous le souhaitez, puis vous vous rappelez que la mémoire est rapide lorsque le disque est lent et php 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". C'est tout ce que vous avez - la clé et le contenu. Vous l'appelez "cache mémoire Vous aimez Richard Dawkins parce qu’il est génial. Vous cachez votre code HTML comme les écureuils dissimulent leurs noix. Vous n'avez pas besoin de réécrire votre code php pour merde. Vous êtes heureux. l'autre a des images déroutantes de chats, certaines avec des crocs.
Mongo. Vous avez écrit un site. Heck, vous en avez écrit beaucoup et dans n’importe quelle langue. Vous réalisez que vous passez une grande partie de votre temps à écrire ces clauses SQL qui vous font mal. Vous n’êtes pas un dba, et pourtant, vous êtes en train d’écrire de stupides déclarations SQL ... pas seulement une, mais paniquer partout. msgstr "sélectionnez ceci, sélectionnez cela". Mais vous vous souvenez en particulier de la clause irritante WHERE. Où nom est égal à "thornton" et film égal à "mauvais père noël". Urgh. Vous pensez, "pourquoi ces dbas ne font-ils pas leur travail et me donnent-ils des procédures stockées?" Ensuite, vous oubliez un champ mineur tel que middlename, vous devez alors supprimer le tableau, exporter les 10G de données volumineuses et en créer un autre avec ce nouveau champ, puis importer les données - et cela continue 10 fois au cours des 14 prochains jours. continuez à vous rappeler des conneries comme la salutation, le titre, en plus d'ajouter une clé étrangère avec des adresses. Ensuite, vous estimez que ce nom doit être lastName. Presque un changement par jour. Ensuite, vous dites darnit. Je dois écrire et écrire un site Web/un 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 pop 'nosql' et ensuite vous lisez des choses et il dit qu'il est juste de vider les données sans aucun schéma. Vous vous souvenez du fiasco de la semaine dernière, laissant tomber plus de tables et souriant. Ensuite, vous choisissez mongo parce que certains gros joueurs comme "airbud", le site de location d'apt l'utilise. Sucré. Fini les changements de modèle de données, car vous avez un modèle que vous ne faites que changer.
Peut-être que cette ressource est utile pour aider à choisir entre les deux. Il aborde également plusieurs autres bases de données NoSQL et propose une liste succincte de caractéristiques, ainsi qu'une explication "dans laquelle je l'emploierais" .
Question difficile à répondre - 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 d'entre eux satisfait votre besoin.
Cela dit, MongoDB ne nécessite aucun matériel coûteux. Comme toute autre solution de base de données, elle fonctionnera mieux avec plus de temps processeur et de mémoire, mais ce n’est certainement pas une exigence - en particulier pour les besoins de développement précoce.
Toutes les réponses (au moment d'écrire ces lignes) supposent que 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 du tout les modèles de données.
MongoDB: données complexes
MongoDB est un magasin de documents. Comparaison avec une base de données relationnelle basée sur SQL: les bases de données relationnelles se simplifient en 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.
La structure des fichiers JSON est similaire à celle des fichiers XML et YAML et des 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 pour 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 contient également un tableau de Accounts contenant plusieurs index. Il est possible de rechercher un document où Accounts contient exactement un sous-ensemble de valeurs, tout de quelque sous-ensemble de valeurs, ou tout = d'un sous-ensemble de valeurs. Cela signifie que vous pouvez rechercher Accounts = ["379-1111", "379-2574"] et ne pas trouver ce qui précède; vous pouvez rechercher Accounts includes ["379-1111"] et trouver le document ci-dessus; et vous pouvez rechercher Accounts includes any of ["974-3785","414-6731"] et trouver ce qui précède, quel que soit le document contenant 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 très structurées, les documents constituent une avancée considérable 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, il vaut mieux utiliser une base de données relationnelle. Encore une fois, le gros problème est de savoir si vos modèles de données correspondent le mieux à une collection de fichiers CSV interreliés ou à une collection de fichiers XML/JSON/YAML.
Pour la plupart des projets, vous devrez faire des compromis en acceptant une solution de contournement mineure dans certains petits domaines où SQL ou les magasins de documents ne conviennent pas. pour certains grands projets complexes stockant un large éventail 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 dans un autre modèle. Facebook utilise à la fois SQL et une base de données de graphes (où les données sont placées dans des nœuds et les nœuds sont connectés à d'autres nœuds); Auparavant, Craigslist utilisait MySQL et MongoDB, mais envisageait de migrer entièrement vers MongoDB. Ce sont des endroits où l'étendue et la relation des données font face à des handicaps importants si elles sont placées sous un même modèle.
Redis: Valeur-clé
Redis est essentiellement 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 regarde que par son nom.
L’invalidation de la mémoire cache est l’un des problèmes majeurs de l’informatique; l'autre nomme des choses. Cela signifie que vous utiliserez Redis lorsque vous souhaitez éviter des centaines de recherches excessives dans un back-end, mais que vous devez déterminer quand vous avez 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, vous pouvez SELECT Lingots FROM Store s INNER JOIN UserProfile u ON s.UserID = u.UserID WHERE u.Username = Simon et stocker le résultat, 100, sous la forme SET user:Simon:lingots = 100. Ensuite, lorsque 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 deuxième cas est la mise à jour des informations dépendantes. Supposons que vous générez des morceaux d'une page et que vous en mettiez en cache la sortie. L'en-tête indique l'expérience du joueur, son niveau et son montant. la page de profil du joueur a un bloc qui montre ses statistiques; et ainsi de suite. Le joueur gagne de l'expérience. Eh bien, vous avez maintenant plusieurs champs templates:Header:Simon, templates:StatsBox:Simon, templates:GrowthGraph:Simon, etc., dans lesquels vous avez mis en cache la sortie d'une demi-douzaine de requêtes de base de données exécutées via 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;
Comme vous venez de mettre à jour les résultats de GetStatsFromDatabase("Simon"), vous devez supprimer templates:*:Simon de votre cache clé-valeur. Lorsque vous essayez de restituer l'un de ces modèles, votre application annule l'extraction des données de votre base de données (PostgreSQL, MongoDB) et leur insertion dans votre modèle. puis il stockera le résultat dans Redis et, espérons-le, ne se souciera plus de faire des requêtes à la base de données ni de restituer des modèles la prochaine fois qu'il affichera ce bloc de sortie.
Redis vous permet également de créer des files d'attente de messages avec les éditeurs et autres. C'est un autre sujet entièrement. Redis est un cache clé-valeur 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 modèle le plus important est généralement le modèle de données, car il détermine la complexité et le risque d'erreur de votre code. Les applications spécialisées s’appuieront sur les performances, des endroits où vous écrivez tout dans un mélange de C et d’Assemblée; la plupart des applications ne font que gérer le cas généralisé et utiliser un système de mise en cache tel que Redis ou Memcached, beaucoup plus rapide qu'une base de données SQL hautes performances ou un magasin de documents.
Redis est un magasin de données en mémoire, qui peut conserver son état sur le disque (pour permettre la récupération après le redémarrage). Toutefois, le fait d'être 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 total de la mémoire sur le système (physique RAM + espace d'échange). En réalité, ce sera beaucoup moins que cela, étant donné que Redis partage cet espace avec de nombreux autres processus sur le système, et que si elle épuise l'espace mémoire du système, elle sera probablement détruite par le système d'exploitation.
Mongo est un magasin de données basé sur le disque, qui est plus efficace lorsqu'il est défini dans son ensemble de travail qui entre dans la mémoire physique RAM. _ (comme tous les logiciels). S'agissant de données sur disque, la taille d'une base de données Mongo n'est pas intrinsèquement limitée. Toutefois, les options de configuration, l'espace disque disponible et d'autres problèmes peuvent signifier que les tailles de bases de données dépassant une certaine limite peuvent devenir impraticables ou inefficaces.
Les deux Redis et Mongo peuvent être mis en cluster pour la haute disponibilité, la sauvegarde et pour augmenter la taille globale du datastore.
Et vous ne devriez utiliser ni si vous avez beaucoup de RAM. Redis et MongoDB en viennent au prix d'un outil à usage général. Cela introduit beaucoup de frais généraux.
Il y avait le dicton qui dit que Redis est 10 fois plus rapide que Mongo. Cela pourrait ne plus être vrai. MongoDB (si je me souviens bien) a prétendu battre Memcache pour le stockage et la mise en cache de documents, à condition que les configurations de mémoire soient les mêmes.
De toute façon. Redis bien, MongoDB est bon. Si vous vous souciez des sous-structures et que vous avez besoin d'agrégation, optez pour MongoDB. Si stocker vos clés et vos valeurs est votre principale préoccupation, tout est à propos de Redis. (ou tout autre magasin de valeur de clé).
Redis et MongoDB sont deux bases de données non relationnelles, mais elles appartiennent à des catégories différentes.
Redis est une base de données clé/valeur et utilise un stockage en mémoire qui le rend très rapide. C'est un bon candidat pour la mise en cache de données et le stockage temporaire de données (en mémoire). Comme la plupart des plates-formes cloud (telles que Azure, AWS) le prennent en charge, son utilisation en mémoire est évolutive.Mais si vous allez l'utiliser sur vos machines avec ressources limitées, considérez son 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, images, 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 bon choix. Il est évolutif avec la stratégie de montée en puissance. Il utilise le disque comme support de stockage, ainsi les données seraient persistées.
Si votre projet en attente vous permet d'avoir assez de mémoire RAM sur votre environnement, la réponse est Redis. Surtout en tenant compte de la nouvelle Redis 3.2 avec la fonctionnalité de cluster.