Discussion :

[shoooryuken]

Bonjour,

On m'a proposé un projet de développement pour mon taf, mais je n'ai pas l'habitude de si gros chantier.

Je vais devoir créer un planning pour 4000 personnes, 24 créneaux horaires/jours, 6 jours semaine, sur 1 mois (et je purge chaque jour les rendez vous de la journée j-1)
soit environ 2 500 000 entrées... chaque entrée reste légère, 15 champs de maximum 50 caractères.

Sur ces 2 500 000, il faut bien sur que je puisse réaliser des recherches, des modifications, ... enfin, que environ 4000 personnes puissent modifier, rechercher, effacer, ...

J'ai un doute sur la qualité de réponse de mes requêtes...

Avez vous des retours sur les capacités/qualité de réponse des bases de données Mysql?

Avez vous des recommandations? astuces?
Merci par avance.

[Artemus24]

Salut shoooryuken.

Avez vous des recommandations? astuces?

1) vous devez travailler sur la modélisation de votre base de données.
C'est le point le plus important car il va conditionner en partie vos performances mais aussi la complexité de votre demande.

2) En admettant que la modélisation soit correcte, vous devez ensuite travailler sur les performances.
--> Ajout d'index.
--> Reformuler les requêtes pour trouver celle qui est la plus performante.
--> Si nécessaire, dégrader les formes normales de vos tables, afin d'obtenir plus de performances.

3) Si la volumétrie devient très importante, vous devez booster votre matériel.
--> Ajouter de la RAM
--> Mettre un processeur plus rapide, ayant plusieurs cœurs.
--> Passer dans une organisation RAID pour avoir plus de sécurité en cas de plantage du matériel.
...

4) Utiliser un SGBDR professionnel comme Microsoft SQL Serveur.
Oui, il y a une licence à payer, mais cela compenser largement les problèmes de maintenances et de performances liés à ce type de SGBDR.

@+

[shoooryuken]

Merci beaucoup pour la réponse,

il faut que je retravaille un peu mon Merise, mais, il n'y a pas 50 tables, c'est jusque que chaque table va avoir beaucoup d'enregistrement.

Mon collègue a eu l'idée de scindé le contenu de la base dans plusieurs bases de données différentes afin de diminuer la charge de traitement de chacune.
Je ne sais pas si c'est une bonne idée...
En effet, il y a 8 grandes équipes subdivisées en une 100 aine d'agence -> d'environ 5 agents.
Plutôt que de traiter 800 enseignes et 4000 agents, nous en gérerions 8 bdd de 100 enseignes pour 500 agents. A raison de 24 rdv/jours, 6 jours semaine, sur 1 mois... A la place de gérer une base de donnée avec 2 400 000 entrées, nous gérerions 8 bases de données de 300 000 entrées.

A voir les performances du serveur à gérer 8 bases de données "modestes" ou une très grosse base de données très sollicité.

Je fais des recherches sur l'optimisation de la Bdd et des requêtes
Je viens de commander des livres sur le sujet, ...

Revoir le matériel ne devrait pas être le problème. (dans une mesure raisonnable)

[SQLpro]

Mon collègue a eu l'idée de scindé le contenu de la base dans plusieurs bases de données différentes afin de diminuer la charge de traitement de chacune.
Je ne sais pas si c'est une bonne idée...
En effet, il y a 8 grandes équipes subdivisées en une 100 aine d'agence -> d'environ 5 agents.
Plutôt que de traiter 800 enseignes et 4000 agents, nous en gérerions 8 bdd de 100 enseignes pour 500 agents. A raison de 24 rdv/jours, 6 jours semaine, sur 1 mois... A la place de gérer une base de donnée avec 2 400 000 entrées, nous gérerions 8 bases de données de 300 000 entrées.

ça c'est une grosse connerie ! En effet, ceci va multiplier les machines, la maintenance, les pannes, etc. Imaginez que votre application devienne critique pour l'entreprise il faudra donc 8 nouveaux serveur pour redonder les 8 bases, etc....

2 500 000 lignes dans une table ce n'est pas grand chose pour un bon SGBDR... C'est un peu la limite dans MySQL !

le point important est la modélisation et généralement c'est toujours la chose la plus mal faite !

A +

[escartefigue]

le point important est la modélisation et généralement c'est toujours la chose la plus mal faite !

Oui, et y compris bien malheureusement, dans les grandes entreprises qui disposent de moyens financiers solides et d'équipes DSI conséquentes !

[SQLpro]

Oui, et y compris bien malheureusement, dans les grandes entreprises qui disposent de moyens financiers solides et d'équipes DSI conséquentes !

Je suis payé pour le savoir... je fais environ 5 à 6 audits de bases de données par an... Et effectivement PME comme BIG, mais surtout vieilles entreprises !

A +

[Artemus24]

Salut shoooryuken.

il faut que je retravaille un peu mon Merise, mais, il n'y a pas 50 tables, c'est jusque que chaque table va avoir beaucoup d'enregistrement.

Ce n'est pas le nombre de tables, ni la volumétrie de vos tables qui posent des problèmes.
C'est essentiellement la façon d'accéder à vos lignes qui peuvent provoquer une dégradation des performances.
Si un utilisateurs accède à environ 10 000 lignes, sans avoir la nécessité de balayer la totalité de la table, que votre table fasse 10 milliards ou simplement 10 000 lignes, la performance sera la même.
D'où la nécessité d'avoir des critères précis (clause where) et d'avoir installé des index pour y accéder d'une manière performante.

De même pour des requêtes en cascades. Quand votre modèle est bien fait, et que vos critères sont précis, la performance est au rendez-vous.

Mon collègue a eu l'idée de scindé le contenu de la base dans plusieurs bases de données différentes afin de diminuer la charge de traitement de chacune.
Je ne sais pas si c'est une bonne idée...

Il n'y a pas de bonnes ou de mauvaises idées, il y a juste une incapacité individuelle à les mettre en oeuvre.
Cela dépend aussi du nombre d'utilisateurs qui accèdent à une base de données.
Logiquement, votre découpage se fait par groupe de 500 agents, et du coup le nombre d'accès est plus faible.
Oui sauf qu'il faut aussi tenir compte de la bande passante de votre réseau.

A la place de gérer une base de donnée avec 2 400 000 entrées, nous gérerions 8 bases de données de 300 000 entrées.

Donc vous avez un critère pour sélectionner la ligne dans la bonne base de données.
Au lieu d'avoir à gérer huit bases de données, le mieux pour une table est de créer des partitions.

--> http://krierjon.developpez.com/mysql/partitionnement/
C'est un peu vieux (2006), mais toujours d'actualité.

Revoir le matériel ne devrait pas être le problème. (dans une mesure raisonnable)

La bonne question est d'identifier le goulot d'étrangement de votre projet :
--> accès réseau, avec un trafic mal réparti.
--> débit réseau trop faible.
--> matériel trop sollicité ou encore pas assez performant
--> mauvaise répartition de vos fichiers partitions sur les disques (toutes les partitions sur le même contrôleur de disques).
--> mauvais paramétrage (fichier my.ini) de votre serveur MySql.
--> requêtes mal configurées et du coup, gros problème de performance.
--> modélisation de votre base de données mal configurée.
--> pas d'index sur les critères de vos sélections.
--> pas de partitions afin de réduire ce que vous sélectionnez.
--> mauvais usage de la primary key ou si vous préférez les données sont trop dispersées sur le disque.

Il y a tellement de causes qu'il est difficile de toutes les répertorier.

@+

[shoooryuken]

Salut shoooryuken.

La bonne question est d'identifier le goulot d'étrangement de votre projet :

merci pour ces réponses complètes et claires.

Nous sommes en période de mise à plat du projet, nous n'avons aucun goulet d'étranglement, puisque le projet n'a pas dépassé le papier.
Nous sommes entrain de modéliser la bdd.
Je précise juste que le matériel ne devrait normalement pas être un frein...

[selecta]

Salut shoooryuken,

Y a pas lieu de s'inquiéter avec de tels volumes sur MYSQL.
Par contre vouloir passer par 8 serveurs va à l'encontre de bonnes performances sans parler des efforts et couts de maintenance, mieux vaut avoir 1seul serveur (voir 2 en mode cluster maitre-esclave basé sur 1 réplication de données) et 1 seul schéma

Artemus24 te propose dans sa liste de recommandation le recours au partitionnement, ça peut être 1 solution de définir un partitionnement par jour, par service, par agence à condition que les clauses where des requêtes portent la clé de partition.
Mais au vu des volumes de quelques millions de lignes, ça n'est pas utile de partitionner, on pense partitionnement au minimum à partir de quelques dizaines de millions de lignes et avec un poids d'enregistrements de quelques dizaines de colonnes, même sur MYSQL

Pour les volumes : 2,5 millions de lignes n'est pas une limite pour MYSQL qui sait parfaitement gérer des volumes bien plus conséquents.
MYSQL a bien évolué depuis la 5.6, très fréquent de voir des tables de 100 millions de lignes sur 1 occupation de 200 Mo/ table !!

Cordialement

selecta

[Artemus24]

Salut selecta.

Hormis pour des questions de performances quand la requête est alignée sur la partition, ou de volumétrie, le seul usage que je trouve intéressant est la purge.
Il est bien plus rapide de détruire une partition que de faire des "delete" en pagaille sur une énorme table, puis ensuite de la réorganiser.

10 millions de lignes ce n'est pas ce que j'appelle une énorme table.

@+