Bonjour à tous,

Dans l'optique d'une refonte total d'une plateforme (importante) existante, j'étudie actuellement mongoDB pour potentiellement l'utilisé combiné à MySQL (la partie relationnel me semble indispensable).

Le problème que nous avons aujourd'hui une BDD MySQL qui est souvent le goulot d'étranglement. Certaines tables contiennent 100 000 000 d'enregistrement voir plus, et les requêtes pour traiter ces données deviennent bien trop longue ! (on compte parfois en heure...)
Outre le fait de totalement revoir la structure de la BDD, ainsi que le coté hardware (en mettant en place un cluster SQL), je souhaite également étudier le NoSQL, qui me semblait adapté pour remplacer ces tables. Pour résumé, c'est tables qui stocks une visite liée à un utilisateur et à un compte, le tout daté + quelques autres infos.

Du coup, je me suis lancé dans des tests, en me basant sur ca :
https://github.com/webcaetano/mongo-mysql

Sur ces tests, on voit que MySQL est plus performant que Mongo. Rien d'étonnant puisqu'en SQL il fait un JOIN, la ou en NoSQL, il boucle autant de fois qu'il y'a d'enregistrement dans la première table.

J'ai donc revu ce test moi même :

J'ai donc un document type de ce genre (données générées aléatoirement) :

avec 10 millions d'enregistrements.

et de l'autre coté une table équivalente en MySQL.

En MySQL, j'effectue la requête suivante :

qui s'execute en 5 089ms

En mongo, j'ai ca :

qui s'execute en 27 189ms !!!

Le NoSQL, dans ces conditions, n'est-il pas censé être plus performant ?
J'ai manqué quelque chose ?

NB : test effectué sur un OVH "VPS SSD 3", linux, debian, mongo 3.2 RC6

Merci pour votre aide.

J'aurais tendance à dire que le modèle mis en place sur MongoDB n'est pas adapté (sans doute trop proche de celui relationnel sur Mysql).
Penser NoSQL quand on vient du relationnel, c'est pas évident sans tuto/formations...

 
Oui, j'ai bien conscience que les manière de s'organiser seront nécessairement différent, là n'est pas le pb.
Du coup pour tester, j'ai fait abstraction de tout ce qui gravite autour des "JOIN" (qui n'existe pas en NoSQL et qui implique de designé la BDD différemment). Juste une table/collection "simple", que je requête.
Si même là je fais de travers, faut pas hésiter à me le dire, mais je pense pas me tromper sur ce point. (ou alors j'ai vraiment rien compris au NoSQL).

Dans les deux cas tu as testé sans aucun index sur ta table je présume, tu as essayé avec les mêmes données mais en indexant sur ce qui t'intéresses ? Ca a beau être du NoSQL, la notion d'index existe quand même.
La différence peut être intéressante.

Autre point, je ne sais pas sous quelle forme "find" renvoie ses données mais je vois que dans le cas de la version SQL tu restreins à deux colonnes, alors qu'implicitement la version NoSQL doit tout renvoyer, donc a priori elle est désavantagée !
Encore une fois ça dépend de ce que renvoie find exactement, mais si tu mets _id, player, email, score, team, date dans ton SELECT SQL à mon avis ça va faire une différence

Alors oui, j'ai essayé avec et sans index sur le mongo. Pas de différence de noté bizarement !  
 
Oui, en effet, je ne récupére pas tout à fait les même données. Du coup pour équilibré j'ai fais un SELECT * sur mysql. Il se fait en 14s, pour toujours environ 30s sur Mongo.
 
Du coup, pour avoir le coeur net la dessus, j'ai fais un count en SQL : SELECT COUNT(*)...
et la même en mongo avec un .count()
 
Résultat, mongo est toujours 2 fois plus lent (4-5s pour mongo, 2s pour MySQL, sans index pour les 2).
 
J'ai continué mes recherches sur le net, et apriori je suis pas le seul à avoir la même conclusion : https://www.quora.com/How-does-Mong [...] in-Darfler
 

 
Avec une explication plus technique du pourquoi ici : http://stackoverflow.com/questions [...] this-query (scroller un peu vers le bas pour voir la réponse).
 
Conclusion pour mon cas, qui recherche avant tout de la performance, pas - encore - de la flexibilité horizontal, mongo ne semble pas fait pour moi.

Ce qu'il faut savoir c'est que MySQL est en réalité extrêmement performant, pour les transactions simples surtout. Par contre dans certains cas d’utilisation MySQL ça peu devenir catastrophique à cause des verrous globaux qui sont posés, ce qui pourrais expliquer des requêtes à rallonge. Tu es sur MyISAM ou innodb ?

 
Je fais des tests sur les 2, mais en l'occurence là j'étais en MyISAM.
J'ai fais des tests en innodb, et les résultats sont à peu près les même, hormis l'insertion qui est naturellement beaucoup plus longue avec innoDB (check d’intégrité, donc ca semble logique).

Sans doute que tu es tout simplement dans un cas où le NoSQL n'est pas adapté. Le NoSQL est à réserver pour certains cas/traitements/volumes bien particuliers.

MyISAM est généralement le plus rapide pour les transactions simples mais il y à le probleme des verrous globaux qui peu être amélioré dans certains cas de figure en passant à innodb.