Mai Travaux yN - Page 3

kim, la version précédente du moteur était comme ca .... et g du la virer ^^ (j'avais meme fais un hashcode comme ca j'avais qu'a chercher dans des int => + rapide)

le pb vient de +eurs choses : si tu cherche 2 mots => faut soit faire un OR (=> performances BLAM), soit une autre requete avec UNION par ex (=> perfs RE-BLAM).

Et en séparant par ordre alpha .... si +eurs mots chercher dans +eurs tables ? bof

'fin si tu veux on en rediscute ce soir ^^

bah, on cherche jamais deux mots... si ?

si, dans 50% des cas

et tu veux pas publier la base de données sujet=>mots, histoire qu'on puisse voir quel type d'algo serait applicable ou pas ? évidemment tu peux appliquer un hash aussi bien au contenu des mots qu'au nom du sujet, pour pas qu'on puisse retrouver le contenu des forums privés

t marrant toi ... appliquer un algo

mais si tu veux t'amuser :

`id` int(10) unsigned NOT NULL default '0',
`forum` mediumint(10) NOT NULL default '0',
`date` int(11) unsigned NOT NULL default '0',
`full` tinyint(1) unsigned NOT NULL default '0', `keywords` text NOT NULL,

fala ^^

nan mais ca les en-tetes des colonnes ca permet pas de savoir si une méthode est viable
tout dépend de la distribution des mots dans les sujets... et ca ca peut se savoir qu'en ayant acces au contenu de la table...

yAro> Pourquoi tu te braques dès que Pollux propose une ingénieuse suggestion ?

m'est avis qu'elle doit etre grosse la table

Pollux :
nan mais ca les en-tetes des colonnes ca permet pas de savoir si une méthode est viable
tout dépend de la distribution des mots dans les sujets... et ca ca peut se savoir qu'en ayant acces au contenu de la table...

bah qu'est ce que tu veux de plus ? tu prend tous les mots (de + de 3car) uniques d'un sujet et tu les met à la suite dans keywords... jpeux pas te donner la table elle fait +eurs mégas !!

Sasume :
yAro> Pourquoi tu te braques dès que Pollux propose une ingénieuse suggestion ?

en quoi je me braque ???

Tiens si tu veux un exemple :

32710 1035 1074892382 0 j\'arrive déplacer l\'autre topic confus marque erreur anniversaire hippopotame kado gato edit smiley cite fait j\'ai liste catégories lesquelles peux enfin c\'est très grave maintenant deux topics tout encore telchar aussi bisoo mici calin cado chapo sorr0w ignare sorrow incapable faire kado\ comme faut ch\'uis bourre naniv merci mais t\'es avance dans jours partie forum post sujet zavez passer demandait gentillement preter bonne idée longtemps qu\'il n\'est passé normal piégé obligé travailler o2os trouvé trainait terre allant chez konci serait-ce tiens l\'ai recupéré sinon prêter attendant commence m\'arriver drôles choses pourrait être pire transformer petite rivière persone veut tant vince parle malheur

yAro :
jpeux pas te donner la table elle fait +eurs mégas !!

ah ok mais ca devrait etre uploadable sur databob ou autre si ca fait pas 150 Mo, non ?
parce que soit il faut faire des tests sur un nombre limité de sujets -> résultats tres différents, soit il faudrait te bouffer 10x plus de bande passante pour aspirer un nombre suffisant de sujets...

T'as qu'a dédoubler 10 000x ce que je t'ai donné, ca suffira

ben non, justement, ca aurait pas du tout les memes propriétés ^^ (rien que le nombre total de mots distincts )

D'ailleurs, ce nombre total de mots distincts pourrait etre divise par au moins 10 ou 20 si l'orthographe de certains n'etait pas si deplorable ...
Premiere idee : virer les accents au moment de l'enregistrement des keywords et sur les mots cherches (comme le fait Google par exemple), ca permet en plus aux utilisateurs de QWERTYs comme moi de faire des recherches sur des mots normalement accentues.
Seconde idee (beaucoup plus dure a mettre en oeuvre, et en plus l'envoi d'un post va bouffer du temps et des ressources) : alleger le champ keywords en utilisant un dictionnaire et en n'enregistrant pas les mots absents du dictionnaire.
Ce dictionnaire devra contenir le plus possible de mots francais (avec tous les accords), anglais et esperanto, ainsi que la liste complete des membres et du vocabulaire courant sur yN mais pas dans un dictionnaire classique (je pense en particulier aux noms de fonctions informatiques qui sont des concatenations de mots anglais, comme nostub (ca s'ecrit bien comme ca ?) ou romcall (idem)).
Mais bon, je ne pense pas que cette seconde idee soit viable ...

alleger le champ keywords en utilisant un dictionnaire et en n'enregistrant pas les mots absents du dictionnaire.
Ce dictionnaire devra contenir le plus possible de mots francais (avec tous les accords), anglais et esperanto, ainsi que la liste complete des membres et du vocabulaire courant sur yN mais pas dans un dictionnaire classique (je pense en particulier aux noms de fonctions informatiques qui sont des concatenations de mots anglais, comme nostub (ca s'ecrit bien comme ca ?) ou romcall (idem)).
Mais bon, je ne pense pas que cette seconde idee soit viable ...

Donc si demain je lance le projet StroShblup personne ne pourra trouver les postes qui en parle, vu que le mot serra ignoré, spa top quand meme tu pense aps ?

C'est bien pour ca que j'ai dit que ce n'etait pas viable ...

je pense qu'avec la méthode actuelle de yaro ce qui ralentit c'est pas tellement les mots rares (meme si ca prend de la place dans la BDD, c'est pas gravissime), c'est plutot les mots fréquents quand on en recherche plusieurs a la fois... je me trompe ?

De toutes façons, mot rare ou fréquent, l'intégralité de la table doit être parcourue, donc bon...
Sinon, pourquoi ne pas travailler avec une table en RAM ?
En fait, tu mets à jour une table à chaque validation de post, et une fois (ou deux, ou plus) par jour, tu copies cette table dans une table en mémoire, beaucoup plus rapide d'accès (donc sur laquelle tu peux faire beaucoup de traitements).
Bon, je n'ai pas pensé à un truc, c'est que la taille de cette table doit être énorme, donc doit prendre à elle seule toute la RAM du serveur .

je suis assez daccord, pour l'accentuation e meme que pour les mots apostrophés.
Et le dico, n'est pas si bete que ca non plus, si les utilisateurs peuvent le modifier

Nil :
De toutes façons, mot rare ou fréquent, l'intégralité de la table doit être parcourue, donc bon...
Sinon, pourquoi ne pas travailler avec une table en RAM ?
En fait, tu mets à jour une table à chaque validation de post, et une fois (ou deux, ou plus) par jour, tu copies cette table dans une table en mémoire, beaucoup plus rapide d'accès (donc sur laquelle tu peux faire beaucoup de traitements).
Bon, je n'ai pas pensé à un truc, c'est que la taille de cette table doit être énorme, donc doit prendre à elle seule toute la RAM du serveur .

le pbm c'est que tu peut pas dire a MySQL de mettre spécialement une table en RAM, et je suis pas sur que ça change gd chose... (les requetes SQL sont généralement fait pour etre rapide, tres rapide)

Sinon pour le dico, je trouve sa completement idiot, antievolutif et completement absurde d'un point de vu utilisateur.. je vois tres mal le site me dire "ha je connais pas 'schmilblick' veux tu l'ajouter dans mon dico ?"

c'est absurde en plusieurs points :
1 -> ça rajoute un traitement assez inutile et ralentissant du coté du serveur
2 -> ça me fait chier moi pasque j'ai autre chose a faire
3 -> 99.9999% des users vont ajouter tout les mots qu'il vont rencontrer dans de tel cas, donc ça pert tout son interet

bref

le pbm c'est que tu peut pas dire a MySQL de mettre spécialement une table en RAM, et je suis pas sur que ça change gd chose... (les requetes SQL sont généralement fait pour etre rapide, tres rapide)

Si, il y a un format de table (heap, si je ne m'abuse) qui est en RAM, et c'est très utilisé.

Hum, faudra que je revise mon MySQL book alors

Nil
: De toutes façons, mot rare ou fréquent, l'intégralité de la table doit être parcourue, donc bon...

huh
depuis qd pour vérifier qu'un mot appartient a un ensemble il faut regarder tous les éléments un par un

Sinon, pourquoi ne pas travailler avec une table en RAM ?

en principe un cache est fait pour que ca soit fait de maniere transparente ^^

Pollux :
je pense qu'avec la méthode actuelle de yaro ce qui ralentit c'est pas tellement les mots rares (meme si ca prend de la place dans la BDD, c'est pas gravissime), c'est plutot les mots fréquents quand on en recherche plusieurs a la fois... je me trompe ?

ce qui ralentit c la taille de la bdd surtt !

Nil :
De toutes façons, mot rare ou fréquent, l'intégralité de la table doit être parcourue, donc bon...
Sinon, pourquoi ne pas travailler avec une table en RAM ?
En fait, tu mets à jour une table à chaque validation de post, et une fois (ou deux, ou plus) par jour, tu copies cette table dans une table en mémoire, beaucoup plus rapide d'accès (donc sur laquelle tu peux faire beaucoup de traitements).
Bon, je n'ai pas pensé à un truc, c'est que la taille de cette table doit être énorme, donc doit prendre à elle seule toute la RAM du serveur .

+ de 50Mo en ram .... euh .. vont pas apprécier chez infomaniak

Godzil :
le pbm c'est que tu peut pas dire a MySQL de mettre spécialement une table en RAM, et je suis pas sur que ça change gd chose... (les requetes SQL sont généralement fait pour etre rapide, tres rapide)

si c les tables HEAP ^^

Pollux
:

Nil
: De toutes façons, mot rare ou fréquent, l'intégralité de la table doit être parcourue, donc bon...

huh
depuis qd pour vérifier qu'un mot appartient a un ensemble il faut regarder tous les éléments un par un

depuis que MySQL n'utilise pas d'index qd on cherche avec la commande LIKE => ca parcourt TOUT !

depuis qd pour vérifier qu'un mot appartient a un ensemble il faut regarder tous les éléments un par un

Ben... si tu n'as ps d'index, tant que tu n'as pas vérifié l'intégralité des mots, tu es obligé de tout parcourir (vu que si je ne m'abuse, yNSearch surligne toutes les occurences trouvées).

yAro
:

Pollux
:

Nil
: De toutes façons, mot rare ou fréquent, l'intégralité de la table doit être parcourue, donc bon...

huh
depuis qd pour vérifier qu'un mot appartient a un ensemble il faut regarder tous les éléments un par un

depuis que MySQL n'utilise pas d'index qd on cherche avec la commande LIKE => ca parcourt TOUT !

je parlais d'un point de vue théorique, pas de ton implémentation en particulier (et y a pas forcément besoin de restructurer completement le truc, par exemple simplement en coupant les gros sujets en 2 ou 4 selon un ordre prédéfini [par exemple en utilisant un hash] on peut ne faire la recherche que sur la portion voulue)

c pas mon implémentation en particulier ... pr rechercher du txt dans du txt y'a que le LIKE (ou la recherche FULLTEXT mais c pas applicable)

et le fait de découper le topic ne servirait à rien, si le mot qu'on cherche se trouve dans la 3eme partie il faudra qd mme le trouver en passant par les 1 et 2 avant

nan nan...

par exemple découpage en 4, si j'ai hash(nil) = 4321, hash(ours) = 1234, hash(foret) = b0b0, hash(censored) = 6969, et ben pour chaque sujet je partitionne les mots en ceux dont le hash est compris entre 0000 et 3fff (region1), 4000 et 7ffff (region2), etc...
donc pour chercher "censored", je vois qu'il est dans la region 2, donc ma requete SQL sera "sujet.region2 LIKE 6969", et sujet.region2 sera en moyenne 4x plus court que la totalité des mots (ici j'ai que 2 mots, nil et censored). et ca marche aussi si on veut rechercher plusieurs mots, sauf qu'évidemment plus on recherche de mots plus il faut examiner de régions

on peut raffiner encore, puisque pour un sujet avec 3 mots ca sert a rien de couper en 4, et inversement pour un sujet avec 100000 mots il vaudrait mieux couper en plus ; pour ca, on peut regrouper les sujets par groupe de taille (éventuellement dans des tables différentes, ou simplement avec un flag en début de sujet pour indiquer le groupe voulu) : les petits sujets seront pas énormément subdivisés, alors que les gros sujets seront subdivisés plus finement.


mais bon la mon but c'est juste de montrer qu'on est pas obligé de rechercher les mots un par un, je suis sur qu'on pourrait faire bien plus subtil et efficace si on avait acces a la BDD

d'ailleurs ce serait utile de pouvoir aussi rechercher les mots de 3 lettres, y en a vraiment tant que ca ?

j'avais deja expérimenté ca à la version précédente du moteur de recherche, mais le pb est que :
- si 2 mots sont dans 2 tables( ou regions pr respecter tes termes), les performances s'effondrent à cause des tris à effectuer (classer par date par ex)
- chaque subdivision devrait ê une table ... si je rajoute trop de tables c le site entier qui sera pénalisé lors de l'accès à chaque table^


Ensuite le fait de + ou - subdiviser le sujet prendrait trop de tps à mon avis ... un sujet commence ac peu de mots ... et qd il arrive à 100 000 on fait quoi ? on se retape ttes les subdivisions à faire => impossible !

si tu veux jte fais une table de test avec mon index de mots dans la journée, t'aura qu'a t'amuser avec