Performances champ de type tableau

[Thibaut Marmin]

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

[Thibaut Marmin]

Ne me dites pas que personne ne sais me répondre... :/

[Thibaut Marmin]

Petite erreur lors de la frappe, le champs tableau sera d'une taille approximativement comprise entre 1 et une centaine d'entrée...

[SQLpro]

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 +

[Thibaut Marmin]

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...

[estofilo]

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.

[estofilo]

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

[CinePhil]

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 ?

[Thibaut Marmin]

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...

[CinePhil]

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.

[Thibaut Marmin]

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.

[CinePhil]

Envoyé par Thibaut Marmin

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) ?

[Thibaut Marmin]

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.

[CinePhil]

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 ?

[Thibaut Marmin]

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.

[Thibaut Marmin]

(oui j'ai lu le doc, merci pour le lien )

[estofilo]

Envoyé par Thibaut Marmin

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.