Oui j'ai regardé d'un peux plus prêt aussi, c'est vrai pour Redis qui va stocker en RAM et parfois faire une "sauvegarde" sur le disque qui va permettre de recharger les données en cas d'arrêt du serveur Redis.
MongoDb lui par exemple ne va pas tout stocker en RAM, il va y garder les opérations à faible latence et le mapping des documents (voir d'autres dont je ne suis pas au courant).
NB : ce qui ne veut pas dire que cela ne peut pas devenir gourmands en utilisation RAM.
Il y a différents types de système NoSQL comme :
- clé->valeur (comme redis par exemple)
- documents (ex: mongodb)
- graph (ex: neo4j)
- column family stores (jamais utilisé)
Je rappelle que NoSQL est un acronyme de "Not Only SQL". Ce qui veut dire qu'il peut tout à fait se coupler à un SGBDR (Polyglot App / Vive les transactions :) ). C'est même là son point fort.
Pour Redis, par exemple vous avez vos propres statistiques de visites (un peu fou mais bon), un compteur de membres, d'articles, de commentaires et des sessions utilisateurs...
Plutôt que de faire des requêtes de types Count et les mettre en cache, ne pas stocker le résultat par exemple une fois par jour (à noter que l'on peux donner une durée de vie aux "clef->valeur" pour qu'elle se supprime automatiquement après X temps) à la première requête serveur (ou même ne pas refaire de requête count tant que la valeur existe dans redis) et ensuite à chaque ajout, incrémenté la valeur Redis. Il me semble d'ailleurs qu'il a un très bon système d'inc qui, même bombardé d'update ne fera pas d'erreur
Mais également pourquoi ne pas y stocker vos sessions utilisateurs qui va vous permettre une scalabilité horizontale (Pouvoir ouvrir/fermer des serveurs sans répercussion pour l'utilisateur)
Voir même pourquoi pas faire du light queuing si l'on n'a pas besoin d'un système comme RabbitMQ ou autres.
Pour ceux qui souhaiteraient en découvrir un peu plus sur Redis : http://tech.m6web.fr/redis-on-fire/ (il y a aussi du mongodb, vagrant, etc.)
Bien sûr, je ne travail pas pour M6, au cas ou.