Bonjour à tous,
 
Je cherche une solution par rapport à une requete.
Elle concerne une colonne d'une table de 2,5 millions d'entrées qui se gonfle de 5000 nlles lignes par jour à peu près.
La colonne en question est un VARCHAR 60.
 
Je donne la possibilité de faire une recherche dessus et ça créé une requête du type WHERE ma_colonne LIKE %ma recherche%
 
Seulement voilà ça peut prendre 10 secondes avant d'avoir la réponse, et des dizaines d'utilisateurs peuvent la faire en même temps. Ce qui bouchonne bien mon appli web.
 
Alors déjà, je n'ai pas indexé cette colonne, mais c'est peut être une erreur.
Je ne l'ai pas fais car pour moi ça alourdirait de trop en cas de modif/suppression multiples, vu que déjà j'ai énormément d'autres colonnes indexées sur cette table et que j'aurai une cardinalité de 2,5 M, car il y a pratiquement autant de valeurs différentes sur cette colonne que de lignes.
 
Qu'en pensez vous ?
 
Sinon peut être pouvez-vous m'orienter vers de nouvelles pistes pour optimiser la chose.  
 
En vous remerciant,
 

C'est quoi dans ce varchar, et pourquoi rechercher dessus ?
Il y a pas mal de solutions, des dénormalisations, d'autres tables ou structures de données, ça dépend vraiment de ce que tu veux faire.

Salut,
 
Si tu fais des requêtes LIKE %truc% , enlève tes indexes, ils ne seront pas utilisés et ne feront que ralentir tes inserts.
Est-ce que tu as pensé utiliser des recherches fulltext ? Personnellement je n'ai jamais eu de bases assez grosses pour que ça devienne un problème, mais on m'a dit que ça peut pas mal aider dans les cas de recherche de strings..

Oui s'il veut chercher des mots ça fonctionne bien, maintenant il faut voir si c'est ce qu'il cherche et pourquoi, s'il y a un moyen de concevoir différemment.
 
En plus, selon la taille de la base, l'indexation fulltext était longue à l'époque... Maintenant je ne sais pas.
Avec un varchar de seulement 60 c'est quand même curieux de devoir faire ça ?

Pas plus que de faire des LIKE %truc% à tous bouts de champs sur des millions de lignes en même temps

Je veux dire curieux de devoir chercher sur des parties, c'est pourquoi j'aurais voulu comprendre. Oui le like c'est affreusement gourmand.

Merci déjà de vous pencher sur mon cas
 
C'est simple il s'agit d'intitulé de timbres.
 
Un exemple :
 
Je peux stocker comme nom:
 
Vélo 90centimes
Martine fait du vélo
Où est passé mon vélociraptor
 
Il faut que les gens qui recherchent un intitulé de timbres avec vélo tombent sur ces cas ci-dessus.

Oui et dans le cas velo au lieu de vélo, VELO, ça ne semble pas fonctionner. Et le faire fonctionner en direct signifierait un traitement à chaque fois refait. Ça ne me paraît pas une bonne solution de refaire à chaque fois ces transformations de caractères, gourmandes, tout comme le like.
 
La recherche se fait toujours par début de mot et non milieu ?

Justement, avec fulltext, suivant le moteur utilisé, il va trouver vélo, velo, VELO, et même bike ( Pas sur sous MySQL, mais je me rappelle l'avoir vu pour Oracle)

Oui ça semble indiqué.

Bein disons que je pense que ça vaudrait en tous les cas qu'il bench ça un peu ... Parce que poser des questions et donner des réponses c'est cool, mais si on a rien pour bencher ça sert à rien...
Si ça se trouve en jouant sur les caches il peut déjà s'en sortir (même si on l’occurrence j'en doute)

En fait dans ce genre de recherche la il n'y a pas 36 solutions, c'est du fulltext index (qui est +- lourd de temps en temps) ou du table scan a chaque select (qui est ultra lourd tout le temps).
 
Le full texte ne rescan que les nouvelle lignes ou les lignes modifées, donc si on est a peine a +5000 lignes par jour ca passera sans aucun probleme.
 
Si ya pas moyen d'utiliser le fulltext tu peux toujours faire une espece de solution hybride en fesant un indexation a la main dans une autre table avec les mots le plus courrant (en gros tu reinventes le fulltext index).
Ou alors ne pas autoriser les recherche qui commence par % (ce qui force le table scan vu qu'il ne sais pas ce qu'il cherche).
 
La derniere solution est d'ajouter assez de RAM pour que ta table entiere tienne en memoire et assez de CPU pour calculer le tout assez vite

j'ai vu ce genre d'utilisations sur de très gros volumes (bien plus qu'ici) en fulltext, mais aussi avec un système parallèle à la base de données (très rapide pour certaines actions même si du coup on nourrit deux systèmes en parallèle).
De plus il ne doit pas y avoir énormément de mots au final.

Je vais tester ça demain, en tout cas si le bench est concluant, c'est magnifique comme solution. Je ne connaissais pas MATCH !

Je ne suis pas un spécialiste, mais ça serait pas un bon cas d'utilisation de moteur comme Sphynx par exemple ? De ce que j'ai toujours pu en lire, ça a des perfs hallucinantes.

Ouais je confirme pour les moteurs spécialisés :  
 
on utilise souvent SolR avec ezPublish et les perfs sont sans commune mesure avec tout ce qu'on pourrait dev en interne.  
 
Je vais regarder Sphynx parce que SolR a un gros défaut  : il lui faut un bon giga de memoire pour être à l'aise  (il est dev en java)

Je vous remercie sincèrement car je ne connaissais pas l'indexage en fulltext.
Du coup j'ai transformé ma requete:
LIKE %xxx%  
par  
MATCH ('ma_colonne') AGAINST ('xxx')
 
Et là c'est magique, temps de la requete de l'ordre de 0,0007 sec en moyenne. Bref, vive Mysql quand même c'est costaud !
J'ai pourtant un dédié avec une config très moyenne.
 
Merci encore