Réponses:
Redis et MongoDB peuvent être utilisés avec de bons résultats. Craiglist est une société bien connue pour exécuter MongoDB et Redis (avec MySQL et Sphinx). Voir cette présentation de Jeremy Zawodny.
MongoDB est intéressant pour les données persistantes, orientées document, indexées de différentes manières. Redis est plus intéressant pour les données volatiles ou les données semi-persistantes sensibles à la latence.
Voici quelques exemples d'utilisation concrète de Redis en plus de MongoDB.
MongoDB pré-2.2 n'a pas encore de mécanisme d'expiration. Les collections plafonnées ne peuvent pas vraiment être utilisées pour implémenter un vrai TTL. Redis dispose d'un mécanisme d'expiration basé sur TTL, ce qui facilite le stockage des données volatiles. Par exemple, les sessions utilisateur sont généralement stockées dans Redis, tandis que les données utilisateur seront stockées et indexées dans MongoDB. Notez que MongoDB 2.2 a introduit un mécanisme d'expiration de faible précision au niveau de la collecte (à utiliser pour purger les données par exemple).
Redis fournit un type de données d'ensemble pratique et ses opérations associées (union, intersection, différence sur plusieurs ensembles, etc.). Il est assez facile d'implémenter un moteur de recherche à facettes ou de balisage de base en plus de cette fonctionnalité, qui est un ajout intéressant aux capacités d'indexation plus traditionnelles de MongoDB.
Redis prend en charge des opérations de blocage efficaces sur les listes. Cela peut être utilisé pour implémenter un système de mise en file d'attente distribuée ad hoc. Il est plus flexible que les curseurs disponibles MongoDB IMO, car une application backend peut écouter plusieurs files d'attente avec un timeout, transférer des éléments vers une autre file d'attente de manière atomique, etc ... Si l'application nécessite une mise en file d'attente, il est logique de stocker la file d'attente dans Redis et conservez les données fonctionnelles persistantes dans MongoDB.
Redis propose également un mécanisme pub / sous. Dans une application distribuée, un système de propagation d'événements peut être utile. C'est encore un excellent cas d'utilisation pour Redis, tandis que les données persistantes sont conservées dans MongoDB.
Parce qu'il est beaucoup plus facile de concevoir un modèle de données avec MongoDB qu'avec Redis (Redis est plus bas niveau), il est intéressant de bénéficier de la flexibilité de MongoDB pour les principales données persistantes, et des fonctionnalités supplémentaires fournies par Redis (faible latence , expiration des éléments, files d'attente, pub / sub, blocs atomiques, etc ...). C'est en effet une bonne combinaison.
Veuillez noter que vous ne devez jamais exécuter un serveur Redis et MongoDB sur la même machine. La mémoire MongoDB est conçue pour être remplacée, Redis ne l'est pas. Si MongoDB déclenche une activité d'échange, les performances de Redis seront catastrophiques. Ils doivent être isolés sur différents nœuds.
Évidemment, il y a beaucoup plus de différences que cela, mais pour un aperçu extrêmement élevé:
Pour les cas d'utilisation:
Techniquement:
Il y a un certain chevauchement, mais il est extrêmement courant d'utiliser les deux. Voici pourquoi:
Redis peut être utilisé en remplacement d'un magasin de données traditionnel, mais il est le plus souvent utilisé avec un autre magasin de données "long" normal, comme Mongo, Postgresql, MySQL, etc.
Redis fonctionne parfaitement avec MongoDB en tant que serveur de cache. Voici ce qui se passe.
Chaque fois que cette mangouste émet une requête de cache, elle passe d'abord par le serveur de cache.
Le serveur de cache vérifiera si cette requête exacte a déjà été émise auparavant.
Si ce n'est pas le cas, le serveur de cache prendra la requête, l'envoie à mongodb et Mongo exécutera la requête.
Nous prendrons alors le résultat de cette requête, il retournera ensuite au serveur de cache, le serveur de cache stockera le résultat de la requête sur lui-même.
Il dira que chaque fois que j'exécute cette requête, j'obtiens cette réponse et donc il va maintenir un enregistrement entre les requêtes qui sont émises et les réponses qui reviennent de ces requêtes.
Le serveur de cache prendra la réponse et la renverra à la mangouste, la mangouste la donnera à exprimer et elle finira par se retrouver dans l'application.
Chaque fois que la même requête exacte est émise à nouveau, mangouste enverra la même requête au serveur de cache, mais si le serveur de cache voit que cette requête a été émise avant il n'enverra pas la requête à mongodb, au lieu de cela, il va prendre la réponse à la requête qu'il a reçue la dernière fois et la renvoyer immédiatement à la mangouste. Il n'y a pas d'index ici, pas de balayage complet de la table, rien.
Nous faisons une simple recherche pour dire que cette requête a été exécutée? Oui? D'accord, prenez la demande et renvoyez-la immédiatement et n'envoyez rien à mongo.
Nous avons le serveur mongoose, le serveur cache (Redis) et Mongodb.
Sur le serveur de cache, il peut y avoir une banque de données avec un type de valeur clé de magasin de données où toutes les clés sont un type de requête émise avant et la valeur le résultat de cette requête.
Alors peut-être que nous recherchons un tas d'articles de blog par _id.
Alors peut-être que les clés ici sont les _id des enregistrements que nous avons consultés auparavant.
Imaginons donc que mangouste émette une nouvelle requête où elle essaie de trouver un article de blog avec _id de 123, la requête s'écoule dans le serveur de cache, le serveur de cache vérifiera s'il a un résultat pour toute requête qui recherchait un _id sur 123.
S'il n'existe pas dans le serveur de cache, cette requête est prise et envoyée à l'instance mongodb. Mongodb exécutera la requête, obtiendra une réponse et la renverra.
Ce résultat est renvoyé au serveur de cache qui prend ce résultat et le renvoie immédiatement à mangouste afin que nous obtenions une réponse aussi rapide que possible.
Juste après cela, le serveur de cache prendra également la requête émise, et l'ajoutera à sa collection de requêtes qui ont été émises et prendra le résultat de la requête et le stockera directement par rapport à la requête.
Nous pouvons donc imaginer qu'à l'avenir, nous émettons à nouveau la même requête, elle frappe le serveur de cache, elle regarde toutes les clés dont elle dispose et dit oh j'ai déjà trouvé ce blog, il n'atteint pas mongo, il suffit le résultat de la requête et l'envoie directement à la mangouste.
Nous ne faisons pas de logique de requête complexe, pas d'index, rien de tout cela. C'est aussi rapide que possible. C'est une simple recherche de valeur de clé.
C'est un aperçu de la façon dont le serveur de cache (Redis) fonctionne avec MongoDB.
Maintenant, il y a d'autres préoccupations. Mettons-nous des données en cache pour toujours? Comment mettons-nous à jour les enregistrements?
Nous ne voulons pas toujours stocker des données dans le cache et lire à partir du cache.
Le serveur de cache n'est utilisé pour aucune action d'écriture. La couche de cache n'est utilisée que pour la lecture des données. Si jamais nous écrivons des données, l'écriture passera toujours à l'instance de mongodb et nous devons nous assurer qu'à chaque fois que nous écrivons des données, nous effacons toutes les données stockées sur le serveur de cache qui sont liées à l'enregistrement que nous venons de mettre à jour dans Mongo.