E R 14:39 onur » yAro: ok, je post, je vais dissimuler l'adresse de ffs


R 14:39 yAro: aucun pb ^^


R 14:38 onur » yAro: à une chanson on associe pas juste un mot, déjà le titre c'est plusieurs mots et puis il y a tous les autres attributs, artist, album, genre, compositeur etc..

mais malgré ca je veux bien qu'il y ait une différence de taille mais vu qu'on indexe tout, ca varie en log(n) en principe. Donc avec 100 fois plus de données, l'utilisateur attendra peut etre 10 fois plus.. mais vu que c'est instantané dans le premier cas..

je te propose qu'on publie cette discussion dans le forum pour avoir le feedback/avis des autres, qu'en dis-tu?


R 14:36 yAro: t'aurais pas le script qui indexe tout ca ? ca m'eviterait de perdre du tps à le recoder


R 14:35 yAro: je sais utiliser les index myqsl merci

et sinon t'as testé avec 200 000 chansons ... c'est bien ... sauf qu'un titre de chanson est de loin inférieur à la taille moyenne d'un post d'yN et de plus y'a 2 170 000 posts en base ... pas 200 000 ^^


R 14:31 onur » yAro: tu avais indexé au niveau sql les attributs?

parce que justement dans la table 1, ce que je fais, je mets 10 attributs lettre1, lettre2, lettre3 etc.. et je les indexe aussi. J'indexe pas en fulltext quoi. Et si tu indexes pas du tout la table 2, ca sert strictement à rien ce systeme.

La requete n'est pas inchiable du tout, le php te le crache instantanément, regarde ca: (cest ultra secret ce lien)

http://http://************************

ya que 3 chanson là dans la base, mais j'ai testé avec 200000 chansons et cest instantané! je te montre ce lien pour te montrer que ca construit la requete sql comme il faut assez rapidement.

actuellement dans spool, cest du fulltext, et ca sux méchamment je trouve.


R 14:27 yAro: bah si tu veux jpeux te fiare une démo, ca me coute rien, tu verras que les temps de recherche sont enormes avec ce systeme, c'est le premier que j'ai mis en place sur yN et c'est à cause de ca que je l'ai viré


R 14:25 onur » yAro: ca marche très bien je t'assure, on va l'intégrer à la nouvelle version de spool (http://spool.fm) où il y aura des millions de titres.

le numéro de sujet c'est pas un souci, t'as pas besoin de l'indexer celui là si tu indexes les autres attributs critiques.

Bien sur qu'il faut que la table d'asso ait beaucoup de ligne, y a pas de miracle.. c'est à toi de voir.


R 14:21 yAro: ok on est bien d'accord alors

ton systeme c'est celui de phpbb en fait

ensuite moi me faut le numéro de sujet encore pour retrouver le post,

et cette solution n'est absolument pas réalisable sur yN ... la table d'assoc aurait bcp trop de lignes ....

de plus avec ton systeme je on cherche 2 mots, ca fait grosso modo 2 requetes avec un "OR" entre les 2 .... et là si t'arrives à avoir une réponse avant le timeout php chapo


R 14:19 onur » yAro: table1:keywords

id | mot
-----------------
1 | test


table2: assoc

worid | postid | forumid
---------------------------
1 | 2 | 2
1 | 2 | 3
1 | 5 | 1

le tuple (wordid, postid, forumid) doit etre unique. Tu indexes le tout, pour la table 2 --> pas trop de cout, ces des valeurs numériques. Pour la table 1 --> pas trop de cout, s'il y a peu de mots différents dans le forum.


R 14:15 yAro: c'est un des premiers trucs que j'ai mis en place jte dis ^^

pour être sûr .... c'est à un truc comme ca que tu penses ?

mot | forum | sujet | post
---------------------------
"test" | 1 | 2 | 3
"test" | 1 | 3 | 4
"test" | 2 | 5 | 1




R 14:11 onur » yAro: francehement sans faire de hash, je pense qu'on peut s'en sortir. Vu que cest toujours les memes mots qui reviennent dans un forum, la table qui va surtout se remplir cest celle de l'association (et pour le forum choisi tu peux ajouter un attribut à l'association et faire des associations en plus au besoin), et donc ca prendrait pas de place.


R 14:07 yAro: c'est pas vraiment précisé, le pb c'est qu'ils te préviennent jamais à l'avance quand c'est trop, mais ils élaguent

mais par expérience une table > 200Mo commence a pas mal ramer en insert/update avec du fulltxt


R 14:06 onur » yAro: on a le droit à combien de MO ?


R 14:04 yAro: j'ai déjà testé une technique comme ca :

hashcode entier du mot => postX, postY, postZ

Le pb apres c'est que ca prend plus de place au final et si tu cherches pas le mot exact bah tu trouvera rien ...

De plus si tu fais une relation mot => posts, comment tu geres les différents forums (un mot apparaissant dans le forum ti ne doit pas être trouvé sur le forum pockett par ex) ? il faudrait dupliquer ce systeme pour chaque forum du coup => encore plus de place

actuellement j'ai des tables fulltext "élaguées", je filtre tous les posts par rapport à des mots communs, trop petits, caracteres spéciaux et autre afin de n'indexer que le strict nécessaire ... et rien que ca sur l'année 2007 me prend deja 105Mo


R 13:57 onur » yAro: moi je fais un moteur de recherche qui prend pas mal de place mais j'utilise pas fulltext en fait, je gere les index à la main.

J'ai une table avec les mots clés, et j'associe à chaque mot clé, les éléments (ici ca va etre les posts) qui contiennent ce mot clé. La table avec les mots clés est pas indexé sur le string, mais sur 10 attributs entiers qui sont les valeurs décimales des 10 premiers caractères unicodes. J'indexe ces 10 attributs. Résultat: cest fucking rapide. Apres au niveau place, ca doit dépendre des données, mais je pense que dans le cadre d'un forum, y a pas mal de mots qui reviennent souvent. Donc à voir.
Tu fais comment actuellement?