yN Moteur de recherche - Page 5

Je réponds: file moi la base , du moins la partie à laquelle j'ai accès, ce qui doit être relativement representatif je pense, et on va voir. Ca m'évitera de parser tout le yN.

As-tu joué sur le paramètre que je viens de te dire? Non. Tu as fait comme à ton habitude, "je colle la solution géniale qu'on me donne et je réfléchis pas".

je viens de re regarder tes scripts et y'a pas de parametre pour choisir la taille min d'un mot ...

* y a pas de fonction toute prete, c'est quelque chose dont je t'ai parlé en mmsg. Il faut éliminer le nombre de champs de la table ffs_word, et modifier le script en conséquence. "10 champs" était un choix arbitraire, cest pour ca que je parle de "paramètre", ce n'est pas un argument des fonctions que je t'ai donné.
* C'est pas la "taille min d'un mot", c'est plutot "le nombre de lettres qui vont etre indexées pour un mot"

Alors ca changera rien au principal problème, le nombre de lignes dans la base.

vince (./113) :
tu connais google ?

google c'est OU par défaut, si tu veux autre chose, faut le préciser

Non, je ne crois pas.

au début de google peut être mais maintenant ça doit être plus compliqué qu'un simple ou

et puis google trouve des mots avec < 4 lettres.

Sasume (./125) :

vince (./113) :
tu connais google ?

google c'est OU par défaut, si tu veux autre chose, faut le préciser

Non, je ne crois pas.

sisi, ou inclusif, mais sur les recherches fructueuses il élude les résultats que l'un ou que l'autre...

par contre sur les recherches peu banales, il peut proposer des résultats qui ne correspondent qu'à une partie des critères.

onur (./127) :
et puis google trouve des mots avec < 4 lettres.

mais google n'est pas (à ma connaissance hein, tu peux peut ^tre me prouver le contraire) hébergé sur un serveur mutualisé

(et puis ils n'utilisent pas mysql, mais un truc qui a mis des années à être développé ...)

onur (./113) :
tous les mots qu'on recherche doivent faire au moins 4 lettres

Est-ce vraiment dramatique ? Sachant que la majorité des mots font moins de 4 lettres, avec la contrainte de la taille de la base, autant économiser. Si tu regardes dans un dictionnaire, la plupart des mots de moins de 4 lettres n'ont aucune pertinence dans une recherche lambda : pronoms, articles...


(et sinon je confirme : google fait un ou inclusif, et favorise simplement à la pertinence, les résultats, c'est pour ça que tu as tendance à trouver des liens contenant l'ensemble de tes mots)

Bon, je viens de relancer le script d'onur pour avoir des chiffres frais. J'ai lancé l'indexation sur 100 000 posts, voici les résultats :

1- j'ai mis un max execution time à 3600s, le script a pas fini de s'executer, il n'a reussi à indexer que 62 241 posts. (=> 50ms par post, sachant que les perfs vont se dégrader à force et à mesure que la table va contenir plus d'enregistrements)
2- la table contenant les mots a 69 971 lignes, ca ca va encore
3- la table assoc a 1 499 671 enregistrements
4- la table assoc fait 37 732 Ko
5- recherche ET exclusive, sans scoring

Maintenant mon systeme :

1- indexe 266 027 posts en environ 2min (=> moins d'1ms par post)
2- pese 125,6Mo pour ce nombre de posts
3- recherche booléenne avec scoring

Si on extrapole les résultats du truc d'onur on aura du coup, pour 266 027 posts, une table d'assoc qui va contenir 5 701 690 .. ca tient dans une table ca ???

Maintenant qui peut m'expliquer, point par point en quoi le systeme d'onur est meilleur ?

Pas moi. Mais on peux pas lui en vouloir d'essayer d'aider. Par contre il a un sens du contact très discutable.
Par rapport à ça:

2- pese 125,6Mo pour ce nombre de posts

Effectivement, ton système semble meilleur.
Mais il dois être possible de faire mieux, yn n'est pas le seul gros forum, et beaucoup ont une recherche très correct.
L'inverse est vrai également, je ne critique pas.
Et puis est-ce nécessaire toutes ces perfs? Comment font les autres forums? On a besoin de vitesse ou de resultats pertinents sur une recherche? Fonction qu'on utilise une fois tous les 6 mois?

Pas taper!

GUNNM (./132) :

Mais il dois être possible de faire mieux, yn n'est pas le seul gros forum, et beaucoup ont une recherche très correct.

Combien de gros forums sont sur du mutualisé ?

GUNNM (./133) :
Et puis est-ce nécessaire toutes ces perfs? Comment font les autres forums? On a besoin de vitesse ou de resultats pertinents sur une recherche? Fonction qu'on utilise une fois tous les 6 mois?

en fait, ici on ne parle que d'insertion, donc ça veut dire 50ms à chaque fois que tu postes un message, contre 1ms avec le système actuel. C'est un temps qui s'additionne à chaque opération lorsque tu postes un message. Le temps de recherche n'est ici pas calculé. Donc oui, dans ce sens là, on peut estimer qu'on a besoin de certaines performances.

GUNNM (./132) :
Et puis est-ce nécessaire toutes ces perfs? Comment font les autres forums? On a besoin de vitesse ou de resultats pertinents sur une recherche? Fonction qu'on utilise une fois tous les 6 mois?

Ils sont sur des serveurs dédiés ?

Par ex pdafrance, moitié moins de posts que moi, ils utilisent le systeme par défaut de VBB qui est analogue à celui d'onur (en compliquant moins), ils ont un dédié et meme avec ca ils ont des pb de stabilité avec la recherche (table qui plante tous les X temps sans raison).

Concernant mon moteur, l'ergonomie a été modifié, mais en quoi les résultats retournés posent problème ? Car c'est de là que part tout ce débat, j'ai déjà posé la question mais j'ai tjrs pas de réponse !!

Je crois que le seul probleme est/etait l'utilisabilité de la recherche (un peu contraignante a une epoque il me semble) mais pas la pertinance

bah là ca me semble bon non ?

Je suis d'accord avec vous. J'essayais juste de comprendre tout ça. Je me tais.

non, tu ne te tais pas : une question n'est jamais idiote, et il vaut mieux la poser que de garder un vieux doute planer

yAro (./137) :
bah là ca me semble bon non ?

Je sais pas, je l'ai pas testé depuis un moment perso

1° le temps n'est pas important franchement, entre 1ms et 50ms on va pas chipotter quoi. Ce temps va augmenter avec le nombre de post, oui. Mais que très peu. A mon avis on arrivera difficilement à 60ms vu le nombre de posts qu'il y a déjà. C'est de la mauvaise foi j'ai l'impression.
2° donc en extrapolant, mon "algo" (c'est prétentieux de l'appeler ainsi mais bon) prendrait 145 Mo contre 125Mo pour le tiens? On est loin des rapports annoncés dans les posts assassins précedents par tes potes.
3° Le scoring n'a pas vraiment de sens avec un "ET" puisque la recherche ne te trouve pas "ce qu'il peut" mais "exactement ce que tu veux".
4° Oui les mots de moins de 4 lettres sont importants, parce qu'il y en a toujours au moins un dans un bout de phrase dont on se souvient. exemple "cdg contre les ...."

onur (./141) :
1° le temps n'est pas important franchement, entre 1ms et 50ms on va pas chipotter quoi. Ce temps va augmenter avec le nombre de post, oui. Mais que très peu. A mon avis on arrivera difficilement à 60ms vu le nombre de posts qu'il y a déjà. C'est de la mauvaise foi j'ai l'impression.

C'est énorme tu veux dire !

ça représente grosso modo temps actuel * 4.

Tu sens la différence entre 1ms et 50ms quand tu posts? Les aléas du réseau impliquent beaucoup plus de différence je pense.

En plus, pour une insertion séparé, je pense pas que ca prenne 50ms, ca m'étonne un peu, mais je peux pas dire, j'ai pas fait de bench à ce point.

sauf qeu ce n'set pas quand tu poste mais poru indexer, et c'est quand meme bcp ! (c'est comme si tu mettait 50h pour faire un truc qui prend 1h..)

moi non (quoique), mais le serveur, lui, tu lui multiplies d'autant la charge.

exemple de suxage:

"Un bon sac de voyage" renvoie par hasard le bon résultat en troisième place... mais avant il trouve "voyage voyage" et je ne sais quoi d'autre..

Si ca sortait le bon résultat, tu tiendrais pas tant à ton "score". (Et encore pour mysql "voyage voyage" a plus de ou autant de score que "Un bon sac de voyage")

onur (./141) :
1° le temps n'est pas important franchement, entre 1ms et 50ms on va pas chipotter quoi. Ce temps va augmenter avec le nombre de post, oui. Mais que très peu. A mon avis on arrivera difficilement à 60ms vu le nombre de posts qu'il y a déjà. C'est de la mauvaise foi j'ai l'impression.

non c'est pas de la mauvaise foi ... actuellement un post est ajouté en moyenne en 80ms, avec l'indexation, plein de verifs de droits, doubles posts & co, si je rajoute 50ms ca va augmenter de plus de 50% le temps ... c'est trop important, de plus 50ms c'était une moyenne sur 62k posts .. et quand je regarde, par rapport aux 1ers posts indexés, les perfs ont été divisées par 10 au moins, donc si on triple la taille des données j'ai peur que ca soit + 100ms que 50, je peux faire le test je suis plus a ca pres

onur (./147) :
Un bon sac de voyage

dans cette expression "un" "bon" "sac" et "de" sont ignorés vu qu'inférieurs à 4 lettres .... il ne cherche donc que "voyage"

"'ai peur que ca soit + 100ms que 50"

> non pour insérer il regarde la présence eventuel d'un mot, pour une premiere lettre c'est en log(n) pour la deuxieme, c'est aussi en log(n) mais parmi les résultats du premier, donc c'est en log(n)*O(log(n)) pour la troisieme et les autres ca continue pareil, donc c'est en log(n). C'est pour ca que je dis que vu le nombre que tu as déjà inseré, ca augmentera pas.


"dans cette expression "un" "bon" "sac" et "de" sont ignorés vu qu'inférieurs à 4 lettres .... il ne cherche donc que "voyage""

> c'est justement la reproche que je te fais

onur (./149) :
> non pour insérer il regarde la présence eventuel d'un mot, pour une premiere lettre c'est en log(n) pour la deuxieme, c'est aussi en log(n) mais parmi les résultats du premier, donc c'est en log(n)*O(log(n)) pour la troisieme et les autres ca continue pareil, donc c'est en log(n). C'est pour ca que je dis que vu le nombre que tu as déjà inseré, ca augmentera pas.

tu crois vraiment que mysql fonctionne comme ca ? revises tes cours sur les index alors

Avec un index le mot est trouvé en 1 itération ^^, quant au temps de recherche dans l'index est proportionnel à la taille de la table, donc si on la triple le temps va au moins double a mon avis