Merci pour cet article très interessant. Par contre je n’arrive à lancer le code fourni, j’ai de erreurs dans le POM.xml j’utilise Eclipse et Tomcat. Je vous remercie

- j’utilise jongo pour dialoguer avec mongo
- j’utilise le build redis pour windows qui n’est officiellement pas supporté
- pour jongo comme pour morphia, j’utilise un WriteConcern FSYNC_SAFE donc c’est plus lent (mais bon, je préfère garder mes données)

Sur mon test j’ai inséré 900 000 objets et fait le test avec morphia, jongo, redis et une base mysql.

Pour la base il faut que je recommence, j’ai pas eu la patience d’attendre l’insertion des 900 000 lignes après plus de 40minutes… (pour 300 000 lignes)

avec morphia :
Count in 1ms
Find by login in 482ms
Save in 28ms
Find by address 435ms

avec jongo :
Count in 0ms
Find by login in 13ms
Save in 26ms
Find by address 497ms (non indexé)
Find by location 8ms (index géospatial)

avec redis :
Count in 0ms
Find by login in 263ms
Save in 21ms

avec redis il faut bien voir que l’opération de save correspond à plusieurs sets pour dénormaliser les différentes infos dont j’ai besoin ensuite pour faire des finds. Donc les 21ms sont très bien en considérant que je fais plusieurs set et un lpush

avec la base de données (mais avec 300 000 lignes) :
Count in 369ms
Find in 686ms
Save in 6ms

Bref, dans mon cas redis est meilleur en écriture mais moins bon en lecture finalement.

Je me plante peut-être mais il me semble que les temps de réponse peuvent aussi être liés à la volumétrie et la concurrence.
Je ne vois pas du tout de concurrence dans ton benchmark donc a mon avis on ne peut pas en tirer beaucoup de conclusions.

D’après ce que je vois, MongoDB viennent de virer le « global lock » lors des écritures, ce qui veut je crois dire que le write concurrent était avant un problème qui est maintenant amélioré.
http://blog.serverdensity.com/2012/05/23/goodbye-global-lock-mongodb-2-0-vs-2-2/

Donc pourquoi pas faire un test en 2.0 puis 2.2, avec des accès concurrents, pour voir la différence?

Redis c’est pas une DB in memory? Du coup comment ça se fait que ça soit plus lent en écriture que MongoDB?

Détail des modes Normal et Safe :
- Normal : Exceptions are raised for network issues, but not server errors
- Safe : Exceptions are raised for network issues, and server errors; waits on a server for the write operation

Pas mal de gens se font avoir dans leur bench, dont moi
Le mode Safe étant bien plus lent que Normal (2 voir 3 fois plus lent).

Pour info, Mongo gère la durabilité en mode cluster, pas mono-machine (d’où le mode « normal » par défaut).
Voir: http://www.thebuzzmedia.com/mongodb-single-server-data-durability-guide/

Tom

Dans le cas du benchmark sur stackoverflow, la version de MongoDB est « ancienne ». Les performances ont été améliorées, notamment en supprimant le global lock du serveur (chose qui m’a fait peur quand je l’ai appris). En soit je ne suis pas un « MongoDB fanboy », il faudra que j’aille regarder Redis.

Sinon, je n’aime pas du utiliser le driver MongoDB (que j’ai vu dans ton code), j’utilise généralement un wrapper qui allège pas mal le code -> http://jongo.org/

En tout cas, merci pour ce retour sur Redis.

Cordialement,

Attention tout de même l’objet de l’article n’est pas de tester Redis vs Mongo. Le (mauvais) score de Mongo peut venir de son driver ou de ma façon de l’utiliser. N’hésite pas à checker le code, je ne suis pas expert

btw, lui aussi arrive à de grosses différences entre les deux : http://stackoverflow.com/questions/5252577/how-much-faster-is-redis-than-mongodb

J’utilise MongoDB et je n’ai jamais testé Redis, je ne connais que de nom. Je me demandais si pour le benchmark présenté, des index avaient été mis dans MongoDB ? La différence me paraît énorme.

Cordialement,