Quand Redis? Quand MongoDB?

Je dirais, ça dépend de la sorte de l'équipe de développement vous et les besoins de votre application.

Par exemple, si vous avez besoin de beaucoup de interrogation, qui signifie surtout qu'il serait plus de travail pour votre développeurs d'utiliser le Redis, où vos données peuvent être stockées dans une variété de des structures spécialisées de données, adapté à chaque type d'objet pour l'efficacité. Dans MongoDB les mêmes requêtes peut être plus facile parce que la structure est plus cohérent à travers vos données. D'autre part, dans le Redis, vitesse pure de la réponse à ces requêtes, est la récompense pour le travail supplémentaire de faire face à la diversité des structures de vos données peuvent être stockées avec.

MongoDB offre la simplicité, beaucoup plus courte de la courbe d'apprentissage pour les développeurs traditionnels DB et SQL expérience. Cependant, Redis non traditionnels, approche nécessite plus d'effort pour apprendre, mais une plus grande souplesse.

Par exemple. Un cache couche peut probablement être mieux mis en œuvre dans le Redis. Pour plus d'schéma de mesure des données, MongoDB, c'est mieux. [Note: les deux MongoDB et Redis sont techniquement schemaless]

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

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

Redis. Disons que vous avez écrit sur un site en php; pour quelque raison que ce soit, il devient populaire, et il est en avance sur son temps ou a porno sur elle. Vous vous rendez compte de php est tellement ridiculement lent, "je vais perdre mes fans, tout simplement parce qu'ils n'auront pas à attendre 10 secondes pour qu'une page." Vous avez une soudaine prise de conscience qu'une page web a une constante url (il ne change jamais, whoa), une clé primaire si vous voulez, et puis vous vous souvenez que la mémoire est rapide alors que le disque est lent et php est encore plus lente. 🙁 Ensuite, vous de la mode un mécanisme de stockage à l'aide de la mémoire et de cette URL que vous appelez une "clé", tandis que le contenu des pages web, vous décidez d'appeler la "valeur". C'est tout ce que vous avez - clés et le contenu. Vous l'appelez "mème cache." Vous comme Richard Dawkins, parce qu'il est génial. Vous le cache de votre code html comme les écureuils cache leurs écrous. Vous n'avez pas besoin de réécrire votre merde de code php. Vous êtes heureux. Alors vous voyez que d'autres l'ont fait, mais vous choisissez Redis parce que l'autre a confusion des images de chats, certains avec des crocs.

Mongo. Vous avez écrit un site. Diable vous avez écrit beaucoup, et dans n'importe quelle langue. Vous vous rendez compte que beaucoup de temps est consacré à la rédaction de ces puant SQL clauses. Vous n'êtes pas administrateur, mais vous y êtes, écrit stupide sql... et pas seulement un, mais à flipper un peu partout. "sélectionnez cette option, sélectionnez". Mais, en particulier, vous souvenez-vous de l'irritant clause where. Où nom est synonyme de "thornton" et le film est égal à "bad santa." Urgh. Vous pensez, "pourquoi ne le faites pas ces administrateurs de bases de données juste faire leur travail et de me donner quelques procédures stockées?" Ensuite, vous oubliez un peu mineur domaine de la middlename et alors vous devez supprimer la table, l'exportation de tous les 10G de gros volumes de données et créer un autre avec ce nouveau domaine, et importer les données, et que se passe 10 fois au cours des 14 prochains jours, comme vous le garder sur le souvenir de la merde comme formule de salutation, de titre, de plus l'ajout d'une clé étrangère avec les adresses. Ensuite vous à la figure que le nom devrait être lastName. Près d'un changement un jour. Ensuite, vous dites darnit. J'ai à écrire un site web/système, jamais l'esprit ce modèle de données bs. Si vous google, "je déteste écrire SQL, s'il vous plaît pas de SQL, de le faire arrêter", mais jusqu'éclate "nosql" et puis vous avez lu quelques trucs et il affirme qu'il décharges de données sans schéma. Vous vous souvenez la semaine dernière fiasco de déposer plus de tableaux et de sourire. Ensuite, vous choisissez mongo parce que certains gros joueurs comme "airbud' apt location de site utilise. Doux. Plus de données le modèle de changements parce que vous avez un modèle que vous venez de changer.

Difficile de répondre à cette question - comme avec la plupart des solutions de technologie, 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 avez besoin de tester les deux pour voir lequel d'entre eux satisfait votre besoins.

Avec cela dit, MongoDB ne nécessite pas de matériel coûteux. Comme toute autre solution de base de données, cela fonctionne mieux avec le plus de CPU et de mémoire, mais n'est certainement pas une exigence, surtout pour le début des fins de développement.

Toutes les réponses (au moment d'écrire ces lignes) supposons que chaque de Redis, MongoDB, et peut-être une base SQL de base de données relationnelle sont essentiellement le même outil: "banque de données". Ils ne considèrent pas des modèles de données à tous.

MongoDB: Données Complexes

MongoDB est une banque de document. Pour comparer avec un SQL-driven relationnel de la base de données: bases de données relationnelles simplifier indexées CSV fichiers, chaque fichier étant un tableau; document de magasins de simplifier indexées JSON fichiers, chaque fichier étant un document, avec plusieurs fichiers regroupés.

Des fichiers JSON ont une structure similaire à XML et les fichiers YAML, et les dictionnaires comme en Python, alors, pensez à vos données dans une sorte de hiérarchie. Lors de l'indexation, la structure est la clé: Un document contient les clés nommées, qui contiennent d'autres documents, des tableaux, ou des valeurs scalaires. Examiner 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 à travers une collection de documents où la clé, PhoneNumber.Mobile, a de la valeur; ils sont indexés.

Il a aussi un tableau de Accounts qui détiennent plusieurs indices. Il est possible de requête pour un document où Accounts contient exactement certains sous-ensemble de valeurs, tous de certains sous-ensemble de valeurs, ou tout de certains sous-ensembles de valeurs. Cela signifie que vous pouvez rechercher pour Accounts = ["379-1111", "379-2574"] et ne pas trouver ci-dessus; 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 de trouver ce qui précède et tout ce document renferme le compte "974-3785", le cas échéant.

Documents d'aller aussi profond 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 très structurées, les documents sont un grand pas en place de bases de données relationnelles.

Si vos données est essentiellement plat, relationnelle, et rigidement structurée, vous êtes mieux avec une base de données relationnelle. Encore une fois, la grande enseigne est de savoir si vos modèles de données le mieux à un de la collection de l'interdépendance des fichiers CSV ou une collection de XML/JSON/fichiers YAML.

Pour la plupart des projets, vous aurez à faire des compromis, accepter un mineur de travail autour de quelques petites zones où SQL ou d'un Document Magasins ne correspondent pas; pour certains grands projets complexes, le stockage d'un large éventail de données (nombre de colonnes; les lignes sont hors de propos), il serait judicieux de stocker des données dans un modèle et d'autres données dans un autre modèle. Facebook utilise SQL et un graphique de la base de données (où les données sont placées dans des nœuds, et les nœuds sont connectés à d'autres nœuds); Craigslist pour utiliser le MySQL et MongoDB, mais avait été à la recherche de déménagement entièrement sur MongoDB. Ce sont des endroits où la durée et la relation de ces données fait l'objet d'importants handicaps en cas de mise sous un modèle.

Redis: Clé-Valeur

Redis est, plus fondamentalement, un key-value store. Redis permet de donner une touche et de rechercher une valeur unique. Redis lui-même pouvez stocker des chaînes de caractères, les listes, les tables de hachage, et quelques autres choses; toutefois, il ne semble par nom.

Invalidation du Cache est l'une des sciences de l'informatique dur de problèmes; l'autre est nommant les choses. Cela signifie que vous allez utiliser Redis quand vous voulez éviter des centaines de l'excès de look-ups à un back-end, mais vous devez savoir quand vous avez besoin d'un nouveau look-up.

Le cas le plus évident de l'invalidation est mise à jour sur l'écriture: si vous lisez user:Simon:lingots = NOTFOUND, vous pourriez 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. Puis, quand vous récompense Simon 5 lingots, vous avez bien lu 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 le Redis, et peut obtenir user:Simon:lingots sans interroger la base de données.

Le deuxième cas est la mise à jour des informations dépendantes. Disons que vous générer des morceaux d'une page et cache leur sortie. L'en-tête montre l'expérience du joueur, le niveau et la quantité de l'argent; le Profil du joueur page a un bloc qui affiche les 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, et ainsi de suite les domaines où vous avez mis en cache de la sortie d'une demi-douzaine de requêtes de base de données, courir à travers un moteur de template. Normalement, lors de l'affichage de 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 déposer templates:*:Simon de votre clé-valeur du cache. Lorsque vous essayez d'afficher l'un de ces modèles, votre demande de désabonnement à l'écart de l'extraction de données à partir de votre base de données (PostgreSQL, MongoDB) et de l'insérer dans votre modèle; puis il va stocker le résultat dans le Redis et, espérons-le, pas la peine de faire des requêtes de base de données et les modèles de rendu de la prochaine affiche de ce bloc de sortie.

Redis vous permet également de faire de l'éditeur-abonnez-vous files d'attente de messages et de ces. C'est un autre sujet entièrement. Le Point ici est Redis est une valeur-clé de cache, qui diffère d'une base de données relationnelle ou une banque de document.

Conclusion

Choisissez vos outils en fonction de vos besoins. Le plus grand besoin est habituellement un modèle de données, comme qui détermine le degré de complexité et le risque d'erreur de votre code. Des applications spécialisées, va s'appuyer sur les performances, les endroits où vous écrire tout dans un mélange de C et de l'Assemblée; la plupart des applications sera juste la poignée de la généralisation d'un cas et l'utilisation d'un système de cache comme le Redis ou Memcached, ce qui est beaucoup plus rapide qu'une haute performance de base de données SQL ou une banque de document.

MongoDB et Redis sont les deux bases de données non relationnelles, mais ils sont de différentes catégories.

Redis est une Clé/Valeur de la base de données, et c'est à l'aide de stockage En mémoire ce qui le rend super rapide. C'est un bon candidat pour la mise en cache des trucs et de stockage temporaire des données(dans la mémoire) et que la plupart des plates-formes cloud (comme Azure,AWS) le supporte, c'est l'utilisation de la mémoire est extensible.Mais si vous allez l'utiliser sur vos machines avec des ressources limitées, c'est l'utilisation de la mémoire.

MongoDB sur l'autre main, est un document de la base de données. C'est une bonne option pour garder les grands textes, images, vidéos, etc, et presque tout ce que vous faites avec les bases de données à l'exception des transactions.Par exemple, si vous voulez développer un blog ou un réseau social, MongoDB est un bon choix. Il est évolutif avec l'échelle de stratégie. Il utilise le disque comme support de stockage, de sorte que les données seraient conservées.