Optimisation de requetes SQL...y'a un prog qui fait ca tout seul ??

Optimisation de requetes SQL...y'a un prog qui fait ca tout seul ?? - Programmation

Marsh Posté le 16-11-2001 à 15:59:50    

J'ai une GROSSE table (6oo.ooo enregristrments) dans laquelle je doit comparez tous les enregistrements les uns aux autres.
 
Bref, ca fait beaucoup de taf pour le serveur ... :(
 
Un ingénieur info de la boite m'a dit que sous oracle, il existait des programmes qui analysait les requetes, et qui proposait des améliorations.
 
Or, là, 1-2% d'amélioration, ca va se compter en heures...
Existe il la même chose pour MySQL (ou pour perl, j'écrit mon truc en perl), ou même un site qui serait spécialié la dedans :??:
 
J'ai fait une recherche sur le forum et dans les site classique de sql (et y'en a), mais j'ai rien trouvé de transcandant la dessus ... :cry:
 
 
 
 
:jap:

Reply

Marsh Posté le 16-11-2001 à 15:59:50   

Reply

Marsh Posté le 16-11-2001 à 16:13:59    

ca veut dire quoi comparer les uns aux autres?

 

[edtdd]--Message édité par jupiler--[/edtdd]


---------------
Je ne suis ni pour, ni contre, bien au contraire  
Reply

Marsh Posté le 16-11-2001 à 16:32:20    

Y'a 6oo.ooo concepts dans un dictionnaire médicale (UMLS).
 
Je prend le concept C0001 et je regarde un de ses attribut (ici, son type semantique T022 par exemple).
 
Apres, je prend le concept C002 et je regarde son Typse semantique. Je compare avec le T022 de C00001.
Je passe au trois, et je recommence..... jusqu'au 6oo.oooème.
 
 
Une fois fini avec le 1, je passe a C0002, que je compare a C0003... et ainsi de suite jusqu'a C6oo.ooo
 
 
Et on continue gaiement jusqu'au dernier, le C6oo.ooo qui n'a plus personne à comparer ...
 
 
 
Bref, du gros boulôt pour le serveur en perspective.
Et le tout a ranger dans une table, evidament, sinon, c'est pas drôle.
D'ailleurs, y'a une limite à MySQL, si ce n'est la place sur le dur ??

Reply

Marsh Posté le 16-11-2001 à 16:34:07    

c'est bien beau mais la comparaison doit retourner quoi?
 
au final tu dois stocker quoi?


---------------
Je ne suis ni pour, ni contre, bien au contraire  
Reply

Marsh Posté le 16-11-2001 à 16:44:23    

La compraison fournit une relation possible entre les types sémantiques des deux concepts.
 
Chaque concepts a un ou plusieurs types semantiques. Les types semantiques sont parfois reliés entre eux.
 
Donc, ej prend un concept, son type semantique, et je regarde si il y a une relation entre son type semantique et celui du concept suivant.
Si il y a une relation, je met dans une table :  
Le premier concept, son TS (Type semantique) , le deuxieme concept, son TS et enfin, la relation liant les deux TS.
 
Puis, toujours avec le premier concept, je compare son TS avec le troisième concept.... et je continue.
 
 
En fait, j'ai deja ecrit un truc en perl qui fait le boulôt.
Sauf que ca prend des heures, ne serait ce que pour le premier concept. donc, je cherche des sites que je pourrait potasser pour améliorer ou me donner des idées sur la mainère d'améliorer les requetes :)

Reply

Marsh Posté le 16-11-2001 à 16:57:56    

AAAAAAAARRrgghhhh, y'a pas de view sur MySQL .... avant la version 4.1 :cry:
 
bon, je sens que je vais prendre une autre base :cry:

Reply

Marsh Posté le 16-11-2001 à 17:01:15    

t'aurais pas plutôt intêret à modifier la structure de tes données ?


---------------
La musique c'est comme la bouffe, tu te souviens du restaurant dans lequel t'as bien mangé 20 ans plus tôt, mais pas du sandwich d'il y a 5 minutes :o - Plugin pour winamp ©Harkonnen : http://harko.free.fr/soft
Reply

Marsh Posté le 16-11-2001 à 17:05:38    

C'est à dire ??
aranger mes bases différament ??
 
de toutes facons, je sais que la base resultante sera énorme, ca je peux pas y couper.
Elle fera plusieurs millions d'enregitrements, ca, c'est sur.
J'ai fait des 'tits test, j'en suis a 61 Millions d'enregistrements pour 1 giga2 de données.
 
Y'aura peut être dix fois ca.
Donc, ca n'est pas trop le probleme, tant que Mysql suit, tout baigne. c'est plus au niveau du temps que je voudrait améliorer le truc.
La requete, je ne la lancerai qu'une fois, mais bon, si ca doit lui prendre un mois, c'est pas top non plus ;)

 

[edtdd]--Message édité par TetardKing--[/edtdd]

Reply

Marsh Posté le 16-11-2001 à 17:10:49    

600 000 entrées dans la table de départ, ca fait potentiellemnt 180 milliards d'enregistrement. pas sur que MySql puisse suivre
 
( 1 + 2 + 3 ...... + 599999 + 600000)


---------------
Je ne suis ni pour, ni contre, bien au contraire  
Reply

Marsh Posté le 16-11-2001 à 17:15:57    

oui, je sais, j'ai fait le calcul :)
 
Mais a vu de nez, y'en aura pas plus de 7oo / 8oo millions :ouch: :D
 
La base est énorme, normal que les requetes le soient.. mais j'ai pas le choix ...
 
Que ca marche ou pas, je m'en fout (enfin, je prefererais que ca marche), mais je bosse pour une fac, mais c'est le temps que ca va mettre pour tout calculer qui me desepère.
 
Sinon, je le fait tourner pendant les fêtes de noël :D
 
Donc, personne n'a ca sous le bras, un 'tit programme ou site qui permettrait d'ameliorer mes requetes ??

Reply

Marsh Posté le 16-11-2001 à 17:15:57   

Reply

Marsh Posté le 16-11-2001 à 17:17:06    

salut
si ce genre de requêtes est exceptionnel, tu peux essayer de bricoler, mais apparemment c'est pas possible...
méta-réponse : ton pb est un pb de conception :D Ta base est pas conçue pour traiter de telles requêtes... ...et tu exprimes ta req de manière procédurale & non ensembliste. Une seule solution : restructurer... bon courage !
ta table de concepts doit pouvoir être modélisée + finement.


---------------
di. / www.diredaredare.org - Ailes de la ville
Reply

Marsh Posté le 16-11-2001 à 17:18:47    

TetardKing a écrit a écrit :

oui, je sais, j'ai fait le calcul :)
 
Mais a vu de nez, y'en aura pas plus de 7oo / 8oo millions :ouch: :D
 
La base est énorme, normal que les requetes le soient.. mais j'ai pas le choix ...
 
Que ca marche ou pas, je m'en fout (enfin, je prefererais que ca marche), mais je bosse pour une fac, mais c'est le temps que ca va mettre pour tout calculer qui me desepère.
 
Sinon, je le fait tourner pendant les fêtes de noël :D
 
Donc, personne n'a ca sous le bras, un 'tit programme ou site qui permettrait d'ameliorer mes requetes ??  




 
ce ne sont pas les requetes qui seront énormes, mais la taille des données à mettre en mémoire ou en swap certainement.


---------------
Je ne suis ni pour, ni contre, bien au contraire  
Reply

Marsh Posté le 16-11-2001 à 17:21:26    

Les bases sont ainsi faîtes :  
 
TABCUI :
 
cui                       TS   Def_TS
C0000005   T116   Amino Acid, Peptide, or Protein  
C0000005   T121   Pharmacologic Substance  
C0000005   T130   Indicator, Reagent, or Diagnostic Aid  
C0000039   T119   Lipid  
C0000039   T121   Pharmacologic Substance  
C0000052   T116   Amino Acid, Peptide, or Protein  
C0000052   T126   Enzyme  
 
Et la table de relation entre les TS :
TS   REL_entre TS   TS
 
T001   T186   T072  
T001   T186   T071  
T001   T142   T001  
T001   T142   T002  
T001   T142   T003  
T001   T142   T004  
T001   T142   T005  
T001   T142   T006  
 
 
Y'a que ca d'interessant.
Pas trop le choix de faire autrement, si ???

 

[edtdd]--Message édité par TetardKing--[/edtdd]

Reply

Marsh Posté le 16-11-2001 à 17:26:26    

TetardKing a écrit a écrit :

Les bases sont ainsi faîtes :  
 
TABCUI :
 
cui                       TS   Def_TS
C0000005   T116   Amino Acid, Peptide, or Protein  
C0000005   T121   Pharmacologic Substance  
C0000005   T130   Indicator, Reagent, or Diagnostic Aid  
C0000039   T119   Lipid  
C0000039   T121   Pharmacologic Substance  
C0000052   T116   Amino Acid, Peptide, or Protein  
C0000052   T126   Enzyme  
 
Et la table de relation entre les TS :
TS   REL_entre TS   TS
 
T001   T186   T072  
T001   T186   T071  
T001   T142   T001  
T001   T142   T002  
T001   T142   T003  
T001   T142   T004  
T001   T142   T005  
T001   T142   T006  
 
 
Y'a que ca d'interessant.
Pas trop le choix de faire autrement, si ???  
 
 




 
Tu as bien des index dans toutes les colonnes sur lesquelles tu fait des restrictions ???
ça joue pas mal

Reply

Marsh Posté le 16-11-2001 à 17:27:52    

Tes tables sont correctement indexées ?
 
Tiens en passant c'est une base utilisée pour faire de la modélisation moléculaire ? Parce que ce dont tu parles ça me rappelle de vieux souvenirs de pharma, où un prof nous avait parlé des différents softs utilisés par l'industrie pharmaceutique pour modéliser (et tester) à moindre frais de nouvelles molécules.

Reply

Marsh Posté le 16-11-2001 à 17:28:29    

krolours > Arrgh, grilled ! :D

Reply

Marsh Posté le 16-11-2001 à 17:31:57    

irulan> je suis en pharma aussi, mais dans un labo de medecine. La base UMLS est un GROS dictionnaire qui comporte des concepts. Ca sert ici pour faire un moteur d'indexation de documents médicaux, en indexant non pas sur les mots mais sur lse concepts.
 
ainsi, hepatho, hépatique, foie, sont indéxés de la meme manière, et c'est pratique :D
 
Sinon, pour les indexes, ou les metteriez vous exactement ?? si j'en met partout, je vais gonfler encore plus mes bases... m'enfin, ca en gonflera que les tables d'origines pas ma table finale... vous me conseilez d'en mettre partout ??

Reply

Marsh Posté le 16-11-2001 à 17:32:45    

Non uniquement sur les colonnes utilisés par les jointures.

Reply

Marsh Posté le 16-11-2001 à 17:34:52    

TetardKing a écrit a écrit :

 
 
Sinon, pour les indexes, ou les metteriez vous exactement ?? si j'en met partout, je vais gonfler encore plus mes bases... m'enfin, ca en gonflera que les tables d'origines pas ma table finale... vous me conseilez d'en mettre partout ??  




 
ca va surtout rallonger le temps de mise à jour des tables.
pense à mettre à jour les stats quand tu as rajouté les indexes


---------------
Je ne suis ni pour, ni contre, bien au contraire  
Reply

Marsh Posté le 16-11-2001 à 17:38:20    

En fait le principe d'un index est le suivant : imagines que tu dois retrouver le N° de Téléphone de quelqu'un dans un carnet, en cherchant son nom.
Si tes numéros sont inscrits l'un à la suite de l'autre, tu mettras beaucoup de temps à retrouver le bon nom (des fois il sera au début, des fois à la fin, enfin on parle d'un point de vue statistique).
En revanche si tu a s un répertoire alphabétique, tu mettras beaucoup moins de temps à retrouver le nom que tu cherches.
 
En gros sans index tu demandes à ton moteur de BDD à chaque ligne d'aller lire quasiment la moitié de la table de 600000 enregistrements pour retrouver la ligne en relation. Donc pas étonnant que ce soit long !

 

[edtdd]--Message édité par irulan--[/edtdd]

Reply

Marsh Posté le 16-11-2001 à 17:38:45    

mon programme perl prendle premier CUI (ici C0005) et son premier type semantique T116.
 
puis, le deuxième C00039 et son premier type semantique (T119).
 
Il regarde si il y a une relation entre T116 et T119. si il y en a une, il met le tout dans une table.
Si il n'y en a pas, il passe au deuxième TS  de C00039 = T121, et regarde a nouveau si il y a une relation entre TS1 (T116) et TS2 (T121).
Puis, pareil avec C000052...
 
Qd il a fini avec le premier TS, il passe à la deuxième ligne C0005 T121, et il continue ....
 
 
ARRRRRRGGGhhh, le pauvre P4, il va souffrir...
 
Rappel :  
 
TABCUI :
 
cui                       TS   Def_TS
C0000005   T116   Amino Acid, Peptide, or Protein  
C0000005   T121   Pharmacologic Substance  
C0000005   T130   Indicator, Reagent, or Diagnostic Aid  
C0000039   T119   Lipid  
C0000039   T121   Pharmacologic Substance  
C0000052   T116   Amino Acid, Peptide, or Protein  
C0000052   T126   Enzyme  
 
Et la table de relation entre les TS :
TS   REL_entre TS   TS
 
T001   T186   T072  
T001   T186   T071  
T001   T142   T001  
T001   T142   T002

 

[edtdd]--Message édité par TetardKing--[/edtdd]

Reply

Marsh Posté le 16-11-2001 à 17:44:00    

Pourquoi tu n'utilises pas le SQL pour avoir directement les bonnes lignes ? :??: En fait tu n'utilises pas du tout la puissance du moteur de la BDD !!
Tu peux faire un truc du genre :
 
Insert into Table_bidule (col1,col2,col3)
select col1,col2,col3 from Table_CUI, table_relation
where il existe une relation;
 
Et là tu obtiens directement toutes les lignes qui correspondent à tes besoins !!
N'utilises surtout pas un langage procédural, tu m'étonnes que tu vas mettre à genoux ta bécane :D

Reply

Marsh Posté le 16-11-2001 à 17:47:38    

Sauf que la la clause where, elle fait trois pages.... et que je suis un total newbee en la matière... je connaissais pas SQL y'a deux jours ;)
 
Et perl encore moins.
 
Par contre, si je ne m'abuse, les deux (perl et sql) tournent en C derrière, donc, la difference doit pas être si énorme, nan :??:

Reply

Marsh Posté le 16-11-2001 à 17:51:21    

Oh que si que c'est énorme la différence !!
Dans un cas tu utilises un script qui lit les lignes une par une, alors que dans l'autre tu utilises un système dédié au traitement de masse des données, et qui tourne sur un serveur en plus !

Reply

Marsh Posté le 16-11-2001 à 17:52:32    

Table de relation entre les TS :
TS1   REL_entre TS   TS2
 
T001   T186   T072  
T001   T186   T071  
T001   T142   T001  
T001   T142   T002  
 
Tiens j'ai un peu réfléchi à ton truc, tu devrais creuser dans ce style  de requête :
 
Insert into TABLE_CIBLE
SELECT T1.CUI,T1.DEF_TS, TR.REL_ENTRE_TS, T2.CUI,T2.DEF_TS
FROM TAB_CUI T1, TABCUI T2, TABLE_RELATION TR
WHERE T1.TS = TR.TS1
AND T2.TS = TR.TS2;
 
En plus pour tester tu peux rajouter :
AND T1.CUI = 'C0000005'
 
ça te permettras de tester ce que renvoie ce genre de requête pour un CUI donné, avant de lancer sur 600000 lignes...
 
Dans tous les cas il sera vraiment important de mettre un index sur la colonne TS de CUI et la colonne TS1 de la table TABLE_RELATION ...

 

[edtdd]--Message édité par irulan--[/edtdd]

Reply

Marsh Posté le 16-11-2001 à 18:01:36    

irulan a écrit a écrit :

Insert into TABLE_CIBLE
SELECT T1.CUI,T1.DEF_TS, TR.REL_ENTRE_TS, T2.CUI,T2.DEF_TS
FROM TAB_CUI T1, TABCUI T2, TABLE_RELATION TR
WHERE T1.TS = TR.TS1
AND T2.TS = TR.TS2;  




 
Ok pour le debut, tu crée une deuxième table re-contenant les CUI et leur TS.
On a donc TABCUI1 et TABCUI2 ainsi que TAB_REL
 
Je reflechi au tout :)
Deux secondes :D

Reply

Marsh Posté le 16-11-2001 à 18:02:23    

Et arrete d'éditer ton message :lol:
:jap:

Reply

Marsh Posté le 16-11-2001 à 18:03:30    

Non tu ne recrées PAS :non: une 2ème table, tu utilises la même mais avec 2 alias différents.
 
Bienvenue dans le monde merveilleux des bases de données :D :jap:

Reply

Marsh Posté le 16-11-2001 à 18:04:14    

TetardKing a écrit a écrit :

Et arrete d'éditer ton message :lol:
:jap:  




 
Bon Ok, c'était pour voir si tu suivais ;)

Reply

Marsh Posté le 16-11-2001 à 18:04:56    

Et TABCUI2, il va la créer tout seul comme un grand :??: :)
trop fort sql ...

Reply

Marsh Posté le 16-11-2001 à 18:06:42    

FROM TABCUI T1, TABCUI T2, TABLE_RELATION TR
 
C'est les T1 et T2 de ton from .... ok ok, j'ai compris, il fait une table T1 et T2  "virtuelle" a partir de TABCUI...

Reply

Marsh Posté le 16-11-2001 à 18:07:31    

Relis attentivement  :p  
 
... TAB_CUI T1, TABCUI T2,...
 
Où vois-tu TABCUI2 ??
T1 et T2 sont les alias de TABCUI

 

[edtdd]--Message édité par irulan--[/edtdd]

Reply

Marsh Posté le 16-11-2001 à 18:08:38    

Ca vient, ça vient :D Fais gaffe tu vas finir par aimer ça :lol:

Reply

Marsh Posté le 16-11-2001 à 18:09:09    

TAB_CUI T1, TABCUI T2,...
 
oui uoi, j'ai compris depuis.
Mais pourquoi tu met une fois TAB_CUI et une autre fois TABCUI :??:

Reply

Marsh Posté le 16-11-2001 à 18:09:45    

irulan a écrit a écrit :

Ca vient, ça vient :D Fais gaffe tu vas finir par aimer ça :lol:  




J'aime déjà ca, pharma, c'est une erreure d'orientation :D

Reply

Marsh Posté le 16-11-2001 à 18:10:27    

C'est pour l'utiliser à la fois sur TS1 et sur TS2 de la table TABLE_RELATION

Reply

Marsh Posté le 16-11-2001 à 18:11:06    

TetardKing a écrit a écrit :

 
J'aime déjà ca, pharma, c'est une erreure d'orientation :D  




 
Oui, ça arrive j'ai fait la même :D

Reply

Marsh Posté le 16-11-2001 à 18:16:04    

Bon, je vais essayer de faire bouiner ton truc, on va bien voir ce qu'il me dit ;)
Je te fait signe pour te donner l'avancement
 
Merci beaucoup en tout cas :jap::jap:

Reply

Marsh Posté le 16-11-2001 à 18:17:22    

Ok, J'espère que ça t'aideras...
 
Sinon là je pars du taf, mais bon n'hésite pas à reposter voire à me mailer (cf profil) si tu as besoin.
 
 :hello:

Reply

Marsh Posté le 16-11-2001 à 18:18:10    

:hello: et bon WE :)

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed