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

Oracle Discussion :

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


Sujet :

Oracle

  1. #1
    Membre du Club
    Inscrit en
    Septembre 2008
    Messages
    16
    Détails du profil
    Informations forums :
    Inscription : Septembre 2008
    Messages : 16
    Points : 67
    Points
    67
    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 611
    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 611
    Points : 11 252
    Points
    11 252
    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 éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    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 - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  4. #4
    Membre du Club
    Inscrit en
    Septembre 2008
    Messages
    16
    Détails du profil
    Informations forums :
    Inscription : Septembre 2008
    Messages : 16
    Points : 67
    Points
    67
    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 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
    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...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  6. #6
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    5 611
    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 611
    Points : 11 252
    Points
    11 252
    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 947
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 2 947
    Points : 5 846
    Points
    5 846
    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 éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    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 - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  9. #9
    Membre du Club
    Inscrit en
    Septembre 2008
    Messages
    16
    Détails du profil
    Informations forums :
    Inscription : Septembre 2008
    Messages : 16
    Points : 67
    Points
    67
    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
    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
    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 Algorithmes et structures de données
    Réponses: 12
    Dernier message: 30/05/2005, 17h07
  2. [C#] Probléme de performance avec IsDbNull
    Par jab dans le forum Windows Forms
    Réponses: 8
    Dernier message: 04/04/2005, 12h39
  3. [oracle 9i][Workbench]Problème de performance
    Par nuke_y dans le forum Oracle
    Réponses: 6
    Dernier message: 03/02/2005, 18h38
  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, 16h41
  5. [ POSTGRESQL ] Problème de performance
    Par Djouls64 dans le forum PostgreSQL
    Réponses: 6
    Dernier message: 26/05/2003, 17h18

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