> Cassandra, Voldemort, MongoDB

Attention c’est pas pareil :
– Cassandra : orienté colonne
– Voldemort : orienté clé/valeur
– MongoDB : orienté document (document pouvant contenir des valeurs simples – string, int, etc – ou complexes, par exemple clé/valeur)

Après, choisir n’est pas simple du tout. A priori une orienté document serait intéressante, mais même dans ce cas il y a plusieurs choix, entre autre MongoDB vs CouchDB

La première chose est donc de voir précisément quel type de stockage est intéressant. Ensuite, faut choisir dans les possibilités, sachant que beaucoup proposent une interface REST avec du Json (donc c’est accessible par le réseau, entre serveurs ou depuis le client, etc) Bon parfois il y a aussi du BSON plutôt que JSON.

Quelques liens :
* Pour comparaison de différentes solutions (et explication) : http://www.smile.fr/Livres-blancs/Culture-du-web/NoSQL
* Pour comparaison de cassandra, mongodb, couchdb, redis, riak, … http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
* Comparaison MongoDB – CouchDB (en prenant en compte que c’est sur le site de MongoDB) http://www.mongodb.org/display/DOCS/Comparing+Mongo+DB+and+Couch+DB

Bon, évidemment c’est encore une réponse du type « faut voir » mais avec de quoi commencer. Dans tous les cas je dirais qu’il y a deux étapes principales : choix du type de stockage puis choix de la solution exacte.
Le problème au final c’est que NoSQL regroupe pas mal de choses assez différentes.

Et histoire de rajouter une solution beaucoup plus… heu… particulière : https://gist.github.com/2715918
En gros, comment faire de l’orienté document avec stockage json dans un PostgreSQL. Je ne suis pas sur que ça puisse répondre mais c’est une solution qui peut parfois être envisageable s’il y a déjà du postgres dans l’infra par exemple.