Crawling distribué

Suite à une discussion concernant l'intérêt du crawling distribué pour un moteur de recherche voici ma réponse suite au message suivant :

En fait, ce que j'entends par crawling P2P, c'est d'utiliser un réseau
de machine pour effectuer le téléchargement des pages et en effectuer
l'indexation. En fait à bien y réfléchir, ça serait plus une approche à
la Seti@home. Le terme P2P n'est peut-être pas très approprié.

Ce qui caractérise le P2P, c'est l'indétermination de la relation client-serveur entre les pairs. Donc ici il s'agit plus généralement de technologie GRID.

L'intérêt à fetcher (télécharger) et indexer les pages est moindre : les pages que les noeuds de la grille auront indexées ainsi que leur contenu devront inévitablement être envoyé au serveur de recherche, et la bande passante gagnée sera donc reperdue... (mis à part comme l'a souligné Jerome dans l'un de ses articles, si la quantité de données envoyée au final est plus faible que la quantité engloutie par les noeuds).

Dans tous les cas, la bande passante gagnée est tellement minime que les efforts déployés pour ce faible gain sont minimes...

Pour aller dans ton sens néanmoins, je dirai que tous les grands noms du domaine des moteurs de recherche, Doug Cutting compris, sont très intéressés par une expérimentation de la chose, afin de confirmer qu'effectivement, le crawling distribué est inutile.

Maintenant, si tu étends le crawling distribué, à une recherche distribuée : tu n'as plus besoin de transférer le contenu des pages, mais uniquement tes index. Néanmoins dans ce cas, la rapidité du service de recherche est directement lié aux temps de latence des différents noeuds de recherche.

Si un noeud est très lent, certains résultats de recherche peuvent durer très longtemps. Dans tous les cas, la rapidité d'une seconde de Google ne sera jamais atteinte.

A cela on peut répondre que l'on peut dupliquer les index, mais à quel nombre ? Le système ne deviendrait que fiable à 99 % que lorsque le nombre de noeuds deviendrait très important (et le nombre de duplication également). Reste alors à implémenter des mécanismes permettant de gérer les duplications afin de lutter contre les problemes de pannes ou lenteur de noeuds.

Pour conclure sur cette dernière remarque, je dirai que tous les experts en GRID s'accordent sur une chose : là où il faut éviter les Desktop Grid (on peut les appeler des Peer to peer grid si l'on veut) c'est bien lorsqu'une fiabilité en vitesse réseau est demandée... La seule issue possible est un GRID de machine puissante, et dans ce cas là, nous nous retrouvons purement et simplement avec une architecture typiquement à la Google.

Salutations.

Christophe Noel
Information Retrieval & Grid Systems
CETIC
Charleroi, Belgique