A l’occasion de deux demandes de formation concernant les serveurs NoSQL Redis v6 et MongoDb v4, j’ai eu l’occasion de consulter bien de la littérature, de bien connaître les deux produits, leurs puissances, leurs limites, et d’en déduire mes sentiments.
Aussi, il me semble important d’écrire un petit article concernant ces serveurs, car ce que j’ai lu n’a pas toujours été très pertinent.
Redis est un serveur orienté Clef-valeur. Avec memcached, c’est une solution extrêmement performante en mémoire.
MongoDb est un serveur de type document. Il est très puissant, et permet les scénarios de type BigCompute ( opérations de calcul distribué la ou se trouve la donnée ).
Ces deux serveurs ne sont donc pas vraiment comparables, et ne se sont pas rejoints depuis leurs première version. Car j’ai commencé par lire des article pour les comparer afin de me faire rapidement une idée du périmètre du second serveur que j’ai appréhendé.
En résumé :
- Redis est un serveur de type Clef-valeur InMemory et persistant. Il est très performant dans des scénarios de cache, et permet la haute disponibilité ( Répartition de charge et tolérance de pannes ).
Redis est « bête et rapide ».
Vous allez consommer énormément de RAM. Pas assez de RAM ? Attention aux plantages !
Avec la version entreprise, vous pourrez déférer de la mémoire sur disque ( via « Flash » ).
Il est faux d’affirmer qu’il dispose de capacité d’index secondaire ! Car c’est à l’utilisateur de mettre en oeuvre lui-même le plan d’indexation ( je suis très déçu de ces affirmations, de fait ). cf article officiel en fin de « mise en oeuvre d’index » ( SCAN n’a aucune relation avec les index ) :
Index inconsistency
Keeping the index updated may be challenging, in the course of months or years it is possible that inconsistencies are added because of software bugs, network partitions or other events.
Different strategies could be used. If the index data is outside Redis read repair can be a solution, where data is fixed in a lazy way when it is requested. When we index data which is stored in Redis itself the SCAN family of commands can be used in order to verify, update or rebuild the index from scratch, incrementally.
- MongoDb est un serveur de type Document. Les documents sont représentés en Json, et disposent de tous les sous-types.
La normalisation relationnelle reste un antipattern sous MongoDb. Il est possible de faire des recherches ( lookup ) pour obtenir l’équivalent des jointures.
MongoDb peut facilement monter en puissance via des réplicas, et du partitionnement en cluster+replicas.
MongoDb est une vraie solution BigData + BigCompute. Ses modèles de pipeline, ou mapReduce au choix, vous permettent de définir des fonctions de calcul puissantes qui seront appliquées dans votre cluster. Dans des scénarios « assez simples », vous pouvez alors vous affranchir de solutions de type Spark par exemple.
MongoDb est prévu pour monter en puissance, et consommera raisonnablement votre mémoire sans limite de stockage.
- Mon sentiment final est que je suis monté très facilement en puissance avec MongoDb, un vrai régal, fluide, puissant, compatible SQL avec une solution tierce.
Concernant Redis dans un second temps, cela était beaucoup plus opaque, des déceptions dans les attentes, des bonnes solutions intégrées de mise en cache applicatives ( JEE, .Net, … ), et il faut arrêter de chercher à faire croire qu’il est capable de faire plus que cela y compris dans la documentation officielle… - Chercher à les comparer est donc une erreur, ils sont à utiliser dans des use cases totalement différents.
