Au départ, il y a une idée fort simple : les sites web devraient être capables de signaler par eux-mêmes leurs changements auprès des différents moteurs de recherche. J’ai déjà effleuré le sujet dans un précédent billet, les moteurs de recherche ont aujourd’hui une approche totalement inverse qui consiste à scanner le web (crawling) à longueur de temps en quête de la moindre modification. Cela ne vous paraît-il pas un peu imbécile ? Imaginez le nombre de pages web à visiter, imaginez le coût si on souhaite que la fréquence entre chaque visite soit la plus faible possible. Aujourd’hui, ce n’est pas moins de 450 000 machines qui seraient en service chez Google, certes elles ne servent pas toutes au crawling mais cela nous permet d’appréhender un petit peu l’ampleur de la tâche (à ce propos, si quelqu’un à une idée de la part du crawling dans le coût global d’un moteur de recherche, je suis preneur). Du coup il semble difficile, voire impossible, d’envisager la création de nouveaux moteurs aujourd’hui. Pourtant, l’avènement du web sémantique devrait entraîner leur multiplication, d’une façon verticale, les moteurs de recherche se spécialisant dans des domaines de plus en plus précis.
Le crawling semble être la partie “ennuyeuse” dans les moteurs de recherche et si ces derniers doivent se différencier les uns des autres, ça ne se fera certainement pas de côté là, l’innovation devrait plutôt se trouver dans le domaine de l’indexation, du ranking, etc. Mais peut-on imaginer que des moteurs de recherche tels que Google ou Yahoo s’entendent un jour pour mutualiser leur crawling ? Aussi surprenant que cela puisse paraître, je crois que oui.
Mais avant d’aller plus loin, il faut bien comprendre de quoi on parle. Finalement, le crawling consiste à réaliser une sorte de “sauvegarde du web”. D’une manière ou d’une autre, les moteurs de recherche généralistes ont besoin de posseder une copie intégrale du web pour fonctionner efficacement. Il leur faut donc scanner et rescanner le web à longueur de temps afin d’obtenir la copie la plus fraîche possible. Pire, le problème est le même pour les moteurs verticaux, même si leur domaine de prédilection se limite à quelques sujets précis, ils doivent tout de même scruter l’intégralité du web car l’information qui les intéresse peut être cachée n’importe où. Du moins, c’est l’approche actuelle.
Comment peut-on améliorer les choses ? Tout d’abord, j’en suis de plus en plus convaincu, il faut inverser le processus. Ce n’est pas aux moteurs de recherche d’interroger les sites web, c’est aux sites de contacter les moteurs pour les informer des différents changements. Aujourd’hui, un développeur web doit mettre en place un fichier robot.txt (voire un Sitemaps) pour assurer le meilleur référencement possible. Demain, il ajoutera un mécanisme permettant d’informer les moteurs de recherche de tous les changements survenant dans sa base de données. Pour les sites modernes s’appuyant sur le paradigme MVC, ça ne devrait pas être un souci, il suffira d’ajouter un “plugin” au niveau du modèle. En gros, ce plugin sera chargé de contacter les moteurs de recherche afin de signaler l’ensemble des opérations de type “Create”, “Update” ou “Delete”. Enfin, cette inversion de processus devrait permettre la création de moteurs de recherche en temps réel. Imaginez, vous rentrez vos critères de recherche et vous voyez les résultats arriver au fur et à mesure que le web évolue !
Mais au fait, si les sites doivent contacter d’eux-mêmes les moteurs de recherche, lesquels vont-ils choisir ? Vont-ils se limiter à certains ? Bien évidement non, les sites devraient pouvoir propager leurs modifications vers un maximum de moteurs, des plus importants aux plus spécialisés, sans même avoir besoin de les connaître à priori. Comment cela peut-il fonctionner ? J’imagine des sortes de relais permettant de diffuser le “flux des modifications” le plus largement possible. Appelons ça des “datahubs” si vous voulez bien (en français on pourrait traduire cela par “concentrateurs de données”). Les datahubs seront reliés les uns aux autres d’une manière totalement décentralisée et si un site web envoie une information sur un datahub donné, la totalité des autres datahubs recevront cette même information, par un jeu de cascade consécutive. Autrement dit, si je veux créer mon propre datahub, il suffira que je me connecte quelque part, à un autre datahub, pour recevoir automatiquement l’intégralité des changements susceptible de survenir n’importe où sur le web. Et de son côté, mon datahub pourra à son tour propager les données qu’il reçoit vers d’autres datahubs. Bien entendu, mon datahub devra disposer d’un tuyau suffisamment important pour faire transiter toute cette masse d’informations.
Il faudrait pouvoir quantifier la bande passante nécessaire pour transférer en temps réel toutes les modifications du web, mais je crois qu’on peut raisonnablement estimer qu’elle ne sera pas très élevée. En fait, je crois qu’elle devrait même être assez faible, et si je devais me risquer à avancer un chiffre très approximatif, je dirais que 1 Gbps devrait être suffisant si on se limite aux données textuelles. Aujourd’hui, on trouve des hébergeurs capables de fournir ce débit pour moins de 100 euros par mois. Essayez donc d’imaginer le coût total occasionné par le crawling permanent de Google, Yahoo et MSN (pour ne citer que les plus gros) comparé aux quelques centaines d’euros nécessaires pour realiser la même chose avec l’idée des datahubs !
Bien sûr, le crawling n’est pas tout me direz-vous, si on souhaite réaliser un véritable moteur de recherche il faudra stocker une masse importante d’informations afin de réaliser un certain nombre d’opérations : parsing, indexation, ranking, etc. Par conséquent, si on entreprend la réalisation d’un nouveau moteur généraliste, il faudra quand même prévoir une infrastructure conséquente. En revanche, et c’est ici que les datahubs deviennent véritablement passionnants, il sera facile et très peu coûteux de réaliser des moteurs de recherche verticaux, spécialisés sur quelques domaines choisis. D’ailleurs, une fonctionnalité importante des datahubs devrait permettre précisément cela, un datahub pourra déclarer les types de données qu’il souhaite recevoir et propager.
Finalement, l’intérêt des datahubs m’apparaît comme une évidence et j’ai peine à imaginer l’ensemble des applications possibles tellement le potentiel semble important. Mais cette idée est pour moi-même assez nouvelle, je débute tout à fait et je connais très peu l’état de la recherche dans le domaine, n’y a-t-il pas des gens qui travaillent déjà là-dessus ? Vos réactions sont les bienvenues.
13 Commentaires
Salut, j’ai lu ton commentaire chez Thierry et je suis venu jeter un oeil par ici.
Ton idée ressemble en gros à ce qui se passe sur un pc avec la technique dite de l’interruption ( clavier, souris, disques…), la limite de cette technique est le nombre d’interruptions à gérer, j’ai un doute sur la bande passante de 1 Gbps, sachant qu’il faudrait sûrement plusieurs copies de web, pour que les mises à jour puissent se faire.
À vrai dire j’ai avancé ce chiffre de 1 Gbps au pifomètre. J’ai essayé de regarder comment les gens utilisaient le web, et si on y pense, il n’y a pas beaucoup de nouvelles données (publiques) qui sont ajoutées/modifiées au cours du temps. 1 Gbps c’est déjà beaucoup non ?
J’ai pris un exemple grossier et purement technique, prenons un point de vue politique et philosophique :
Gougle contrôle un minimum les données ( à base de filtres j’imagine ), quelle serait l’”éthique” de ce moteur de recherche dont tu parles ?
Si je prends le point de vue du pénible:
Je veux nuire ce moteur de recherche, comment protéger ton moteur, serait-il plus fragile qu’un truc centralisé comme gougle ?
Le principe que j’ai exposé vise à remplacer le crawling uniquement, c’est un élément important mais un moteur de recherche c’est bien plus que ça. Je crois que le crawling en lui-même peut être totalement neutre et je ne pense pas qu’il y ait du filtrage à faire de ce côté là. En revanche, les moteurs de recherche s’appuyant sur ce crawling pourront en faire ce qu’ils veulent, s’ils souhaitent placer des filtres pour masquer certains sites, libres à eux de le faire.
vive la technologie
J’aime beaucoup ce genre de philosophie sur la hi-tech, les nouveaux et les réseaux, car ça pourrait donner des idées pour sortir (temporairement j’entend) du web “google-centré”…
Idée très intéressante !
Si je résume, il s’agirait d’une sorte de flux RSS, mais lu directement par des moteurs de recherches, et non par des utilisateurs.
Ce concept existe déjà en partie avec les flux RSS : certains agrégateurs de flux RSS en ligne permettent de faire une recherche sur ces flux RSS.
La grosse différence, je suppose, serait d’une part de ne pas se ‘limiter’ à des flux RSS, et aussi de le faire de manière active (c’est à dire que les sites envoient l’information comme quoi ils sont mis à jour, contrairement aux flux RSS qui doivent être lu pour qu’on soit informé de nouvelles modifications).
Reste à mettre en place un protocole pour ce type de service.. et à imaginer le tout.
Merci Piwaï pour ton commentaire, on peut en effet voir ça comme des flux RSS “à l’envers”, fonctionnant en mode “push” et non “pull”.
À ma connaissance Google a déjà plus de 1 million de serveur… les sitemaps font exactement ça. Elles listent ce qui changent et ce que le moteur doit manger.
Manuel au boulot… suffit le créer ce service… un annuaire de sitemap… pas difficile, je vais convertir bonWeb (s’il réaparaît dans Google :-))
Bah non, les sitesmaps sont juste une sorte de robot.txt amélioré, il ne s’agit pas d’une inversion des processus. C’est toujours Google qui fetch les pages quand il peut, alors que dans le cas des datahubs, c’est les sites qui reportent eux-mêmes les modifications à tous les moteurs et cela en temps réel. Ça change pas mal de choses.
Je suis d’accord mais lire régulièrement un sitemap ça pompe pas des tonnes de ressources. Déployer une solution de push c’est plus compliqué.
Faut agir… c’est ce que je fais avec coZop… c’est sur ce point que je te trouve trop en retrait… tu as les compérences, le temps… aller aller on se bouge.
Ça va venir, ne soit pas inquiet, il y a un vrai projet derrière tout ça, je dois juste aller jusqu’au bout de ma réflexion. J’ai passé en revue les grands aspects du web mais il me reste un dernier point à aborder, les navigateurs qui devraient finalement s’appeler des communicateurs. Tout est dans ma tête mais contrairement à toi je suis nullisime dès qu’il s’agit d’écrire.
Merci pour le lien, c’est bien quelque chose comme cela que j’imaginais sans pouvoir pour autant le formaliser.
Je ne sais pas bien comment fonctionne les moteurs de recherche des logiciels de P2P, mais il y a bien à la base une liste de serveur qui font office d’agrégateur des fichiers publiés par les machines qui se connectent au réseau P2P avec un système permettant de savoir en temps réel ce qui est disponible et sur quelle machine le trouver.
Ici les serveurs du réseau P2P sont tes datahubs et les PC des internautes des sites Web.
2 Trackbacks/Pingbacks
[...] This is a translation of the article “Les datahubs” originally written in French, feel free to improve it by sending your [...]
[...] ou dans des myriades de “datastores” indépendants ? C’est ici que les datahubs entrent en scène ! Pour réaliser un moteur de recherche ou un YouTube, il suffira de mettre en [...]
Laisser un commentaire