a propos de la programation d'un moteur de recherche - PHP - Programmation
Marsh Posté le 04-07-2003 à 12:46:19
bah, l'idéal, c'est de te faire une sorte d'index. Exemple simple: Tu prends une table qui reprend tous les mots utilisés et leur attribut un id et une autre table qui met en relation id du mot avec id d'un message le contenant. Evidemment, ca booste considérablement la taille de ta db mais si tu veux rajouter des recherche phonétique c'est nettement plus pratique.
le full text, c'est pas terrible actuellement.
Marsh Posté le 04-07-2003 à 12:46:27
gére un index et sa ira nickel
tain, tu m'a devancé de 8 secondes ..
Marsh Posté le 04-07-2003 à 12:47:15
full texte = c'est bien si tu veux voir ta charge serveur monter en fleche.
Il faut que tu créés des tables d'index, que tu remplira a chaque message posté.
exemple, je poste dans le topic 11, un message "salut a tous !"
ton forum va ajouter dans une table words les mots > 3 lettres (un simple explode(" ",$msg); ) qui n'existent pas, et ainsi recuperer un identifiant PAR mot
exemple :
ID | mot
12 | salut
45 | tous
ensuite, tu rajoute dans une table search (clé composée des 2 champs)
ID | topic
12 | 11
45 | 11
ainsi, quand tu va faire une recherche du mot "salut"
tu fais une requete pour recuperer l'id de ce mot
et tu fais un simple
select topic from search where id = ID_DU_MOT;
A+
Marsh Posté le 04-07-2003 à 12:59:04
ben je vois que tout les trois avez eu la meme idée
j'avais pensé a ca mais je me disais que ca allait prendre une taille immense et que j'avais une idées de fou
mais vu que je ne suis pas le seul a penser cela
par contre c'est vrai qu'au niveau espace de la bdd
Marsh Posté le 04-07-2003 à 13:01:40
forummp3 a écrit : ben je vois que tout les trois avez eu la meme idée |
taille et rapidité sont liés inversement.
Marsh Posté le 04-07-2003 à 13:10:17
d'accord je garde cette solution et je testerais.
Sinon est ce que vous avez une solution qui prendrait moins de place ?
est ce que avec un select puis ensuite avec preg_match c'est rapide ?
Marsh Posté le 04-07-2003 à 13:12:14
forummp3 a écrit : d'accord je garde cette solution et je testerais. |
Non, ca augmenterai la charge serveur considérablement
Marsh Posté le 04-07-2003 à 13:20:21
Skylight a écrit : taille et rapidité sont liés inversement. |
Quand on parle français, on dit "taille et rapidité sont inversément proportionelles"
Marsh Posté le 04-07-2003 à 13:29:16
gizmo a écrit : |
Mais moi je parle mon français dauphinois, pas le français belge
Marsh Posté le 04-07-2003 à 13:35:58
Skylight a écrit : |
ca veut dire qu'une requete like prend moins de resource ?
Marsh Posté le 04-07-2003 à 13:50:59
forummp3 a écrit : ca veut dire qu'une requete like prend moins de resource ? |
je sais pas lequel prends plus de ressources que l'autre, mais un preg_match demande des ressources processeur, et un LIKE aussi...
Marsh Posté le 04-07-2003 à 14:01:13
je viens tester le full text. C'est impressionnant de rapidité
sur une table de 35 mo ( 30000 enregistrements ), il trouve un mot ( resultats classés par pertinence ) en 0.003s.
pour inserer, il met 8s pour inserer 30mo ( 10000 enregistrements )...
donc c'est sans probleme la recherche que je vais utiliser maintenant
Marsh Posté le 04-07-2003 à 14:12:13
karamilo a écrit : je viens tester le full text. C'est impressionnant de rapidité |
c'est mysql qui classe par pertinence ?
Marsh Posté le 04-07-2003 à 14:21:19
n'empeche que c'est vrai que avec full text ca va hyper vite
Je crois que j'ai trouver ma solution pour le moment
mais j'aimerai bien savoir comment classer par pertinence maintenant
Marsh Posté le 04-07-2003 à 14:21:35
ReplyMarsh Posté le 04-07-2003 à 14:58:42
karamilo a écrit : oui c'est ecrit dans la doc |
je viens de tester et c'est pas trop par pertinence
Marsh Posté le 06-07-2003 à 11:05:39
ha ok,je savais pas qu'il fallais faire la requete comme ca
Marsh Posté le 06-07-2003 à 12:27:43
Ca doit faire 6 mois que j'ai pas touché à PHP mais je vais m'y remettre. En ce qui concerne le moteur de recherceh ça m'avait posé pas mal de pb.
Le meilleur rapport simplicité/performances que j'avais trouvé était le Full Text. Certes c pas ce qu'il y a de mieux mais c clairement mieux qu'un LIKE.
Sinon je te conseille ce lien :
http://www.onlamp.com/pub/a/php/20 [...] ngine.html
Marsh Posté le 06-07-2003 à 13:12:00
Skylight a écrit : full texte = c'est bien si tu veux voir ta charge serveur monter en fleche. |
je viens de penser a un truc.Dans certain cas ton moteur de recherche n'est pas super,car imagine que tu a le mot "parisien" et que tu cherche "paris",le mot parisien ne sera pas pris en compte alors qu'il contient bien le mot paris,donc d'un coté c'est pas super
Marsh Posté le 06-07-2003 à 14:30:06
pour ceux qui ont un serveur dédié,vous avez le logiciel mngoseach http://search.mnogo.ru/download.html
Marsh Posté le 10-07-2003 à 12:46:32
je suis en train de tester un systeme,c'est a dire de faire une requete avec like et ensuite de stocker le resultat puis ensuite de faire un select.Vous en pensez quoi ?
Marsh Posté le 10-07-2003 à 14:10:52
c'est quoi la recherche Full Text ?
Marsh Posté le 10-07-2003 à 14:16:05
forummp3 a écrit : pour ceux qui ont un serveur dédié,vous avez le logiciel mngoseach http://search.mnogo.ru/download.html |
Y'a aussi htdig : http://www.htdig.org
Je l'ai déjà utilisé et je l'ai trouvé pas mal
Marsh Posté le 10-07-2003 à 14:17:53
Harkonnen a écrit : c'est quoi la recherche Full Text ? |
c'est une sorte d'indexation automatique réalisée par MySQL. Ca accélère la recherche par rapport à un bête LIKE, mais ce n'est pas encore aussi performant qu'une bonne indexation manuelle.
Marsh Posté le 10-07-2003 à 14:20:10
*Syl* a écrit : Y'a aussi htdig : http://www.htdig.org |
et ca marche comment avec php ce genre de logiciel ?
Marsh Posté le 10-07-2003 à 15:18:59
franchement pour avoir testé le full text, je vois pas comment on peut faire plus rapide avec la pertinence.
Marsh Posté le 10-07-2003 à 15:26:17
karamilo a écrit : franchement pour avoir testé le full text, je vois pas comment on peut faire plus rapide avec la pertinence. |
c'est long pour les trés grande table.
Marsh Posté le 10-07-2003 à 15:37:50
On gagne bcp à faire une table
*nom-id
*id-post
en lieu d'une
*nom-post
Marsh Posté le 10-07-2003 à 16:02:42
forummp3 a écrit : c'est long pour les trés grande table. |
perso 0.0004s pour une table de 1 300 000 enregistrements soit 330mo, je trouve pas ca long.
j'ai jamais vu de recherche aussi rapide ceci dit. Ne pas oublier aussi que la taille de la bdd est tres moindre par rapport a un index manuel
Marsh Posté le 10-07-2003 à 16:07:04
karamilo a écrit : |
C'est un type de champ ?
C'est a mettre, pour un forum, pour le champ des messages ?
Marsh Posté le 10-07-2003 à 16:10:50
non c'est le fait de faire une table avec a chaque ligne un mot et les id des messages ou il se trouve.
Le but est de rechercher ce mot dans cette table puis de dire ce mot est dans les messages id=5 et id=17.
apres, y'a plus de probleme
Marsh Posté le 10-07-2003 à 18:10:51
forummp3 a écrit : et ca marche comment avec php ce genre de logiciel ? |
Faut un dédié pour pouvoir l'installer, après suffit juste de l'intégrer à ton site..
Marsh Posté le 04-07-2003 à 12:42:02
Bonjour tout le monde
Je voudrais coder un moteur de recherche en php pour une base de donné assez importante avec plus de 100 000 enregistrement,donc je ne vois pas comment faire car si j'utilise un like dans ma requete j'en ai pour des plombe.
Est ce que vous avez des astuses pour avoir un truc optimisé et rapide ?
J'ai entendu parler de full text,c'est efficace ca ?
Merc d'avance pour vos futurs reponse
---------------
lecteur mp3 yvele's smilies jeux de fille