Crawlers Parallèles Présentation faite par: Mélanie AMPRIMO étudiante en Master en Sciences Informatique Basée sur l'article Parallel Crawler de Mr Junghoo Cho (Université de Californie) et de Mr Hector Garcia-Molina(Université de Stanford)
Situation Augmentation de la Taille du Web: Une solution: Augmentation des pages redondantes Difficultés de trouver toutes les pages en un temps respectables. Une solution: Les crawlers simples Les crawlers parallèles
Plan Introduction I. Architecture des crawlers parallèles II. Modes des crawlers pour un assignement statique II.1 Minimisation de l'échange d'URL II.2 Fonction de partition III. Modèle d'évaluation IV.Exemple d'évaluation IV.1 Base de données IV.2 Différents Modes Conclusion
Introduction: problèmes soulevés par les crawlers Pas que la parallélisation: combien de fois visiter une page, sans l'inonder? quelle page enregistrer pour pas remplir notre espace mémoire et avoir la meilleure collection possible? Mais enjeux plus intéressants surtout très peu traité et peu d'écrits.
Introduction Peu de modèles, donc questions essentielles: chevauchement: Comment peut-on coordonner les processus pour éviter le chevauchement? qualité: Comment peut-on être sûr de la qualité des crawlers parallèles / crawler centralisé? longueur de la bande passante de communication: De quoi ont-ils besoin pour communiquer et comment ces frais généraux seraient-ils significatifs? Peut-on réduire au minimum ces frais généraux tout en maintenant l'efficacité des crawlers?
Introduction Avantages: Supporter la charge Répartition en zones géographiques du réseau de téléchargement Réduction du réseau de téléchargement Toutes les pages doivent être transférées à un endroit centralisé: transfert<trafic de téléchargement initial compression :compresser la base différence avec l'image précédente synthèse: index central-> bases simplifiées
I.Architecture des crawlers parallèles plusieurs crawling processes : C-proc, équivalent chacun à un single crawler
I.Architecture des crawlers parallèles Problème: pages similaires Intra-site: crawlers sur le même réseau(Lan) le réseau de téléchargement est centralisé Distributed crawler: zone géographique distante séparation et réduction du téléchargement attention à la communication
I.Architecture des crawlers parallèles : Distributed Crawler Différentes façons de voir le problème de communication: crawlers indépendants: téléchargement des pages de manière individuelle assignement dynamique: Coordinateur central qui distribue les partitions aux différents crawlers, souvent parallélisé. assignement statique:le Web est déjà partitionné et les partitions sont attribuées avant le début du crawler
II.Fonctionnement du crawler pour un assignement statique 1 processus = 1 partition C1-S1 / C2-S2 mais on a certains liens d'inter-partition. (a,g),(c,g)... Comment gérer ces liens pour éviter la redondance?
II.Fonctionnement du crawler pour un assignement statique Mode FireWall liens inter-partitions ignorés =>ni surcharge, ni coordination Mode Cross-Over Mode exchange s'informe des liens sans telecharger les pages. minimise la redondance et maximise la sécurité
II.1 Minimisation de l'échange URL Batch Communication envoie d'un lot d'URLs après avoir collecté k pages à différents crawlers. purge en maitenant seulement la liste des liens dans le groupe courant. Replication: Distribution de Zipfian recherche des pages les plus populaires distribution entre les crawlers
II.2 Fonction de partitionnement URL-hash based: on assigne une page URL a un C-proc beaucoup de liens inter-partitions Site-hash based: on sélectionne le nom du site et attribue l'adresse à un C-proc -> diminution du nombre de lien inter-partitions Hierarchical: on sélectionne d'une manière hiérachique, par ex: nom de domaine ->diminution du nombre de lien inter-partitions, mais difficulté de faire des partitions équivalentes.
II.2 Fonction de partitionnement : résumé - Tableau représentant les points abordés dans le I puis le II.
III. Modèle d'évaluation Surcharge = N-I I Couverture= I N Qualité = |AnʌPn| |Pn| Surcharge de communication N: nombre de pages total télécharger par l'ensemble des crawlers I: nombre de pages uniques téléchargées An: ensemble des pages les plus importantes de l'image du web du crawler Pn: ensemble des pages les plus importantes du web = nombre de pages téléchargées nombre d'échanges d'URLs inter- partition
III. Modèle d'évaluation Les deux résultats: - Good: le mode est relativement performant dans ce domaine. - Bad : le mode n'est pas performant par rapport aux autres modes - Et sur des vraies bases de données?
IV. Exemples d'évaluation IV.1 Base de données 40 millions de pages Web issues de la base de Stanford URLs listés dans l'Open Directory dmoz.org = noyau du crawling = 1 million d'URLs bases petites mais peu cher résultats concluants
IV.2 Différents tests Mode Firewall et couverture Mode Cross-Over et Surcharge Mode Exchange et communication Qualité et Batch Communication
Mode Firewall et Couverture le mode Firewall limite la communication, mais aussi la couverture du réseau. Au départ: 5 URLs au hasard. => couverture diminue quand le nombre de processus augmente
Mode Firewall et Couverture La couverture dépend du nombre d'URLs du départ du crawler Conclusion: - Petit nombre d'URLs obligent un petit nombre de C-proc - le mode firewall n'est pas un bon choix
Mode Cross-Over et Surcharge Le mode cross-over augmente la couverture du réseau au dépend de la surcharge. La surcharge reste longtemps a 0 jusqu'à ce que la couverture atteigne un certain pourcentage Conclusion: Même si le mode Cross-Over est mieux qu'un mode indépendant, la surcharge devient vite très importante.
Mode Exchange et communication Nous avons divisés les 40 millions de pages par une méthode de hachage. - Le site Hash diminue la communication.
Qualité et Batch Communication l'importance des pages est noté par rapport aux nombres de liens allant sur cette page. La qualité dépend du nombre d'échanges d'URLs.
Qualité et Batch Communication La surcharge de communication ne croit pas linéarement avec le nombre d'URL échangés Les crawlers n'ont pas besoin de communiquer beaucoup pour avoir la qualité.
Conclusion crawlers parallèles de plus en plus utilisés Mais peu de choses connues En résumé: peu de processus de crawling -> mode firewall mode exchange-> peu de bande réseau batch communication-> maximise la qualité