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

Optimisations SGBD Discussion :

Grosse base de données Mysql et performances PHP


Sujet :

Optimisations SGBD

  1. #1
    Membre régulier
    Inscrit en
    Novembre 2007
    Messages
    250
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 250
    Points : 75
    Points
    75
    Par défaut Grosse base de données Mysql et performances PHP
    Bonjour à tous,

    Étant novice dans la gestion de grosses bases de données, je m'en remets à vos conseils.

    J'ai actuellement une table par "centrale", une centrale fournit de multiples informations par jours, et remplit donc progressivement sa table. La problématique est qu'une de nos "centrales" remplit sa bdd à une vitesse très rapide, nous sommes à 40Go de données en 3 mois. Ce qui pose évidement des soucis de performance lors des requêtes php (qui sont déjà optimisées).

    Ces tables "centrale" vont donc grossir de plus en plus, et j'ai besoin d'une solution afin de trouver de meilleures performances.

    J'ai pensé découper les tables "centrale" en différentes tables "centraleX_2011-09", "centraleX_2011-08", etc...

    Le problème c'est que je sens bien le 10/15Go de données par mois, et ça me semble encore trop faible comme découpage pour avoir de bonnes performances.
    Et faire une table par jour deviendrait un gros bordel dans phpmyadmin...

    Auriez vous des solutions alternatives ?

    Merci d'avance.

  2. #2
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 792
    Points : 34 013
    Points
    34 013
    Billets dans le blog
    14
    Par défaut
    Que sont ces "centrales" ?
    Que sont ces données qui arrivent à vitesse rapide ?
    Pourquoi une des centrales alimente t-elle sa table plus vite que les autres ?
    Quelle est la structure type d'une de ces tables "centrale" ?

    Est-il nécessaire de conserver toute les données à brève, moyenne et longue échéance ?
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  3. #3
    Membre régulier
    Inscrit en
    Novembre 2007
    Messages
    250
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 250
    Points : 75
    Points
    75
    Par défaut
    Les centrales sont des FTP indépendant qui sont analysés, ils contiennent des csv qui sont eux aussi analysés afin d'être retranscris dans la table de la centrale.
    La table d'une centrale est toujours la même, 20 champs, un champ id, deux champs date (datetime et timestamp), le reste sont des varchar(255).

    Le fait qu'une table soit plus alimentée qu'une autre vient du fait de la production de donnée plus importante sur une centrale que sur une autre, et nous n'avons pas la main là dessus.

    Les lignes en bdd ne peuvent pas être "compressées", car nous avons besoin d'accéder aux données historique de manière précise (ex : aujourd'hui nous demandons toutes les données du 20 décembre 2002 pour une centrale donnée).

    J'ai pensé au partitionnement par jour... ?

  4. #4
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 792
    Points : 34 013
    Points
    34 013
    Billets dans le blog
    14
    Par défaut
    Si je comprends bien, une table de centrale est alimentée par les fichiers csv ?

    Il y a donc 17 colonnes varchar(255) dans la table, ce qui fait bien lourd avec un important volume de données.
    Les données issues d'un fichier CSV sont rarement correctement modélisées. Ces données devraient être réparties dans les tables d'une BDD normalisée, ce qui devrait réduire considérablement le volume de données à traiter et accélérer les traitements sur les données.

    Peut-on voir en exemple quelques lignes d'une table centrale avec, bien sûr, la structure de la table et la signification des colonnes ?
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  5. #5
    Membre régulier
    Inscrit en
    Novembre 2007
    Messages
    250
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 250
    Points : 75
    Points
    75
    Par défaut
    Merci de ton aide.

    Oui en effet tables alimentées par des csv que j'analyse en amont.

    Voici un exemple d'une table avec 6 lignes :

    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
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
     
    CREATE TABLE `MaCentrale` (
      `releve_id` int(11) NOT NULL AUTO_INCREMENT,
      `onduleur_id` varchar(255) NOT NULL,
      `pac` varchar(255) NOT NULL,
      `iac` varchar(255) NOT NULL,
      `vac` varchar(255) NOT NULL,
      `pcc1` varchar(255) NOT NULL,
      `pcc2` varchar(255) NOT NULL,
      `ucc1` varchar(255) NOT NULL,
      `icc1` varchar(255) NOT NULL,
      `ucc2` varchar(255) NOT NULL,
      `icc2` varchar(255) NOT NULL,
      `edaily` varchar(255) NOT NULL,
      `eweekly` varchar(255) NOT NULL,
      `emonth` varchar(255) NOT NULL,
      `eyear` varchar(255) NOT NULL,
      `etotal` varchar(255) NOT NULL,
      `epartial` varchar(255) NOT NULL,
      `date` datetime NOT NULL,
      `date_insert` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
      `file` varchar(255) NOT NULL,
      PRIMARY KEY (`releve_id`)
    ) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=20249 ;
     
    --
    -- Contenu de la table `MaCentrale`
    --
     
    INSERT INTO `MaCentrale` VALUES(10236, '225587', '5935.91', '7.867', '239.466', '3949.215', '2103.288', '533.96', '7.245', '514.954', '4.062', '17759', '0', '0', '0', '0', '0', '2011-07-28 12:10:00', '2011-08-07 05:19:42', 'MaCentrale_INV_1_1_110728_103020.csv.gz');
    INSERT INTO `MaCentrale` VALUES(10237, '225587', '4761.839', '6.215', '240.096', '3167.993', '1675.513', '548.267', '5.668', '534.857', '3.128', '18490', '0', '0', '0', '0', '0', '2011-07-28 12:20:00', '2011-08-07 05:19:42', 'MaCentrale_INV_1_1_110728_103020.csv.gz');
    INSERT INTO `MaCentrale` VALUES(10238, '225587', '4895.292', '6.422', '239.789', '3293.91', '1686.46', '542.218', '6.04', '532.292', '3.17', '19356', '0', '0', '0', '0', '0', '2011-07-28 12:30:00', '2011-08-07 05:19:42', 'MaCentrale_INV_1_1_110728_103020.csv.gz');
    INSERT INTO `MaCentrale` VALUES(10239, '240977', '6187.081', '8.083', '239.407', '4104.207', '2207.123', '556.7', '7.032', '538.528', '4.043', '18468', '0', '0', '0', '0', '0', '2011-07-28 12:10:00', '2011-08-07 05:19:42', 'MaCentrale_INV_1_1_110728_103020.csv.gz');
    INSERT INTO `MaCentrale` VALUES(10240, '240977', '5086.869', '6.542', '239.938', '3390.576', '1780.113', '563.993', '5.868', '556.544', '3.171', '19293', '0', '0', '0', '0', '0', '2011-07-28 12:20:00', '2011-08-07 05:19:42', 'MaCentrale_INV_1_1_110728_103020.csv.gz');

  6. #6
    Membre régulier
    Inscrit en
    Novembre 2007
    Messages
    250
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 250
    Points : 75
    Points
    75
    Par défaut
    Les différents champs varchar sont ceux sur lesquels je fais mes calculs en front.
    Ils sont en varchar et non en float car j'ai eu un problème avec une requête qui ne voulait passer que si les champs était en varchar... J'arriverais pas à te retrouver exactement la requête je pense

  7. #7
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 792
    Points : 34 013
    Points
    34 013
    Billets dans le blog
    14
    Par défaut
    Que veux-tu dire par "que j'analyse en amont." ?
    Cela veut-il dire qu'un CSV est en fait le résultat d'une analyse de données ?

    À ce que je vois, la plupart des colonnes sont des nombres. Elles ne devraient pas être du type VARCHAR.
    Seule la dernière colonne est vraiment un VARCHAR, qui plus est très répétitif. Cette dernière devrait être externalisée dans une table des fichiers et il ne devrait y avoir ici que l'identifiant du fichier.
    Je vois aussi des colonnes, pcc1 et 2, icc1 et 2, ucc 1 et 2. N'y aura t-il toujours que 2 colonnes de chaque sorte ? Peut-il y en avoir zéro ou une seule ou plus de deux ?

    Ces données sont-elles des relevés de mesures sur des onduleurs ? Intensité, tension et puissance actives et de court-circuit ?

    Décris-nous un peu le processus qui conduit à l'obtention de ces données et à quoi elles sont destinées, pourquoi on les stocke en BDD alors qu'elles existent en fichiers CSV, pour en faire quoi ?
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  8. #8
    Membre régulier
    Inscrit en
    Novembre 2007
    Messages
    250
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 250
    Points : 75
    Points
    75
    Par défaut
    En effet tu as compris le processus, il s'agit de données d'onduleurs. Une centrale comporte plusieurs onduleurs. Cette centrale envoi un csv toutes les heures environ, ce csv est ensuite traité par un process php afin de convertir les données reçu de la même manière pour toutes les centrales (car certaines les envoient sous des formes différentes, et nous devons faire des calculs en amont).

    La dernière colonne est en effet répétitive, mais nous avons besoin de savoir pour telle donnée d'où elle vient, donc en effet c'est répétitif mais pas trop le choix ici.

    Les formats Varchar regarde mon message plus haut, à cause d'une requête j'étais obligé de passer par ça pour que les calculs soient bons... Incompréhensible d'ailleurs.

  9. #9
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 792
    Points : 34 013
    Points
    34 013
    Billets dans le blog
    14
    Par défaut
    Plutôt que FLOAT qui peut effectivement causer des problèmes dans les calculs, utilise DECIMAL.

    D'une manière générale, je t'encourage à ne pas travailler sur les données brutes mais à les incorporer dans une structure de données normalisée.

    Bon courage.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  10. #10
    Membre régulier
    Inscrit en
    Novembre 2007
    Messages
    250
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 250
    Points : 75
    Points
    75
    Par défaut
    Ok no problèmes, merci pour ça.

    Par contre au niveau de l'optimisation bdd tu aurais une idée ? Car sur une table j'ai plus de 300 millions d'enregistrements, et c'est là qu'on a des problèmes (40Go la table)

  11. #11
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 792
    Points : 34 013
    Points
    34 013
    Billets dans le blog
    14
    Par défaut
    Ta table fait 40 Go en grande partie à cause des varchar(255) et notamment de la dernière colonne qui est la plus coûteuse en espace.
    Si tu externalises le nom du fichier et que tu mets à la place dans la table centrale un entier référençant l'identifiant du fichier, cela n'occupera plus que 4 octets par ligne au lieu des 40 octets de ton exemple de données, soit 1,2 Go pour 300 millions de lignes au lieu de 12 Go.

    Les décimaux par contre sont apparentés aux chaînes de caractères donc tu ne gagneras pas beaucoup de place avec eux.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  12. #12
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 144
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Pourquoi ne pas stocker :
    - Les CSV dans un CLOB (s'il s'agit que de restituer les données, pas besoin de les structurer)
    - Ou de stocker uniquement le chemin d'accès au fichier CSV, qui sera éventuellement stocké sur un NAS compressé, ou dans des ZIP mensualisés.
    On ne jouit bien que de ce qu’on partage.

  13. #13
    Membre régulier
    Inscrit en
    Novembre 2007
    Messages
    250
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 250
    Points : 75
    Points
    75
    Par défaut
    @CinePhil :
    Sur une table de test (3millions d'enregistrements) j'ai supprimer la colonne "file" et passé toutes les autres varchar en decimal(10,0), je passe de 430Mo à 330Mo

    @StringBuilder :
    CLOB je connais pas.
    Mais si je comprends ton idée c'est un stockage des csv ?
    On a besoin d'avoir les données dispo de suite pour un affichage immédiat, c'est la base de notre appli, elle a besoin de toutes ces infos de manière permanente pour les afficher en front, donc je pense pas que le stockage soit une bonne soluce car on devra extraire et analyser les zip à chaque demande en front, donc assez lourd à mon avis...

  14. #14
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 792
    Points : 34 013
    Points
    34 013
    Billets dans le blog
    14
    Par défaut
    Citation Envoyé par Dev@lone Voir le message
    @CinePhil :
    Sur une table de test (3millions d'enregistrements) j'ai supprimer la colonne "file" et passé toutes les autres varchar en decimal(10,0), je passe de 430Mo à 330Mo
    Euh... DECIMAL(10,0), c'est un entier ! Le zéro représente le nombre de chiffres après la virgule et le premier nombre représente le nombre de chiffres au total.

    Dans tes données exemples, tu as une précision de 3 décimales donc un DECIMAL(10, 3) serait plus approprié. Voire même moins de 10 car tes données ne donnent que des nombres à maximum 7 chiffres.

    D'ailleurs, tu pourrais aussi étudier la possibilité de ne stocker que des entiers, ce qui prendrait beaucoup moins de place (un entier occupe 4 octets), et de diviser par 1000 lors de la présentation des données.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  15. #15
    Modérateur
    Avatar de Waldar
    Homme Profil pro
    Customer Success Manager @Vertica
    Inscrit en
    Septembre 2008
    Messages
    8 452
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Customer Success Manager @Vertica
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2008
    Messages : 8 452
    Points : 17 811
    Points
    17 811
    Par défaut
    J'ajouterai qu'il ne faut pas supprimer vos deux dernières colonnes, il faut les changer par un identifiant de traitement, c'est la proposition initiale de Cinephil : il parle du nom du fichier, mais la date qui est attachée c'est exactement pareil, un timestamp c'est une quinzaine d'octets je ne sais plus exactement.

    Imaginez une table comme ceci (je ne sais pas si vous avez des règles de nommage, vous pouvez toujours adapter) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    CREATE TABLE `Traitement`
    (
        trt_id           int          NOT NULL AUTO_INCREMENT,
        trt_date_insert  timestamp    NOT NULL DEFAULT CURRENT_TIMESTAMP,
        trt_nom_fichier  varchar(255) NOT NULL,
        PRIMARY KEY (`trt_id`)
    )
    Et dans votre table MaCentrale vous remplacez vos deux dernières colonnes par ce trt_id.

  16. #16
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 144
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Dev@lone Voir le message
    @StringBuilder :
    CLOB je connais pas.
    Mais si je comprends ton idée c'est un stockage des csv ?
    On a besoin d'avoir les données dispo de suite pour un affichage immédiat, c'est la base de notre appli, elle a besoin de toutes ces infos de manière permanente pour les afficher en front, donc je pense pas que le stockage soit une bonne soluce car on devra extraire et analyser les zip à chaque demande en front, donc assez lourd à mon avis...
    CLOB, c'est un type de donnée Oracle (mais il y a le même avec MySQL, sous un autre nom peut-être, BLOB par exemple, ou TEXT).

    Ce type de donnée permet de stocker jusqu'à 2 Go de données dans un enregistrement. En revanche, la place occupée dans la table n'est que celle d'un pointeur vers la donnée, stockée physiquement ailleurs dans le tablespace.

    Ceci permet d'avoir des temps de réponse très intéressants sur la table elle-même, tout en conservant le fichier dans la base de données.

    En ce qui concerne le ZIP, le temps de compression/décompression d'un fichier ZIP est généralement plus court que le temps d'accès sur le disque du fichier non compressé. D'ailleurs, c'est tellement rapide que la plupart des sites web compressent à la volée les pages avant de les envoyer au navigateur, qui les décompresse alors (gain notable de bande passante, et donc de vitesse). Il n'y a donc rien de surprenant à stocker les données (dabns un CLOB ou non) dans un format compressé.
    En revanche, il est évidement plutôt préférable dans ton cas d'opter pour un ZIP par fichier. Ceci n'est intéressant que si les CSV sont un minimum volumineux (plusieurs centaines de Ko, sinon en effet ça sert à rien).

    Le seul point négatif du CLOB combiné ou non au ZIP (ou d'un stockage externe à la base, en ZIP ou non) c'est qu'il sera impossible de faire des recherches sur les données contenues dans les CSV. Rien ne t'empêche cependant de mélanger les deux (stocker dans la table ou un deux valeurs clés du CSV, et stocker le reste du fichier dans un CLOB ou sur disque).
    On ne jouit bien que de ce qu’on partage.

  17. #17
    Membre régulier
    Inscrit en
    Novembre 2007
    Messages
    250
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 250
    Points : 75
    Points
    75
    Par défaut
    @CinePhil :
    En mettant des INT partout je descend à 281Mo sur la table de test, donc la différence n'est pas flagrante et à mon avis je ne réduirais pas la table de 40Go avec cette méthode

    @Waldar :
    Si je comprends bien le but serait d'externaliser les données file et timestamp selon vous ?

    Afin de regrouper vos propals j'ai supprimer les champs qui posent souci, et mis en INT les autres, voici le resultat :

    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
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
     
     
     
    CREATE TABLE `MaCentrale` (
      `releve_id` int(11) NOT NULL AUTO_INCREMENT,
      `onduleur_id` int(11) NOT NULL,
      `pac` int(11) NOT NULL,
      `iac` int(11) NOT NULL,
      `vac` int(11) NOT NULL,
      `pcc1` int(11) NOT NULL,
      `pcc2` int(11) NOT NULL,
      `ucc1` int(11) NOT NULL,
      `icc1` int(11) NOT NULL,
      `ucc2` int(11) NOT NULL,
      `icc2` int(11) NOT NULL,
      `edaily` int(11) NOT NULL,
      `eweekly` int(11) NOT NULL,
      `emonth` int(11) NOT NULL,
      `eyear` int(11) NOT NULL,
      `etotal` int(11) NOT NULL,
      `epartial` int(11) NOT NULL,
      `date` datetime NOT NULL,
      PRIMARY KEY (`releve_id`)
    ) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=22561852 ;
     
    --
    -- Contenu de la table `MaCentrale`
    --
     
    INSERT INTO `MaCentrale` VALUES(20729799, 227578, 2255, 3, 225, 1494, 830, 427, 3, 472, 2, 53605, 0, 0, 0, 0, 0, '2011-05-30 18:00:00');
    INSERT INTO `MaCentrale` VALUES(20729800, 227576, 2364, 3, 225, 1597, 788, 471, 3, 465, 2, 67981, 0, 0, 0, 0, 0, '2011-05-30 18:00:00');
    INSERT INTO `MaCentrale` VALUES(20729801, 227619, 3243, 4, 225, 1668, 1676, 474, 3, 475, 3, 78110, 0, 0, 0, 0, 0, '2011-05-30 18:00:00');
    INSERT INTO `MaCentrale` VALUES(20729802, 227608, 2223, 3, 225, 1247, 990, 399, 3, 313, 3, 53835, 0, 0, 0, 0, 0, '2011-05-30 18:00:00');
    Nous passons de 430Mo à 270Mo sur la table de test (3 millions d'enregistrement), donc un gain de moins de 50%, ce qui n'est donc pas gérable pour moi.

    Que pensez vous du partitionnement ? Je pensais faire une partition par jour ?

  18. #18
    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
    Dans votre cas les problèmes de dégradation des perfs sont liés à deux défaut majeur de MySQL :
    1) MySQL ne possède pas d'ETL dédié pour absorber de gros fichier à intégrer...
    Regardez en comparaison les performances d'un ETL comme SSIS dédié à SQL Server...
    http://msdn.microsoft.com/en-us/libr...ql.100%29.aspx
    En effet l'ETL travaille en parallèle ses fichiers en activant tous les CPU disponible pour insérer les lignes, ce que ne fait pas MySQL qui travaille toutes ses requête en mono thread !
    2) MySQL est très loin de valoir du Oracle, du SQL Server, voir même du postGreSQL en matière d'indexation (a lire http://blog.developpez.com/sqlpro/p9...t-sur-l-index/) comme en matière d'optimisation des requêtes (certaines requêtes sont infaisables sous MySQL... http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/)

    Bref vous aurez du mal à optimiser la chose...

    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/ * * * * *

Discussions similaires

  1. Grosse base de données et performances
    Par Promeneur dans le forum Optimisations
    Réponses: 26
    Dernier message: 19/05/2012, 12h47
  2. [MySQL] Requête pour vérifier base de donné Mysql en php
    Par srab2pac dans le forum PHP & Base de données
    Réponses: 8
    Dernier message: 13/06/2008, 10h48
  3. Problème de copie d'une base de données MySQL avec PHP
    Par rheem dans le forum SQL Procédural
    Réponses: 4
    Dernier message: 15/10/2007, 15h52
  4. [MySQL] Synchronisation de base de données MySQL en PHP
    Par takepaf dans le forum PHP & Base de données
    Réponses: 3
    Dernier message: 12/07/2007, 12h23
  5. [Crystal] Performance sur grosses base de données
    Par Nico118 dans le forum SAP Crystal Reports
    Réponses: 5
    Dernier message: 14/11/2003, 16h27

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