Discussion :

[Hotgeart]

Bonjour,

Tout d'abord un peu d'histoire :
Je suis webmaster d'un site web de rencontre, mais assez proche du model de facebook. Donc newsfeed général et individuel, notifications, message 1n1 ajax, chatroom ajax, forums, visites avec stats individuel, etc.

Bref une machine de guerre codé en php... procédural, pas tapé . Le service mysql est down tous les soir minimum 3 fois et j'en ai eu ma claque de redemarrer ce truc. J'ai donc décidé de tout refaire à zéro pour que ça soit plus maintenable, ajouter quelque feat. et mon choix s'est porté sur Symfony2.

Au début je l'ai appris avec mysql et il y a une semaine je suis tombé sur un article sur le noSQL, je connaissais déjà, mais je n'avais aucune raison d'aller voir ce que c'était réellement vu que MySQL répondait à mes attentes. Sauf que la donne ayant changé j'ai quand même lu tout ça et j'ai tout dévoré ! Slider, conférence vidéo et autre articles sur le sujet. Et beaucoup parlais de mongoDB avec de jolie graph de perf. Et alors la je me suis dit : "Attend ! SF2 supporte mongoDB avec doctrine.". Et bien faisons un test. J'ai donc installer Genghis pour m'amuser un peu avec la console et ensuite couplé sf2+mongodb et j'ai fait un test d'insertion de 500 items et mongodb s'est avérer 5x plus performant que mysql. Autant vous dire que j'ai presque eu une érection .

Maintenant je me dis pourquoi pas sauter le pas et faire ce site en SF2+MongoDB. Cependant, j'ai la trouille. En effet ce n'est pas un choix à faire à la légère car ce site est un peu mon gagne pain donc je veux pas me gourer. Donc je viens vous poser certaines questions:

1/ En SQL nous avons les injections SQL, mais en mongoDB quels sont les risques niveau sécu ?

2/ MongoDB est bien sur ma machine, mais niveau serveur ça se passe comment ?
a ) Sur mon PC j'ai Genghis, mais il me demande aucun mot de passe ou quoi que se soit donc comment sécuriser ça sur mon serveur ? Je mets juste un .htaccess ?
b ) Et coté serveur comment sécuriser ? Car SF2 n'a besoin d'aucun login :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
# MongoDB Configuration
doctrine_mongodb:
    connections:
        default:
            server: mongodb://localhost:27017
            options: {}
    default_database: mongo_test
    document_managers:
        default:
            auto_mapping: true

Donc ça sous entend que le premier gus qui essaye de se connecter y arrivera avec juste : mongodb://localhost:27017

3/ Et forcément c'est un bordel dans ma tête car les jointures n'existe pas et comme je trouve que des tutos qui survole mongodb et font juste du CRUD de base, ma soif n'est pas assouvit. Donc comment se passe les jointures s'il y en a pas ? On ma dit qu'il fallait répliquer les donner, mais ça devient vite ingérable.

Imagination j'ai une table pour les posts d'un forum et les users :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
users:
-id       => 1
-name  => Paul
-sex     => Masculin
-mail   
-pass  
-token 
-lastlogin
 
topics
-id     => 1
-name => Discutions générales
 
posts:
-id 
-name   => Paul
-sex      => Masculin
-content => Lorem
-created
-topic_id  => ?

Ok répliquer les donnés du 'name' et 'sex' de l'user ça va, mais si paul change de nom c'est le bordel il y aura des dizaine de tables/documents à update.

Merci pour vos réponses. Si vous avez d'autres remarques que je n'ai pas soulevé, merci de m'en faire part

[hugo123]

Beaucoup de questions

Même si j'aime beaucoup Mongodb, je conseille fortement de bien étudier son cas d'usage avant de passer dessus.
C'est pas juste une base Mysql plus rapide (et d'ailleurs c'est pas forcément le cas).
Il y a des features en plus, ou plus simples à mettre en place et des features en moins, notamment la transactionnalité.

Tu as des besoins transactionnels, oublies Mongo.

Si tu as des soucis de perfs actuellement, peut être qu'il faut plutot penser cache ?

Par contre sur un site ou tu modélises des relations, peut être penser bases de données orientées graphe (Neo4j) ?

Dans tout les cas, tu peux mixer plusieurs systèmes en fonction des cas d'usage.

Pour tes questions,

1) Ca dépend de la lib que tu utilises. En principe c'est ta lib qui doit te proposer de faire du binding de paramétre dans tes requêtes. Evidemment on évite la concaténation de chaine tout comme en SQL.

2) MongoDB supporte l'accès par authentification. Mais le mieux reste de n'autoriser que des connexions locales. A toi de configurer ton firewall pour interdire les accès au port de Mongo depuis l'extérieur.

3) Oui, pas de jointures. Si t'as de gros besoins transactionnels, oublies Mongo. Mais sinon il faut penser différemment, oublies tes réflexes de normalisation, pense dénormalisation (duplication des données). Pense résistance aux erreurs en ayant des mécanismes qui acceptent des données éronnées ou pas à jour mais qui peuvent se corriger automatiquement.
Parfois le plus simple c'est d'embarquer des documents les uns dans les autres, par exemple topic et commentaires on peut les imaginer dans le même document.
Parfois tu ne feras que des références à un autre document via leurs ID et ca t'obligera à faire deux requêtes en lecture (ou plus).

[Hotgeart]

Merci pour ta réponse

Mon site ne gérera pas des données sensibles ni d'argent donc une perte de donnée est acceptable (pas trop quand même ). Si un membre envoie un message il verra bien que celui-ci n'a pas été envoyé et il le renverra ce n'est pas un problème. Pareil si la visite d'un membre sur la page d'un autre membre n'est pas prise en compte ce n'est pas un drame. Si c'est ça que tu entends par 'transactionnelle'.

Ma problématique actuelle est la suivante :
Mon serv' mysql est souvent down du à une trop forte charge et je ne sais que très rarement mettre des données en cache étant donné que le gros du système sont la notification, newsfeed, chat .. bref ! Que des données qui bougent constamment.

Je n'ai pas les moyens de payer d'autres serveurs pour faire de la duplication et encore moins les connaissances ce qui sous entendra une infogérance et donc des coûts en plus.

Donc mon regard s'est arrêté sur mongoDB étant donné que doctrine le supporte qui lui même est supporté par SF2. un schéma parfait.

C'est surtout cette conférence ci-dessous qui m'a conforté dans l'idée que mongo pouvait être LA solution.


1/ Donc si j'utilise SF2+doctrine je n'ai pas à me soucis trop de la sécu.

2/ Ok

3/ Oui actuellement c'est ce que fait Doctrine. Si j'ai des articles dans 2 catégories différentes il me fait 3 queries :
- Recup tous les articles
- Recup le nom de la categorie x
- Recup le nom de la categorie y

Personnellement je pense que le mariage sera bon :
Cache APC..-> pour ne pas trop en demander à mongo
SF2...........-> Pour la sécurité
Doctrine.....-> Qui choisi lui même l'organisation des documents. Donc je ne peux pas faire de conneries de débutant.

[hugo123]

Dans tout les cas, vérifies bien que la charge que tu as aujourd'hui peut être tenu par Mongo sur une machine de taille équivalente

[Hotgeart]

Tu peux t'expliquer ? Car logiquement mongodb demande moins de ressource non ? Pour de meilleur perf.

[hugo123]

Principe de base en performance : mesurer
Il est probable que ton cas d'usage et des modifications de paramétrage donne des résultats très différents d'une autre personne.
J'ai réalisé des benchs sur de fortes charges en écriture sur plusieurs bases dont Mongo et Mysql et Mysql se comportait pas si mal en conso RAM et CPU.

As tu analysé pourquoi ca plante avec Mysql ? As tu essayé de faire du tuning dessus ?

[Hotgeart]

Ça vient pour beaucoup du newsfeed et des notifications je dirai. Car j'ai constitué mon newsfeed et notification de cette façon :

id
sender => qui à fait l'action Y ?
(reiceiver) => dans le cas des notifs pour savoir qui est le receveur
type => un integer qui indique ce qu'est l'action (1 => aimer une photo, 2=> commenter une photo, 3=> x est ami avec y , etc...)
misc => varchar libre pour donner plus d'info (l'id d'un membre, l'id d'une photo, l'id d'un topic, etc..)

Exemple :
id \ type\ misc
10 \ 2 \ 5000
L'user 10 à commenté la photo qui a pour id 5000.

Ce qui fait une requête pour récupérer les newsfeeds avec une jointure pour savoir qui est le sender

Et ensuite dans la boucle bien en fonction du type une query est lancé ou non pour récupérer les misc.

Me doute que c'est pas super, mais actuellement si c'était a refaire je vois pas comment faire autrement.

Je sias pas si mon explication est claire ou non

[SQLpro]

y'a quand même une chose qui me grattouille dans votre discours.... Vous dites avoir des problèmes de performances avec MySQL... Vous ne dite rien de votre config machine, du nombre d'utilisateurs, de la volumétrie de la base et du nombre de transactions....

Parce que avant de tout redévelopper, peut être faut-il simplement reconfigurer le serveur, rajouter des ressources, indexer....

Évidemment MySQL c'est loin d'être le plus performant des SGBDR... C'est même le plus mauvais ! mais ne pas oublier deux choses :
1) un SGBDR possède déjà un cache naturel de données (les SGBDR travaillent exclusivement en RAM). Il faut donc bien dimensionner votre RAM
2) un SGBDR ne sera performant que sur un serveur dédié. Il fonctionne de manière particulière et mobilise beaucoup plus de ressources que n'importe quel autre système...

A +

[Hotgeart]

500-600 users en ligne quand le serv' plante
>100 000 users
>3Millions de message par trim.

Sur ce serv' : http://www.ovh.com/fr/serveurs_dedie...hybrid_sas.xml

On peut me voir chialler aussi ici : http://forum.ovh.com/showthread.php?t=93126

J'ai deja mit :
le join à 4Mo
innodb_buffer_pool_size = 3G
innodb_additional_mem_pool_size = 64M

Voila ce que je peux en dire.

[SQLpro]

les conseils qu'on vous a donné sont déjà assez pertinents; Avez vous procédé à une campagne d'indexation adéquate ?

Certes MySQL ne dispose pas d'outil d'auto diagnostic, capable par exemple de vous donner ls liste des index manquant, comme c'est le cas avec SQL Server. mais il suffit d'analyser les requêtes les plus couteuses et en fonction de la façon dont elle sont écrite réaliser les index les plus couvrants possibles.

A +

[Hotgeart]

J'ai fait selon mes connaissances. Il y a surement moyen de faire mieux...

[SQLpro]

500-600 users en ligne quand le serv' plante
>100 000 users
>3Millions de message par trim.

Sur ce serv' : http://www.ovh.com/fr/serveurs_dedie...hybrid_sas.xml

On peut me voir chialler aussi ici : http://forum.ovh.com/showthread.php?t=93126

J'ai deja mit :
le join à 4Mo
innodb_buffer_pool_size = 3G
innodb_additional_mem_pool_size = 64M

Voila ce que je peux en dire.

Ce qui est certains, c'est que MySQL n'est absolument pas taillé pour ce genre de volumétrie...
C'est surtout le nombre d'utilisateurs. En pratique quand MySQL est à plusieurs dizaines d'utilisateurs simultanés (donc requêtes concurrentes en cours d'exécution) la contention se fait sentir....
Lisez ce que j'ai écrit sur MySQL : http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux

Il serait plus sain et moins couteux de changer de SGBDR et reprendre l'existant de votre base MySQL en la transposant sur au minimum du PostGreSQL, mais mieux du SQL Server ou du oracle.

Quand à la volumétrie du nombre de message (3 millions par trimestre) ce n'est pas grand chose ni en termes de volume ni en termes de transaction. Cela ne représente en moyenne que 23 transactions par minute, là ou un serveur comme SQL Server est capable d'en faire plusieurs millions (voir benchmark TPC C ou TPC W).
En volumétrie, j'ai par exemple une table SQL Server comportant 800 millions de lignes ou n'importe quelle requête de type SUM ou COUNT ne prends jamais plus de 50 ms avec un serveur à 5 000 € ! Les secrets étant :
1) un modèle parfaitement normalisé
2) un éventuel partitionnement des données
3) des vues indexées

A +

[rudib]

Je me joins un peu tard à la conversation. Si ce que tu veux stocker tiens dans un document JSON, auquel tu vas accéder via la clé, ou selon quelques critères assez simples, tu peux voir du côté de MongoDB. Pense aussi que MongoDB est intéressant parce qu'il est shardable. Donc tu peux monter en charge en ajoutant des machines, mais ce n'est peut-être pas ton idée pour ton type de site ? Pense aussi que le sharding sur Mongo est assez coûteux en nombre de machines : il faut un démon mongos, un serveur de config, et si tu répliques, trois fois chaque serveur.

Mais par rapport à ton besoin, il me semble qu'une solution peut être de combiner MySQL ou PostgreSQL avec Redis. Redis peut te permettre de décharger MySQL pour certaines requêtes que tu dois faire tout le temps. Peut-être que ça peut aider le newsfeed, mais j'avoue n'avoir pas très bien compris comment il fonctionne. Dans mon bouquin sur NoSQL j'ai fait une étude de cas avec le site Skyrock et Redis, ils l'utilisent beaucoup pour la perf et c'est un moteur très agréable et hyper rapide pour ses cas d'utilisation.