Redis et MongoDB peuvent être utilisés ensemble avec de bons résultats. Une entreprise bien connue pour exécuter MongoDB et Redis (ainsi que MySQL et Sphinx) est Craiglist. 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 concrets d'utilisation de Redis sur 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 ou de marquage à facettes de base en plus de cette fonctionnalité, ce qui est un ajout intéressant aux capacités d'indexation plus traditionnelles de MongoDB.
-
Redis prend en charge les opérations pop de blocage efficaces sur les listes. Cela peut être utilisé pour implémenter un système de file d'attente distribué ad hoc. Il est plus flexible que les curseurs tailables MongoDB IMO, car une application backend peut écouter plusieurs files d'attente avec un délai d'attente, transférer des éléments vers une autre file d'attente de manière atomique, etc ... Si l'application nécessite une certaine file d'attente, il est logique de stocker la file d'attente dans Redis , et conserver les données fonctionnelles persistantes dans MongoDB.
-
Redis propose également un mécanisme de pub/sub. Dans une application distribuée, un système de propagation d'événements peut être utile. Il s'agit à nouveau d'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 apportées 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 échangée, pas Redis. Si MongoDB déclenche une activité d'échange, les performances de Redis seront catastrophiques. Ils doivent être isolés sur différents nœuds.
