Bon, je suis dans la merde...
 
Je suis en train de faire un site web dont la base de données contient des produits dont les descriptions sont traduites en 5 langues, ainsi qu'un certain nombre d'autre critères (dépôts dépendants du profil client, etc.)
 
Alors voilà.
Je dois faire une recherche par mots clés.
Ces mots clés doivent chercher dans tout ce qui contient du texte au niveau des traductions, de la marque, etc.
 
Du coup j'ai des tas de jointures plus ou moins complexes, qui portent sur un total de 1 500 000 lignes environs (dans les 300 000 produits traduits en 5 langues)
 
Faire des LIKE sur chaque champs au sein d'une énorme condition OR, autant de fois que j'ai de mots clés, c'est pas viable.
 
J'ai donc tenté de concaténer tous les champs "texte" et faire un unique LIKE par mot clé dessus.
Les perfs sont encore pire, car à cause de la concaténation, les indexes ne sont plus utilisés.
 
Je me suis donc résolu à me créer une table rafraîchie tous les jours contenant les données "pré-formattés".
Voici la structure :
 
CODSOC / Code société
CODPRO / Code produit
ECAT   / Code alternatif
REFPRO / Référence fournisseur
CODLAN / Code langue
NOMPRO / Nom du produit (localisé)
TXTPRO / Description du produit (localisé)
KEYWORD/ Nom + Description + Marque + codes + ...
 
KEYWORD est un CLOB (comme un LONG, mais formatté suivant le charset utilisé pour les types caractères).
 
Le LIKE ne fonctionne pas sur ce type de champs.
Par contre, je peux faire un INSTR() qui me renvoie une valeur > 0 si la chaîne est trouvée.
 
Banco !
 
Ben non.
 
Perfs toujours aussi pourrie, alors que cette fois je n'ai plus de jointures.
Le INSTR est donc encore plus lent que le LIKE.
 
Comment faire pour pallier à mon problème ?
 
Je me suis renseigné auprès des DBA, il nous est impossible de passer par un INDEX de type TEXT, car il faut installer l'applicatif Oracle Text, qui est bien trop cher (et surtout on n'a plus le temps de l'implémenter)
 
Personne n'a une idée ?
Pour ceux qui font des forums, vous avez bien un moteur de recherche ? Comment vous faites ? (ouais, je sais, c'est pas Oracle que vous utilisez mais bon )

En gros :
 
select search.codpro, search.refpro, search.nompro, search.txtpro  
from  
search  
where search.codsoc = 0  
and search.codlan = 'ENG'  
and not exists (select null from exclusion where exclusion.codsoc = search.codsoc and exclusion.codpro = search.codpro and exclusion.codpay = 'FR')  
and instr(search.keyword, upper('upp')) > 0  
and instr(search.keyword, upper('hd')) > 0  
order by nompro
 
Ca met 2 minutes et 41 secondes pour retourner :
 
1A00473 UPP-110HD PAPER,UPP110HD,SONY,110MMX20M A6,220SHEETS BOX OF5ROLLS,GLOSSY,FOR UPP811 UPP850 UPP860 UPP890ü          
1A04153 UPP-210HD PAPER,UPP210HD,SONY,210MMX25M, BOX OF 5 ROLLS 84SHEETS,GLOSSY,FOR UP960 UP980          
1A00065 UPP-216HD PAPER,UPP216HD,SONY,216MMX25M, BOX OF 5 ROLLS 30 SHEETS,GLOSSY,FOR UP910/930          
2S071080614 71080614 PRINTERPAPIER SONY UPP 110-HD Printerpapier Sony UPP 110-HD            
2S010650121 10 650 121 SONY PRINTER PAPIER UPP 110 HD Sony Printer Papier UPP 110 HD11cm x 20m          
2S01A00473 1A00473 SONY UPP-110HD DRUCKERPAPIER Sony UPP-110HD DruckerpapierPCK = 5 Rollen   110mmx20m          
2S01A04153 1A04153 SONY UPP-210 HD DRUCKERPAPIER Sony UPP-210 HD DruckerpapierPCK = 5 Rollen   210mmx25m          
2S01A00065 1A00065 SONY UPP-216HD DRUCKERPAPIER Sony UPP-216HD DruckerpapierPCK = 5 Rollen   216mmx25m          
2S0UPP216HD UPP 216 HD SONY VIDEOPRINTER PAPIER Sony Videoprinter Papier216mm x 25m (VE = 5 Stck)          
 
C'est vraiment pas gérable
 
Surtout que le site web est configuré pour planter si une page met plus de 15 secondes à charger

PS: Si je vire les "Instr()", la requête me retourne la liste des produits en anglais qui sont vandables en France en 72 ms (pour 280 000 lignes ça va...)

Personne n'a une idée ?
 
Je viens de m'appercevoir qu'un LIKE marche aussi sur le type CLOB.
Du coup c'est mieu, car ça va plus vite.
 
Mais ça met toujours plus d'une minute, et c'est beaucoup trop lent
 
Je ne peux évidement pas indexer un champ de type CLOB, et vu qu'il contient régulièrement plus de 10 000 caractères, ça marche pas.
 
Comment faire ? J'ai vraiment besoin d'un coup de main

Grrrrr... Sacrés DBA
 
Ouf, sauvé
 
J'ai contact le chef de celui qui voulait pas, et il n'a même pas tiqué, il a accepté directement d'installer les options Oracle Text
 

 
Bon, une journée de perdue (enfin pas complètement, j'ai fait d'autres trucs quand même )

Bon, ben pour demain, j'espère que qq1 d'entre vous sait se servir de l'option Text d'Oracle, parceque j'y connais rien

C'est hallucinant...
 
Avec tous les gens qui bossent sur des forums, vous allez me faire gober qu'une de vous ne s'est jamais posé la question d'un moteur de recherche sur un grand volume de données ?
 
C'est quand même pas la lune que je demande. Là je suis bloqué avec Oracle qui plante carrément maintenant en faisant les requêtes (erreur d'espace dans les tables temporaires utilisées en interne pour les requêtes)
 

C'est l'objet de mon tout prochain taf Arjuna. Désolé de ne pas pouvoir te t'aider présentement mais c'est clair qu'on va s'entendre

Bon, en plus y'a le directeur informatique au niveau Europe qui ne voulais pas qu'on utilise ça.
Alors j'ai dit, "puisque c'est comme ça, et qu'on n'a pas de solution, on va faire un batch qui va générer 1 300 000 fichiers toutes les nuits nommés par le code des produit, avec comme contenu les descriptions des fichiers, et on va utiliser Index Server (service natif de Windows Server) pour faire les recherches. Ca va être merdique, mais au moins ça marchera."
 
Du coup ça l'a calmé, là ils sont en train de tester la charge nécessaire pour le module Oracle Text... J'espère que c'est pas trop gourmand, parceque s'il faut upgrader le serveur Sun pour ça, on est très mal, ça va coûter bombom de rajouter des CPU et de la mémoire

En même temps, t'es sûr que Oracle Text va résoudre ton problème de perf ?

Normalement, c'est fait pour, j'espère oui...

En tout cas ça peut pas être pire que des LIKE dans des CLOB