Brunni (./518) :
Merci de vos réponses! Oui, ElasticSearch et Redis semblent adaptés, c'est ce que j'ai entendu. Mais ce qui m'intéresse c'est la démarche. Il y a tellement de systèmes de DB et quand tu lis une page comme http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html (qui est en fait vieille maintenant que je vois l'URL), difficile d'en sortir "c'est celui-là que je veux". Je serais curieux de savoir selon quelle démarche tu peux choisir un système de DB, à moins d'être un expert et d'avoir un peu tout testé bien sûr.

déjà, contrairement à ce qu'on lit souvent, il ne faut surtout pas exclure les bases SQL classiques, surtout PosgreSQL qui s'est améliorée pour ajouter des fonctions qu'on trouvait plutôt dans les noSQL à la base. En terme de perfs, tu peux avoir des surprises.
Ensuite, la dimension du besoin est vraiment importante. Certaines solutions ont été conçues pour les besoins de Google ou Facebook (au prix de grosses contraintes, parfois), et si tu n'as pas leurs besoins, elles n'ont pas spécialement d'intérêt.
Après, c'est moins vrai maintenant, mais il y a quelques années, la plupart de ces bases n'étaient pas forcément super stables et plantaient facilement ; je me souviens notamment d'un motif d'insertion/lecture/suppression dans du Cassandra qui me permettait d'écrouler un petit cluster de test de 70 cœurs en un quart d'heure (et parfois, les données étaient corrompues après le plantage \o/). Pour d'autres usages, ça tenait parfaitement.