1. #1
    Candidat au Club
    Inscrit en
    septembre 2008
    Messages
    4
    Détails du profil
    Informations forums :
    Inscription : septembre 2008
    Messages : 4
    Points : 2
    Points
    2

    Par défaut Problème de performance: clé primaire fonctionnelle telle que 1050000001

    Bonjour,

    Analysant un base de donnèes de calcul de trajets avec beaucoup de paramètres, je pense avoir trouver une source de problème de performance:
    La clé primaire utilisée pour tous les objets est une clé fonctionnelle dont les valeurs sont par ex:
    1050000001, 210000149 ...
    Pour collecter un seul trajet, la requete a mis 4mn7s....

    est ce que lún déntre vous pourrait svt me confirmer que cela doit etre modifié en utilisant une clé primaire interne auto-incrémentée ?

    Merci

  2. #2
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    5 555
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2007
    Messages : 5 555
    Points : 11 394
    Points
    11 394

    Par défaut

    Peut-être si vous pouvez justifier qu'"une clé primaire auto-incrémentée" est la source du problème.

  3. #3
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    Oracle ACE Director, DBA OCM 12c, consultant. En Suisse (dbi services)
    Inscrit en
    novembre 2007
    Messages
    1 558
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Suisse

    Informations professionnelles :
    Activité : Oracle ACE Director, DBA OCM 12c, consultant. En Suisse (dbi services)
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 558
    Points : 5 417
    Points
    5 417
    Billets dans le blog
    5

    Par défaut

    Bonjour,
    Citation Envoyé par hemeury Voir le message
    est ce que lún déntre vous pourrait svt me confirmer que cela doit etre modifié en utilisant une clé primaire interne auto-incrémentée ?
    Non,au contraire. Ca va juste rajouter une colonne de plus, un index de plus, des jointures de plus, ...
    Si la clé fonctionnelle est connue dés l'insert et ne change plus ensuite, c'est la bonne clé.
    Cordialement,
    Franck.
    Franck Pachot - Consultant et formateur (dbi services) - Oracle ACED - Oracle Certified Master 12c - Oak Table member - twitter: @FranckPachot
    Besoin d'une formation Oracle 12cR2 ?


  4. #4
    Candidat au Club
    Inscrit en
    septembre 2008
    Messages
    4
    Détails du profil
    Informations forums :
    Inscription : septembre 2008
    Messages : 4
    Points : 2
    Points
    2

    Par défaut

    Merci Pachot pour ton conseil mais j'avais toujours entendu qu'une clé primaire doit etre concise ...

    Alors j'insiste, cette clé primaire (ATTR_X) contient les valeurs suivantes:

    1050000001
    100060

    dans la meme table

    Cette donnee fonctionnelle est utilisee comme cle primaire pour une trentaines de tables.
    Il y a des requetes de 4 jointures et des conditions telles que: ATTR_X >= 1100000001 and ATTR_X <= 1149999999

    Afin de ne pas avoir de trop grosses tables, les attributs d'un objet B ont ete regroupes dans 4 tables differentes, en fonction de leur type: domains, date, char et numeric.
    Avec ce fameux attribut comme clé primaire.

    Les perfos sont catastrophiques ...
    Serait ce du a ce découpage en attribut ou a l'utilisation de cette clé priöaire fonctionnelle ?

    Je suis entrain de regénérer les statistiques et referai des tests de perfos ensuite...

    Merci pour votre contribution !!!

  5. #5
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 251
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 251
    Points : 39 953
    Points
    39 953
    Billets dans le blog
    1

    Par défaut

    Les deux !

    1) plus une clef est grosse moins elle est performante. En seek, pas très important. En scan beaucoup plus.
    2) une modélisation doit se faire selon les formes normales avant tout, par à la façon paire clef/valeur, sinon, passer à un SGBD spécialisé NoSQL qui sait faire ce genre de 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...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  6. #6
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    5 555
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2007
    Messages : 5 555
    Points : 11 394
    Points
    11 394

    Par défaut

    Citation Envoyé par hemeury Voir le message
    ...
    Cette donnee fonctionnelle est utilisee comme cle primaire pour une trentaines de tables.
    Il y a des requetes de 4 jointures et des conditions telles que: ATTR_X >= 1100000001 and ATTR_X <= 1149999999

    Afin de ne pas avoir de trop grosses tables, les attributs d'un objet B ont ete regroupes dans 4 tables differentes, en fonction de leur type: domains, date, char et numeric.
    Avec ce fameux attribut comme clé primaire.

    Les perfos sont catastrophiques ...
    ...
    C'était prévisible. Lisez Bad CaRMa pour comprendre dans quelle galère vous vous trouvez, c'est assez amusant.

  7. #7
    Expert confirmé
    Profil pro
    Inscrit en
    août 2008
    Messages
    2 600
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2008
    Messages : 2 600
    Points : 5 016
    Points
    5 016

    Par défaut

    Mouais, en fonction des requêtes le gain de sera de null à faible, pour le travail que ça engage et les risques, je ne suis pas convaincu que modifier la PK soit la bonne idée.

    Je n'ai pas bien compris le concept niveau modélisation, on est plutôt sur du partitionnement vertical ou sur du modèle EAV ?
    Si c'est du partitionnement vertical, je trouve étrange de le faire sur le type de données.
    L'EAV, c'est globalement contre performant.

    Vous pouvez nous en dire plus ?

  8. #8
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    Oracle ACE Director, DBA OCM 12c, consultant. En Suisse (dbi services)
    Inscrit en
    novembre 2007
    Messages
    1 558
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Suisse

    Informations professionnelles :
    Activité : Oracle ACE Director, DBA OCM 12c, consultant. En Suisse (dbi services)
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 558
    Points : 5 417
    Points
    5 417
    Billets dans le blog
    5

    Par défaut

    Citation Envoyé par hemeury Voir le message
    Merci Pachot pour ton conseil mais j'avais toujours entendu qu'une clé primaire doit etre concise ...
    Il n'y a vraiment aucune raison à ça.
    La comparaison de nombres de 4 ou 20 chiffres ne fera quasi pas de différence. Ce ne sont pas ces microsecondes qui vont poser un problème. Quand on parle d'accès par clé primaire, on parle de 100aine de microsecondes (si en cache) ou de millisecondes (si sur disque).

    Citation Envoyé par hemeury Voir le message
    Afin de ne pas avoir de trop grosses tables, les attributs d'un objet B ont ete regroupes dans 4 tables differentes, en fonction de leur type: domains, date, char et numeric.
    Avec ce fameux attribut comme clé primaire.
    Tout le secret de l'optimisation, c'est de stocker ensemble ce qui va être interrogé ensemble. Donc tout découper pour se retrouver à faire des jointures à chaque requêtes, c'est pas une bonne idée.
    Franck Pachot - Consultant et formateur (dbi services) - Oracle ACED - Oracle Certified Master 12c - Oak Table member - twitter: @FranckPachot
    Besoin d'une formation Oracle 12cR2 ?


  9. #9
    Candidat au Club
    Inscrit en
    septembre 2008
    Messages
    4
    Détails du profil
    Informations forums :
    Inscription : septembre 2008
    Messages : 4
    Points : 2
    Points
    2

    Par défaut

    Wahooouuu ! Merci pour vos réponses !

    Effectivement c'est un modèle EAV et d'après: http://www.magentix.fr/divers/modele...-database.html

    "Quels sont les inconvénients du modèle EAV ?

    L'inconvénient majeur du modèle EAV est sa vitesse. La répartition des données impose un nombre conséquent de jointure lors d'un enregistrement ou d'une sélection."

    Donc j'ai dèjà 2 bonnes raisons pour expliquer ce pb de perf:
    - modèle EAV
    -clè primaire fonctionnelle trop grosse

    je vais creuser aussi coté exploitation: modèle du serveur, RAM dispo, vitesse de rotation
    ( Merci Frédéric Brouard pour les cours dispo pour tous ! Synthétiques, bien écrit, vraiment une grande grande aide !)

    et expliquer à mon responsable ces soucis !

    Encore merci pour votre réactivité et le partage de vos connaissances et expèrience !


    P.S: Je commence à lire BadCarMa...

  10. #10
    Modérateur

    Homme Profil pro
    Ingénieur d'études en décisionnel
    Inscrit en
    septembre 2008
    Messages
    7 432
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'études en décisionnel
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2008
    Messages : 7 432
    Points : 15 715
    Points
    15 715

    Par défaut

    Vous ne lisez que ce qui vous arrange dites-donc.
    On vous dit que la clef primaire trop grosse n'est pas un vrai problème.

    J'aime beaucoup votre lien sur Magento :
    Le modèle EAV est utilisé car il est beaucoup plus souple et évolutif qu'un modèle de base de données habituel. Nous pouvons ajouter indéfiniment des attributs sans jamais modifier la structure même de la base (ALTER TABLE par exemple n'est jamais utilisé).
    Et quatre lignes plus loin :
    Pour palier au problème de performance, Magento a imaginé un système de FLAT. Le FLAT rassemble au sein d'une même table l'ensemble des données. Magento offre donc la souplesse d'un modèle EAV associé à la rapidité d'un modèle de base classique !
    Du coup, quand ils rajoutent un attribut à un produit, ils ont droit aux requêtes pénibles et alambiquées ET à l'alter table dans le modèle "flat".
    Chapeau !

Discussions similaires

  1. [jeu]problème de performance d'un algo
    Par le Daoud dans le forum Général Algorithmique
    Réponses: 12
    Dernier message: 30/05/2005, 16h07
  2. [C#] Probléme de performance avec IsDbNull
    Par jab dans le forum Windows Forms
    Réponses: 8
    Dernier message: 04/04/2005, 11h39
  3. [oracle 9i][Workbench]Problème de performance
    Par nuke_y dans le forum Oracle
    Réponses: 6
    Dernier message: 03/02/2005, 17h38
  4. Recherche BDD telle que PGS sous Windows sans Cygwin ... :(
    Par Shepard dans le forum Décisions SGBD
    Réponses: 2
    Dernier message: 20/12/2004, 15h41
  5. [ POSTGRESQL ] Problème de performance
    Par Djouls64 dans le forum PostgreSQL
    Réponses: 6
    Dernier message: 26/05/2003, 16h18

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