IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MySQL Discussion :

Performance Mysql - quantité de donnée traitée


Sujet :

MySQL

  1. #1
    Nouveau membre du Club
    Homme Profil pro
    amateur
    Inscrit en
    Mars 2014
    Messages
    28
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations professionnelles :
    Activité : amateur

    Informations forums :
    Inscription : Mars 2014
    Messages : 28
    Points : 26
    Points
    26
    Par défaut Performance Mysql - quantité de donnée traitée
    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.

  2. #2
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 344
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 344
    Points : 18 919
    Points
    18 919
    Par défaut
    Salut shoooryuken.

    Citation Envoyé par 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.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  3. #3
    Nouveau membre du Club
    Homme Profil pro
    amateur
    Inscrit en
    Mars 2014
    Messages
    28
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations professionnelles :
    Activité : amateur

    Informations forums :
    Inscription : Mars 2014
    Messages : 28
    Points : 26
    Points
    26
    Par défaut
    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)

  4. #4
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 344
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 344
    Points : 18 919
    Points
    18 919
    Par défaut
    Salut shoooryuken.

    Citation Envoyé par 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.

    Citation Envoyé par shoooryuken
    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.

    Citation Envoyé par shoooryuken
    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é.

    Citation Envoyé par shoooryuken
    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.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  5. #5
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par shoooryuken Voir le message
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  6. #6
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 059
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 059
    Points : 38 269
    Points
    38 269
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    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 !

  7. #7
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  8. #8
    Nouveau membre du Club
    Homme Profil pro
    amateur
    Inscrit en
    Mars 2014
    Messages
    28
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations professionnelles :
    Activité : amateur

    Informations forums :
    Inscription : Mars 2014
    Messages : 28
    Points : 26
    Points
    26
    Par défaut
    Citation Envoyé par Artemus24 Voir le message
    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...

  9. #9
    Membre régulier
    Profil pro
    Administrateur de base de données
    Inscrit en
    Juillet 2003
    Messages
    94
    Détails du profil
    Informations personnelles :
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Juillet 2003
    Messages : 94
    Points : 116
    Points
    116
    Par défaut
    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

  10. #10
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    Février 2011
    Messages
    6 344
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : Février 2011
    Messages : 6 344
    Points : 18 919
    Points
    18 919
    Par défaut
    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.

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

Discussions similaires

  1. Dégradation des performances avec la quantité de données chargées
    Par matdev62 dans le forum Général Conception Web
    Réponses: 4
    Dernier message: 06/01/2011, 15h56
  2. [Excel] PHP-MYSQL exportation de données vers un fichier excel
    Par toure32 dans le forum Bibliothèques et frameworks
    Réponses: 4
    Dernier message: 19/10/2005, 20h29
  3. performances mysql (10 a 100 millions de rows)
    Par killy-kun dans le forum Outils
    Réponses: 1
    Dernier message: 21/07/2005, 16h06
  4. [Conception][performance] mysql table de 10000 enregistrements / hashmap
    Par debdev dans le forum Collection et Stream
    Réponses: 5
    Dernier message: 09/07/2005, 12h29
  5. [Comparatifs] Limites nombres tables et quantité de données
    Par benj63 dans le forum Décisions SGBD
    Réponses: 7
    Dernier message: 13/06/2002, 22h31

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo