Discussion :

[cyril_M]

Bonjour,

J'aimerais avoir votre avis sur l'utilisation de PostgreSQL pour une base de donnée volumineuse.

La base :
Elle traite des mots dans dans nombreux document, il y aura donc environs un milliard d'entré à terme.
Assez peu d'utilisateur ( centaine, voir millier)
Assez peu de table, je pense qu'une table me servira à la jointure entre les autres pour alléger le traitement(est ce pertinent?)

Questions:
Le comparatif décris PostgreSQL comme efficace pour des bases de taille moyenne, est ce qu'à l'heure d'aujourd'hui il est viable pour les bases plus importante.
Dans la négative quelle serait la meilleurs solution(gratuite)

D'avance merci

[SQLpro]

un milliard d'entrée ne veut rien dire. Si vous faites de l'indexation textuelle vous aurez au plus 250 000 mots d'en moyenne 8 caractères soit une table de 500 Mo ce qui est ridicule...

Pour votre croisement doc / mot, en comptant 20 000 mots par doc et en comptant 100 000 document on est en effet à 2 milliards de références, soit 2 colonnes d'entiers dans la table de jointure, soit 25 go... C'est gros mais pas énorme....
Pour résoudre les temps d'accès un partitionnement de la table serait le bienvenu.. Sauf que la partitionnement dans PG est imbitable... A lire : http://blog.developpez.com/sqlpro/p1...paraison_postg

Ne rêvez pas, gratuit et performant... y'a pas.

Il existe cependant des éditions plus ou moins couteuses en fonction de vos besoins. par exemple SQL Server Web edition pourrait parfaitement convenir à votre situation...

A +

[cyril_M]

Merci de votre avis,
Je pensais mettre en place un index pour diminuer le temps d'accès est ce une bonne solution?

[al1_24]

C'est une question qui ne se pose pas !
Il n'y a pas d'accès performant à une table sans index.

[cyril_M]

C'est une question qui ne se pose pas !
Il n'y a pas d'accès performant à une table sans index.

Je me suis mal exprimé, ma question serais plus de savoir si la mise en place d'un index sur les champs recherché SUFFIT à accélérer la recherche.

[punkoff]

Bonjour,

Le SGBD prend plusieurs paramètre en compte afin de créer un plan d’exécution de votre requête, et selon le plan les indexs mis en place seront utilisés ou non.

Quoiqu'il en soit pour votre projet, vous pourrez vous tourner vers les recherche dites "full text" :

http://www.postgresql.org/docs/9.2/s...extsearch.html


Sinon :

Assez peu de table, je pense qu'une table me servira à la jointure entre les autres pour alléger le traitement(est ce pertinent?)

Ne pensez pas mais modélisez correctement.
Et testez avec de la charge si vous voullez commencer à sortir des chemin battu de la normalisation.

[cyril_M]

Ne pensez pas mais modélisez correctement.
Et testez avec de la charge si vous voullez commencer à sortir des chemin battu de la normalisation.

Je suis entrain de modéliser ma table et je commencerais donc à la tester sur différent SGBD juste après.
Ma grosse charge sera une table de plusieurs milliards de ligne *35 colonnes avec beaucoup de valeur null.

Je ferais un benchmark de différentes solutions et reviendrais fournir les résultat à titre d'exemple si vous le souhaitez.

EDIT :

Quoiqu'il en soit pour votre projet, vous pourrez vous tourner vers les recherche dites "full text" :

http://www.postgresql.org/docs/9.2/s...extsearch.html

Merci mais justement mes enregistrements sont les mots traités sémantiquement, je garde le liens du document mais uniquement à des fins historique

[FSiebert]

Je suis entrain de modéliser ma table et je commencerais donc à la tester sur différent SGBD juste après.
Ma grosse charge sera une table de plusieurs milliards de ligne *35 colonnes avec beaucoup de valeur null.

Êtes-vous sûr de votre modélisation ?
Pourquoi "beaucoup de valeur null" ? Cela pourrait indiquer un problème de modélisation.

[SQLpro]

...
Ma grosse charge sera une table de plusieurs milliards de ligne *35 colonnes avec beaucoup de valeur null...

C'est exactement ce qu'il ne faut pas faire !

A +

[cyril_M]

Cette table correspond à l'analyse d'un mot, imaginé le nombre de mot dans la littérature anglaise ou allemande (oui toute la littérature).

Chaque mot à énormément de paramètre (les terminaisons,préfixe,suffixe...)
Je pourrais éclater cette table en plusieurs tables relié en (1,1) mais est ce que le gains obtenus avec la limitation de colonne de la table principale ne serait pas moindre que le coût demandé par la jointure à chaques fois qu'il y a un suffixe par exemple

[punkoff]

pourquoi en 1,1 ?

un préfix / suffix sera commun à plusieurs mots

[cyril_M]

Non,
L'outil permet de corriger les analyses, ainsi un linguiste pourra dire "non le préfixe ici n'est pas "dé" mais "dés" (pour le verbe habiller mais c'est vraiment un exemple au hasard)
Ce qui est stocké est l'extraction automatique du préfixe par exemple, on est au niveau de l'analyse pas du mot découpé parfaitement.
Une solution à été trouvé pour réduire grandement les champs :
Au lieu d'avoir les colonnes "genre" et "nombre" et {toute les colonnes dont la valeur provient d'une liste fini} il y aura un colonne "générique" dans laquelle sera encodé l'indice de la valeur dans une table de correspondance donc j'aurais un INT au lieu de plusieurs VARCHAR.

Pour revenir sur le sujet, est ce que vous auriez des retours d'expérience sur d'autre solution gratuites?

Encore merci

[SQLpro]

Non,
L'outil permet de corriger les analyses, ainsi un linguiste pourra dire "non le préfixe ici n'est pas "dé" mais "dés" (pour le verbe habiller mais c'est vraiment un exemple au hasard)

Ca ne chan ge pas le problème. En cas d'erreur il suffira de déréférence la valeur fautive pour en prendre une autre ou la créer si elle n'existe pas.
N'oubliez jamais qu'une base de données c'est 0 (ZÉRO) redondance si vous voulez de la performance...

Ce qui est stocké est l'extraction automatique du préfixe par exemple, on est au niveau de l'analyse pas du mot découpé parfaitement.
Une solution à été trouvé pour réduire grandement les champs :
Au lieu d'avoir les colonnes "genre" et "nombre" et {toute les colonnes dont la valeur provient d'une liste fini} il y aura un colonne "générique" dans laquelle sera encodé l'indice de la valeur dans une table de correspondance donc j'aurais un INT au lieu de plusieurs VARCHAR.

Vous voyez que vous commencez à y arriver.

Pour revenir sur le sujet, est ce que vous auriez des retours d'expérience sur d'autre solution gratuites?

Encore merci

Vous pouvez vous inspirer de LEXIQUE du CNRS pour les mots français (mais la base est incomplète).

A +