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 :

Performances champ de type tableau


Sujet :

PostgreSQL

  1. #1
    Membre à l'essai
    Profil pro
    Étudiant
    Inscrit en
    Décembre 2009
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2009
    Messages : 28
    Points : 21
    Points
    21
    Par défaut Performances champ de type tableau
    Bonjour,

    après avoir parcouru plusieurs forums et des docs, et n'ayant pas trouvé de réponse je viens poser ma question ici en espérant que quelqu'un entre vous arrivera à me renseigner.

    Je voudrai savoir comment sont stockés les champs de type tableau dans les SGBD (PostgreSQL ou autres) et est-ce que la recherche sur ces champs est efficaces ?

    La table qui comporte parmi tous ses champs le champs de type tableau d'entier, possèdera plusieurs centaines de milliers d'occurrences, chaque occurrence du champs tableau ayant au mieux plusieurs centaines d'entrées (pouvant aller jusqu'à plusieurs centaines de milliers).
    Pensez-vous ensageable une recherche du type "selectionner toutes les occurrences qui comporte l'entier xx dans leur tableau" ?
    (je précise que je ne connais pas à l'avance la taille des tableaux, ils seront donc dynamique, champs de type int[]).


    J'espère que vous pourrez me renseigner

  2. #2
    Membre à l'essai
    Profil pro
    Étudiant
    Inscrit en
    Décembre 2009
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2009
    Messages : 28
    Points : 21
    Points
    21
    Par défaut
    Ne me dites pas que personne ne sais me répondre... :/

  3. #3
    Membre à l'essai
    Profil pro
    Étudiant
    Inscrit en
    Décembre 2009
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2009
    Messages : 28
    Points : 21
    Points
    21
    Par défaut
    Petite erreur lors de la frappe, le champs tableau sera d'une taille approximativement comprise entre 1 et une centaine d'entrée...

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    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 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    A de rares exceptions près, les types objet comme les tableaux ne sont pas indexable. Dès lors les performances sont médiocre à catastrophique.

    Il n'y a d'ailleurs aucun intérêt à utiliser un type tableau dans un SGBDR. C'est pourquoi la plupart des "grands" SGBDR (Oracle, SQL Server..) ne l'implémente même pas. En effet, un table, c'est un tableau beaucoup plus perfectionné et indexable !!!!

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

  5. #5
    Membre à l'essai
    Profil pro
    Étudiant
    Inscrit en
    Décembre 2009
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2009
    Messages : 28
    Points : 21
    Points
    21
    Par défaut
    Salut et merci pour ta réponse !

    Etant donné que je ne connais pas à l'avance la taille des tableaux, et que la table qui devait contenir le champ tableau comptera au moins 1 million d'entrée, je ne vais pas (pouvoir) créer une table par entrée pour remplacer ce champs...

  6. #6
    Membre émérite
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    1 874
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Octobre 2008
    Messages : 1 874
    Points : 2 890
    Points
    2 890
    Par défaut
    Pensez-vous ensageable une recherche du type "selectionner toutes les occurrences qui comporte l'entier xx dans leur tableau" ?
    Regarde le module intarray, qui fait précisément ça, et avec une indexation possible.

  7. #7
    Membre émérite
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    1 874
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Octobre 2008
    Messages : 1 874
    Points : 2 890
    Points
    2 890
    Par défaut
    C'est pourquoi la plupart des "grands" SGBDR (Oracle, SQL Server..) ne l'implémente même pas
    C'est faux en ce qui concerne Oracle. Voir http://www.orafaq.com/wiki/VARRAY

  8. #8
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    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 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Une colonne (et pas champ ! ) de type tableau devrait être interdite car contraire au principe élémentaire des bases de données : 1 colonne = 1 donnée-type.

    Que représentent ces tableaux d'entiers ?
    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 !

  9. #9
    Membre à l'essai
    Profil pro
    Étudiant
    Inscrit en
    Décembre 2009
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2009
    Messages : 28
    Points : 21
    Points
    21
    Par défaut
    il s'agira d'un base d'indexation, composée d'une table "Document", d'une table "Terme", chaque document en relation avec un terme via une table "Relation".

    La table "Relation" comportera trois champs :
    --> id_terme
    --> id_document
    --> positions (le fameux champs de type tableau à éliminer)

    Le champs position permet donc de connaitre la position (i-ième mot dans le document). La taille du champs position sera égale au nombre d'apparition du terme dans le document.
    A partir d'un document et de ses relations, il est donc possible de recomposer le corps de texte grâces aux positions.

    Ne connaissant pas à l'avance la taille du champs positions, je ne vois pas comment le remplacer par l'ajout d'une table ou d'autres champs de type standards...

    La seule solution (non envisageable) à mes yeux, serait de créer une nouvelle table pour chaque relation... Sachant que la table relation comportera plusieurs millions d’occurrences : pas possible...

    Il serait également possible de créer une table position, mais elle comportera alors plusieurs milliards de lignes...

  10. #10
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    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 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Si tu ajoutes la position dans la clé primaire de la table "Relation", tu auras une ligne par position d'un terme dans un document. Chaque ligne de la table étant composée de 3 entiers, aura une taille de 12 octets.

    La table qui comporte parmi tous ses champs le champs de type tableau d'entier, possèdera plusieurs centaines de milliers d'occurrences, chaque occurrence du champs tableau ayant au mieux plusieurs centaines d'entrées (pouvant aller jusqu'à plusieurs centaines de milliers).
    Les documents sont-ils si gros pour qu'un terme puisse y apparaître plusieurs centaines de milliers de fois ? Même dans un livre de 500 pages, je pense qu'un article courant (le, la, un, une) ne doit pas apparaître plus de quelques milliers de fois.
    Le but de ton référencement de termes est-il d'aller jusqu'à référencer les petits mots de ce genre ?

    Regarde l'article de SQLPro sur l'indexation textuelle.
    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 !

  11. #11
    Membre à l'essai
    Profil pro
    Étudiant
    Inscrit en
    Décembre 2009
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2009
    Messages : 28
    Points : 21
    Points
    21
    Par défaut
    Voici le schema correct avec une table qui gère les positions :

    Table relation (relation entre un terme et un document) :
    --> Document
    --> Terme
    --> Poids (il s'agit du poids du terme dans la page)

    Table positions :
    --> Document
    --> Terme
    --> Position

    Pour la volumétrie, ça peut beaucoup varier en fonction du domaine d'indexation. Le nombre de termes sera au maximum de 500 000, le nombre de document pouvant aller jusqu'à plusieurs millions

    Concernant les document, il s'agit de pages web. Seuls les 100 premier Ko sont lus.
    Le nombre de lignes dans la table relation sera donc égal à la somme de termes différents présents dans chaque page.
    Le nombre de lignes dans la table positions sera égal au nombre de mots présents dans tout le corpus !
    (si "bonjour" apparait deux fois, la relation entre ce terme et le doc sera présent qu'une fois dans la table relation, les deux positions seront stockées dans la table positions).

    Pour pouvoir recomposer entièrement la page, nous envisagions de stocker non seulement les mots vides (de, le, la etc..) et la ponctuation.

  12. #12
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    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 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Citation Envoyé par Thibaut Marmin Voir le message
    Pour pouvoir recomposer entièrement la page,
    Pourquoi vouloir faire ce travail ? N'est-il pas plus simple d'enregistrer la page ou même le morceau de texte, et de l'indexer syntaxiquement et éventuellement sémantiquement ?

    Et quid des caractères spéciaux (spéciaux) ?
    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 !

  13. #13
    Membre à l'essai
    Profil pro
    Étudiant
    Inscrit en
    Décembre 2009
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2009
    Messages : 28
    Points : 21
    Points
    21
    Par défaut
    Pour les caractères spéciaux, ils seront traduits en pré-traitement de l'indexation.

    Concernant la recomposition du document, le but serait de connaitre la proximité des mots.

    Exemple pour une requête "bonjour monsieur",
    les documents qui comportent les mots "bonjour" et "monsieur" à proximité verront leur pertinence augmenter.

  14. #14
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    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 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Donc il ne s'agit pas de recomposer entièrement une page à partir des termes mais de chercher les occurrences d'ensembles de mots dans la BDD et d'en calculer le poids en fonction de la proximité des mots recherchés à partir de la position des mots.

    Et il me semble que les "petits mots" et autres signes de ponctuation n'ont pas d'intérêt dans cette recherche.

    Tu as lu l'article de SQLPro que j'ai mentionné précédemment ?
    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
    Membre à l'essai
    Profil pro
    Étudiant
    Inscrit en
    Décembre 2009
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2009
    Messages : 28
    Points : 21
    Points
    21
    Par défaut
    Techniquement il faudra qu'il soit possible de recomposer la page pour deux raisons :
    • la recherche des mots composés et chaines de caractères (avec les "")
    • dans l'affichage des résultats, il serait bien d'éfficher le passage dans lequel se situe le ou les mots recherchés.

  16. #16
    Membre à l'essai
    Profil pro
    Étudiant
    Inscrit en
    Décembre 2009
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2009
    Messages : 28
    Points : 21
    Points
    21
    Par défaut
    (oui j'ai lu le doc, merci pour le lien )

  17. #17
    Membre émérite
    Profil pro
    Inscrit en
    Octobre 2008
    Messages
    1 874
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Octobre 2008
    Messages : 1 874
    Points : 2 890
    Points
    2 890
    Par défaut
    Citation Envoyé par Thibaut Marmin Voir le message
    Table positions :
    --> Document
    --> Terme
    --> Position

    Pour la volumétrie, ça peut beaucoup varier en fonction du domaine d'indexation. Le nombre de termes sera au maximum de 500 000, le nombre de document pouvant aller jusqu'à plusieurs millions
    Le souci est que cette structure n'est pas adaptée à ce volume, si l'objectif est d'avoir des temps d'exécution de requêtes de quelques secondes.

    En supposant par exemple qu'il y ait en moyenne dans les 2000 entrées par document dans cette table, et 2 millions de documents, ça ferait une table de 4 milliards de lignes qui pèserait dans les 160Go (il faut compter 40 octets par ligne). Il faut ajouter à ça les index, compter 18 octets par ligne pour une colonne simple de type int. Il en faut a minima un sur terme, mais aussi un sur document si tu veux reconstituer le doc, soit 2 fois 72Go. Par ailleurs les termes à forte occurrence seront sur-représentés, d'où un index déséquilibré.

    Une fois ces données en table sur un serveur du commerce, je dirais qu'en étant optimiste certaines recherches pourraient peut-être passer en quelques secondes, et encore ça reste à voir, mais que d'autres nécessiteraient plusieurs minutes, notamment dès qu'elles incluent les termes sur-représentés ou n'importe quoi d'autre qui implique trop de données à joindre ou filtrer.

Discussions similaires

  1. Réponses: 22
    Dernier message: 22/12/2006, 19h01
  2. [MySQL] quel type de champ pour un tableau serializé
    Par lodan dans le forum PHP & Base de données
    Réponses: 2
    Dernier message: 17/11/2006, 15h37
  3. Pb de formatage de champs de type float
    Par FrankyNormand dans le forum XMLRAD
    Réponses: 9
    Dernier message: 05/05/2005, 13h37
  4. Valeur par defaut 'True' dans un champ de type bit
    Par Mouse dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 24/03/2003, 16h26
  5. Fonction de type tableau
    Par Charles f dans le forum Langage
    Réponses: 5
    Dernier message: 04/08/2002, 15h04

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