Retrouvez motrech sur son nouveau site http://motre.ch/

18 janv. 2006

J2J2 Le Pire Tout Pire

Ce billet, tout comme un de mes récents billets consacré au crawling est une tentative pour briser certaines idées reçues sur les moteurs de recherhe. Commence donc une série "Brisons les idées reçues des futurs créateurs de moteurs de recherche":
  • Penser que le crawling est un problème simple (ici).
  • Penser que le Peer-To-Peer (P2P) est LA solution miracle (ce billet)
  • Penser que la scalabilité est JUSTE une affaire de ressources (à venir)
  • ...

Nous avons assisté à un buzz marketing presque digne de Google ces derniers temps concernant le nouveau service PeerFactor.
Malgré toutes ces informations très enthousiastes mais généralement sans réelle analyse technique je vais essayer de vous convaincre définitivement de l'inutilité du modèle Peer-To-Peer (P2) dans le cadre d'un moteur de recherche.
J'ai souvent été sollicité à ce sujet pour Frutch (encore récemment sur la liste motrech). J'ai donc déjà plusieurs fois répondu aux questions de faisabilité d'un moteur de recherche en P2P, dont ici aux côtés de l'exxxccccelllllent Olivier Ertzscheid. Mais une mise au point définitive (?) s'impose.

L'idée paraît tout d'abord séduisante: Répartir la charge de crawling et d'indexation d'un moteur de recherche sur les ordinateurs des internautes volontaires (genre SETI@Home). C'est ce que nous propose PeerFactor.
Ainsi, s'il me venait l'idée insensée de créer un moteur de recherche (tiens, je l'appellerais bien Frutch), je pourrais alors comme cela est décrit par exemple ici, demander à PeerFactor d'utiliser les ressources informatiques des internautes inscrits à son programme pour crawler Internet et me renvoyer des données de "pré-crawling" du Web (entendez par données "pré-crawlées" des pages web). Cool, une partie du travail en moins à faire. Je ne vais pas avoir besoin de dépenser d'argent pour la bande passante pour crawler l'ensemble du Web, les membres de PeerFactor vont le faire pour moi. Cela représente des économies substantielles pour la mise en place de mon moteur de recherche.

Deuxième étape, il faut donc maintenant que je récupère les données "pré-crawlées" par les Gentils Membres de PeerFactor (GMPF). Allez, c'est parti... Heu... mais au fait, si les GMPF ont chacun de leur côté "pré-crawlé" un total de 10 Gigas de pages web et que je désire les indexer (c'est mieux pour un moteur de recherche), il faut donc que je télécharge ces 10 Gigas de données... Vous voyez où je veux en venir?
Si j'avais effectué moi même le crawling, j'aurais consommé 10 Gigas de ma bande passante. Si je veux récupérer les données "pré-crawlées" par les GMPF je devrais consommer 10 Gigas de bande passante... Où est le gain?
A ma petite échelle individuelle le gain est de 0. Mais à l'échelle d'Internet, c'est encore pire, puisque la perte est de 20 Gigas. En effet, les 10 Gigas d'informations ont circulé trois fois: 1 fois entre les différents serveurs Web crawlés et les GMPF, une autre fois entre les GMPF et PeerFactor et finalement une dernière fois entre PeerFactor et moi...

De plus, quel contrôle ai-je sur le crawler de PeerFactor? Comme puis-je lui spécifier les URLs à suivre et ceux à ne pas suivre? Est-ce que PeerFactor respecte les principes d'exclusion des Robots? Comment puis-je lui injecter de nouveaux URLs à crawler? Quelles règles de politesse applique-t-il vis à vis des serveurs crawlés? Comment gère t-il la minimalisation des doublons crawlés? Bref, beaucoup de questions, et très peu de réponses sur le site de PeerFactor.

Ainsi, dans le cadre d'un moteur de recherche généraliste, je ne vois AUCUN intérêt à PeerFactor (ou à toute autre technologie P2P qui fait du "pré-crawling").

Nous pourrions en revanche pousser un peu plus loin le principe du P2P appliqué aux moteurs de recherche: que chaque noeud du réseau P2P effectue le crawl ET l'indexation. Ainsi il ne transiterait vers le moteur de recherche que l'index. Cela reste l'option la plus envisageable. Elle ne peut cependant pas être une solution généraliste de partage de ressource comme l'est PeerFactor. Mais de nombreux problèmes se posent alors: tout le code est déporté vers les noeuds P2P : crawling, parsing multi-format, indexation. Il faut donc installer un logiciel plus lourd sur les noeuds P2P et être en mesure de synchroniser tous ces noeuds: synchronisation pour ne pas faire le même traitement plusieurs fois pour le même document, synchronisation en cas de changement de configuration, synchronisation en cas de changement du code d'indexation, ... Bref, nous tombons dans les problèmes des solutions multi-agents.

Enfin, il y a la solution du moteur de recherche entièrement P2P. Chaque noeud du réseau devient à la fois backend (crawling, parsing, indexation, ...) mais également front-end (il répond à des requêtes sur son index local). Ainsi lorsque vous soumettez un requête, tous les noeuds les plus proches de vous recherchent dans leur index local, renvoient les résultats sur votre machine, qui au final a la responsabilité de fusionner et dédoublonner les résultats des différents noeuds avant de vous les présenter.
On imagine facilement que dans une telle architecture des compromis entre le temps de réponse à une requête et l'exhaustivité de la recherche s'imposent.

"Un moteur de recherche généraliste en P2P? NON!"

Là où un moteur de recherche P2P a toute sa raison d'être, c'est dans les moteurs de recherche sociaux. Il me semble même incroyable que tous les outils sociaux que nous rencontrons aujourd'hui soient tous sur un modèle centralisé. Dans un moteur de recherche social, votre réseau P2P ne serait pas un réseau physique (le noeuds les plus proches ou qui répondent le mieux), mais un réseau social: Le maillage de votre réseau P2P serait celui de vos "contacts" : ainsi lorsque vous naviguez sur le Web, l'agent P2P installé sur votre poste (ou dans votre navigateur) indexe les pages que vous visitez. Un index de vos centres d'intérêts est ainsi constitué en local sur votre ordinateur. Il en va de même chez vos "contacts". Lorsque vous effectuez une recherche, votre moteur de recherche P2P va alors se connecter à tous vos "contacts" et lancer une recherche sur chacun de leurs index et vous fournir une réponse non plus par rapport à un index généraliste (comme Google), mais par rapport à tous les petits index de vos "contacts". Bref, l'idée d'effectuer des recherches dans les fonds documentaires de votre réseau social n'est pas neuve, mais elle me semble par essence même être un processus P2P.

(Note: je n'ai rien contre PeerFactor. Je trouve même ce service très prometteur, mais si les créateurs de PeerFactor visent les futurs créateurs de moteurs de recherche je pense qu'ils ont fait une grosse erreur).


TAGS : , , ,


2 commentaires:

SdC a dit…

Merci Jérôme pour cette analyse technique, c'est exactement ce que j'attendais de votre part en postant sur la liste.
J'espère que vous ne m'en voudrez pas trop :)

Anonyme a dit…

Entièrement d'accord avec cette analyse, j'ajouterais un autre point qui me semble ultra critique dans la fonction de "crawling déporté". Que se passe-t-il si le gentil utilisateur du client P2P Pearfactor n'est pas "gentil" ? Rien de plus simple pour un spammeur de se créer un proxy qui change à la volée les pages crawlées par le client P2P. Il pourrait par exemple changer les liens Microsoft ou Google par un autre lien. Les possibilités sont infinies et il me semble quasi impossible d'éliminer ce problème. Le croisemement des résultats de plusieurs utilisateurs n'est pas envisageable dans ce contexte car les pages sont pour la plupart dynamiques rapidement (ex: blog).

Enregistrer un commentaire