Discussion :

[Nanji]

Bonjour,

Je souhaite créer un moteur de recherche. Les données seront dans une base de données mysql, avec environ 10 à 20 millions de lignes de 200 caractères environ. Il faut que les résultats s'affichent en moins de 3 secondes.

Quelles solutions me recommandez-vous ? Dois-je charger la base en mémoire, dans un tableau C, puis faire la recherche en C (le plus rapide) ? Ou bien est-il plus préférable de faire directement les requêtes dans la base avec select ?

Quelle langage adopter ? perl ou C ?

[Mr6]

Perso je ne saurais pas te dire ce qu'il est préférable d'utiliser (mes connaissances en C sont bien trop loins pour comparer avec Perl) . Je te conseille tout de même très fortement de faire des tests sur une machine identique à ta machine de prod, en chargeant d'un côté ta base mysql pour lancer une requête et voir en combien de temps tu as la réponse, puis en comparant en essayant de mettre toutes ces données en mémoire pour y accéder (celà dit ca fait beaucoup de données, donc si tu penses à cette possibilité c'est que tu as du matériel qui suit je suppose). Déjà ca te permettrait de voir combien de temps tu mets juste pour cette opération principale, et ca te permettra de juger de ce que tu peut te permettre de faire autour pour afficher tes données (car ca aussi ca peut prendre du temps )

@+
Mr6

[Nanji]

dans le cas où je ferais une requête select, avec un index, toute la recherche reposerait sur mySQL.

Dans ce cas, il n'y aurait pas grande différence de performances entre utiliser un programme perl et un programme C, puisque l'essentiel de la performance repose sur la base de données. Qu'en pensez-vous ? Et quelle langage me recommandez-vous pour programmer le moteur ?

[scaleo]

On peut très bien faire sa avec du perl, pour ce qui est de ta base de donnée réfléchie y bien il ne faut pas que tes tables soit trop grosses vaut mieux plusieurs petite table que des grosses qui peuvent faire chuter les performances pour ce qui est de faire un select sur toute ta base de données sa prendra trop de temps imagine si tu fais un LIKE dans ton select tu risque d'avoir une surprise, utilise plutôt des index en texte intégral (fulltext). Regarde aussi du coté de Transact-Sql. Ensuite le reste dépend fortement de tes algos de trie il faut qu’ils soient puissant et rapide sans être des gouffres a mémoire et cpu.

[pospos]

salut
20M de messages de 200 octets ca va chercher dans les 4Go. Ca peu presque tenir en memoire, mais ca ne resoudra pas vraiment le probleme: ce qu'il te faut c'est un index fulltext (un index inversé)
Celui de MySQL est pas trop mal mais il risque de s'ecrouler sur les requetes complexes (genre phrase exacte par exemple), par contre il suffira totalement si tu ne fait que des requtes simples (genre un seul mot).
Si tu veux faire des requetes complexes je te conseil de mettres ces données dans un vrai moteur d'indexation fulltext.
Il en existes beaucoup, chacun ayant ses particularités.
Par exemple si tu n'a pas besoin d'indexation incrementale (c'est à dire si aucune nouvelle donnée ne sera ajoutée dans la base, ou si tu peux te permettre de tout réindexer regulierement pour prendre en compte ces nouvelles données) alors swish-e est pas mal (il existe d'ailleurs une version incrementale mais c'est pas ideal).
Ensuite tu a Xapian qui est tres efficace (mais pas tres bon sur les requetes de type phrase), Lucene qui bien que codé en java est egalement tres rapide.
Coté perl il existe aussi pas mal de modules pour faire ce genre de chose. Il y a un port de lucene: plucene. Je te le deconseille: il est tres lent...
Par contre tu a kinosearch qui reprend beaucoup des fonctionnalité de lucene et qui est tres efficace (mais avec du C à compiler dedans):
http://search.cpan.org/~creamyg/Kino.../KinoSearch.pm

en tous cas, avec 4Go de données texte à chercher je te deconseille les bidouilles à la main.