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

PostgreSQL Discussion :

optimisation du temps de recherche


Sujet :

PostgreSQL

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Inscrit en
    Décembre 2006
    Messages
    100
    Détails du profil
    Informations personnelles :
    Âge : 38

    Informations forums :
    Inscription : Décembre 2006
    Messages : 100
    Par défaut optimisation du temps de recherche
    bonjour a tous,

    j'aimerais avoir des avis concernant le problème auquel je suis confronté en stage :

    il existe une table "achats" , dans la bdd de l'entreprise qui contient des millions de lignes. On m a demandé de trouver une solution réduire le temps de recherche dans cette table. j ai pensé a 2 solutions (mais de nouvelles sont les bienvenues) :

    - j'exporte tous les ans la bdd dans un fichier et a la suite d'une recherche je recharge le fichier concernant la période désirée pour la recherche (les recherches concernent principalement l'année en cours, donc il y a rarement des recharges) ->inconvénient : le temps de recharge du/des fichiers peut rendre la recherche fastidieuse.

    - je créée une table "achats" par exercice. par exemple achats2008, achats2009. inconvenient->solution qui demande plus de place, meme si la capacité de stockage n'est pas un probleme pour moi.

    voila. n'hesitez pas me communiquer d'autres idées ou a corriger mes erreurs de raisonement

    merci

    ps : il s agit d une bdd postgres

  2. #2
    Membre Expert Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Par défaut
    Création d'indexes ou partitionnement (héritage de tables)
    Avec en tous les cas un calcul régulier des stats de la table
    La théorie, c'est quand on sait tout mais que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

    Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/

  3. #3
    Membre confirmé
    Inscrit en
    Avril 2008
    Messages
    89
    Détails du profil
    Informations forums :
    Inscription : Avril 2008
    Messages : 89
    Par défaut Comme Scheu
    Effectivement je pense que la première chose à faire (au niveau conception) est de poser des indexes sur les champs de ta table sur lesquels ton application de recherche permet d'opérer. A priori ces champs sont sûrement : date, année, etc...

    Dans le cas de champs liés à d'autres tables (par exemple un champ id_client lié à une table client) il est alors préférable de poser une foreign key (qui garantit l'intégrité référentielle) mais permet aussi un gain de temps. Si tu cherches tous les achats passé par "Un tel" (dont tu ne connais pas directement l'ID) alors ta requête risque d'être sensiblement plus rapide (du moins je le crois).

    Enfin, au niveau administration de ta base il faut bien sûr lancer des vacuums régulier sur cette table 'critique' et pourquoi pas d'autres analyses.

    Je ne suis vraiment pas expert et je te conseilles d'attendre d'autres avis qui pourront conforter ou infirmer ma position.

    En tout cas voilà un début... espèrons que d'autres contribuent car la réponse d'experts à ta question intéresse sûrement beaucoup de monde dont je suis...

    Cordialement,

  4. #4
    Membre confirmé
    Inscrit en
    Décembre 2006
    Messages
    100
    Détails du profil
    Informations personnelles :
    Âge : 38

    Informations forums :
    Inscription : Décembre 2006
    Messages : 100
    Par défaut
    merci pour vos réponses. en fait la table possèdes deja des indexes.
    la solution du partitionnement de la table par exercice me parait pertinente. je ne connaissait pas cette solution, elle m evitera de crééer une table par exercice...je vais creuser dans cette voie

    merki

  5. #5
    Membre Expert Avatar de scheu
    Inscrit en
    Juin 2007
    Messages
    1 506
    Détails du profil
    Informations forums :
    Inscription : Juin 2007
    Messages : 1 506
    Par défaut
    Tu as toutes les infos sur le partitionnement dans la doc officielle (selon ta version de base)
    De plus , faire régulièrement un VACUUM FULL de la table
    La théorie, c'est quand on sait tout mais que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi.
    Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi !

    Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/

  6. #6
    Membre confirmé
    Inscrit en
    Décembre 2006
    Messages
    100
    Détails du profil
    Informations personnelles :
    Âge : 38

    Informations forums :
    Inscription : Décembre 2006
    Messages : 100
    Par défaut
    rectification: après documentation sa m obligera bien a créer une table par exercices, mais sa reste une bonne solution

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. optimiser le temps d'exécution de l'explorateur windows
    Par ben_iap dans le forum Autres Logiciels
    Réponses: 6
    Dernier message: 31/01/2006, 22h04
  2. Réponses: 9
    Dernier message: 20/06/2005, 12h17
  3. [SGBD]Optimiser le temps d'accès aux données (schéma BD)
    Par vsavoir dans le forum Décisions SGBD
    Réponses: 5
    Dernier message: 08/10/2004, 18h33
  4. optimisation de temps de traitement xml/xslt
    Par Erwy dans le forum XSL/XSLT/XPATH
    Réponses: 2
    Dernier message: 06/05/2004, 16h08

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