La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Efficient and Simple Encodings for the web graph Auteurs : Jean-Loup Guillaume, Matthieu Latapy et Laurent Viennot. Présenté par RUYAGA Evrard Professeur.

Présentations similaires


Présentation au sujet: "Efficient and Simple Encodings for the web graph Auteurs : Jean-Loup Guillaume, Matthieu Latapy et Laurent Viennot. Présenté par RUYAGA Evrard Professeur."— Transcription de la présentation:

1 Efficient and Simple Encodings for the web graph Auteurs : Jean-Loup Guillaume, Matthieu Latapy et Laurent Viennot. Présenté par RUYAGA Evrard Professeur ROLIM José, Assistant BOUGET Mathieu Université de Genève Cours Algo-Web.

2 Résumé Larticle propose un ensemble de méthodes basées sur des outils simples, libres : Pour stocker et manipuler un large ensemble dURLs et une grande partie du web graphe; Afin de gérer les calculs avec des données placées dans la mémoire centrale efficacement. Objectif :- Stocker la liste dURLs et le graphe. Conversion "URLs" "idenficateurs dURLs" soit la plus vite possible. Obtention de tous les successeurs dun URL dune manière efficace.

3 Plan Introduction Codage dURLs Codage du graphe Conclusion

4 1.Introduction Comprendre la structure du graphe est essentiel pour beaucoup dapplication récentes (Recherche dinformation, web crawling optimisé,..etc.). La première étape pour étudier le web graphe sera dêtre capable de le stocker et de le manipuler efficacement en termes de temps et despace. Lélément clé de lencodage est dassocier un identificateur unique à chaque URL ce qui nous permettra ensuite de pouvoir encoder le graphe.

5 1.Introduction (suite) A titre indicatif, stocker lurl nécessite 70 byte en sachant que en moyenne chaque nœud possède 7 nœuds enfants. Donc si nous voulons stocker 1 million de nœud dun sous graphe : 100 Mb Pour bien étudier le graphe web, le nombre de nœuds qui doivent être pris en considération peut atteindre des centaines de millions.

6 1.Introduction (suite) Ainsi lefficacité de lencodage dun graphe devient donc un élément crucial. Le challenge sera de trouver le bon équilibre entre lespace et le temps nécessaire pour lencodage. NB : Les expériences ont été faites sur un compaq, 800 Mhz, pentium 3, 1 GB de mémoire sous système dexploitation linux kernel.

7 2.Codage dURLs Soit un ensemble donné dURLs on aimerait : affecter un identificateur unique (un entier) à chaque URL; et fournir une fonction permettant le mapping entre "identificateurs" et "URLs". Une idée simple serait de trier lensemble contenant les URLs dune manière lexicographique Ainsi lidentificateur assigné à un URL correspondrait au rang de l URL dans lensemble. Nous allons maintenant montrer que le choix dune telle méthode permet dobtenir un encodage efficace.

8 2. Codage dURLs (suite) Premièrement notons que le fait juste de trier lensemble permet une auto compression des données (dû à la redondance des données) on passe de 7.27 à 5.55 bytes de moyenne pour un URL après larrangement. Sûrement en utilisant cette méthode, le temps de recherche ne sera pas efficace; puisque quand on convertit "identificateurs" en "URLs" et inversement, on est obligé de décompresser tout le fichier. Nous utiliserons la gzip function pour la compression (car elle donne une compression rapide, facile à utiliser et une expansion de routines)

9 2. Codage dURLs (suite) 2.1 Encoding by gzipped blocks Pour éviter le besoin de décompresser le fichier (contenant la liste d URLs) en entier, on procède ainsi : On décompose le fichier en blocks qui seront ensuite compressés indépendamment. LURL contenu au début de chaque block ainsi que son identificateur seront sauvegardés De cette manière on gagnera beaucoup plus de temps en décompressant un seul block lors de la réaliser du mapping. Expérimentalement la moyenne de compression dun URL naugmente pas tant que la taille des blocks tourne autour de 1000 URLs (~ 5.62 bytes/URL). Avec des blocks de 100 URLs, la moyenne augmente à 6.43 bytes.

10 2. Codage dURLs (suite) 2.1 Encoding by gzipped blocks La conversion "URL" "identificateur" se procède ainsi : trouver le block qui contient lURL à convertir : La recherche du block se fait par une recherche dichotomique en se basant sur les URLs se trouvant au début de chaque block (soit en décompressant la 1ère de chaque block, soit parce que on a gardé une liste de ces URLs ; ce qui a le même coût). décompresser le block trouver lidentificateur de lURL dans le block (décompressé) : En effectuant une recherche linéaire dans la liste (recherche inévitable puisque les URLs ont des longueurs différentes).

11 2. Codage dURLs (suite) 2.1 Encoding by gzipped blocks Réciproquement, la conversion "identificateurs" "URLs" se procède ainsi : trouver le block qui contient lidentificateur à convertir : Comme les blocks contiennent le même nombre dURLs, le numero du block est donné par décompresser le block trouver l URL dans le block (décompressé) : La ligne de l URL égal à On utilise encore une recherche linéaire.

12 2. Codage dURLs (suite) 2.1 Encoding by gzipped blocks Complexité du mapping N.B : Vu la complexité obtenue à la troisième étape, il est important que la taille dun block soit assez petite. Cependant cela peut être amélioré en utilisant une longueur fixe pour tous les URLs dans chaque block. Ce qui va être présenté dans le point suivant

13 2. Codage dURLs (suite) 2.1 longueur dURLS fixe Pour améliorer le temps de consultation : on rajoute à chaque URL contenu dans un block un nombre de caractères spéciaux de tel sort que sa longueur (la longueur de lURL) soit la même que celle du plus long URL contenu dans le block. Dans chaque block, la longueur fixée est celle du plus long URL contenu dans le block. (Position URL = ).

14 2. Codage dURLs (suite) 2.1 longueur dURLS fixe Ainsi, on obtient le tableau suivant (amélioration effectuée à létape 3) :

15 2. Codage dURLs (suite) 2.1 longueur dURLS fixe Notons que loptimisation doit être bien appliqué pour assurer une bonne compression des URLs (un bon taux de compression) et une expansion rapide (temps de consultation à létape deux). Compression En effet si les blocks sont petits, le taux de compression sera naturellement petit ; par contre si les blocks sont grands, il est fort probable de trouver un très long URL par rapport aux autres et donc être obligé de rajouter beaucoup de caractères inutiles ce qui augmentera la taille moyenne des URLs. Temps de consultation Le temps de consultation dépend la plupart des fois de la longueur du block, ainsi lon doit avoir la plus petite taille possible pour permettre un bon mapping.

16 2. Codage dURLs (suite) 2.1 longueur dURLS fixe Le résultat de ces phénomènes est représenté ci- dessous :

17 2. Codage dURLs (suite) En conclusion on obtient un codage de 6.54 bytes en moyenne pour un URL, avec une conversion entre "URLs" et "identificateurs" de 2ms (dans les deux directions) en utilisant seulement des méthodes simples, libres et largement disponibles (sort et gzip). Cet encodage associe donc à chaque URL sa position dans lensemble arrangé lexico graphiquement, et nous avons montré comment le mapping pouvait être fait de manière efficace. Nous allons maintenant montrer comment cet encodage peut être utilisé dans la représentation dune grande partie du Web graphe.

18 3. Codage du graphe Un lien est défini par un couple dentiers, entier qui représente lidentificateur dun URL. Le graphe est ainsi enregistré dans un fichier tel que la ligne numéro k contient tous les identificateurs des URLs sur lesquels le sommet k pointe. Et on obtient une compression suivante : (avec bzip) 0.8 bytes de moyenne pour un lien ; (avec gzip instead of bzip) 0.83 bytes de moyenne pour un lien. Ces valeurs sont considérées comme bornes inférieures pour lespace réservée à un lien.

19 3. Codage du graphe (suite) Dans cette partie on va proposer deux méthodes pour encoder les liens dun Web graphe. Lune des deux méthodes est une simple expansion de la méthode gzipped block method utilisée précédemment qui donne un bon taux de compression. Pour améliorer le temps daccès aux successeurs dun sommet (ce qui est important pour pouvoir effectuer des statistiques et exécuter des algorithmes sur le graphe) nous proposerons une seconde méthode à cet effet, tout en gardant un taux de compression élevé. Remarque:Noter que la technique proposée peut être utilisée dans lautre sens (c'est-à-dire étant un URL donner tous les URLs qui contiennent un lien vers cet URL).

20 3. Codage du graphe (suite) 3.1 Encoding by gzipped blocks On utilise la même méthode que dans la partie précédente le fichier est subdivisé en block et on compresse chaque block séparément. Recherche des successeurs dun sommet décompresser le block contenant le sommet on recherche les successeurs du sommet, on a deux méthodes : Les listes de successeurs dans le block ont une longueur variable, on effectue une recherche linéaire. Les listes de successeurs dans le block ont une longueur fixée, la liste est directement trouvée. Dans les 2 cas comme la majeure partie du temps est employé dans le temps de consultation, il y a aucune différence entre trouver un seul successeur du sommet et trouver la liste entière des successeurs.

21 3. Codage du graphe (suite) 3.1 Encoding by gzipped blocks Cependant, la majeure partie des opérations faites sur les graphes concerne lexploration des successeurs et prédécesseurs des sommets. Dans ce cas, le temps de consultation des successeurs devient un paramètre crucial, et la méthode de compression des blocks devrait être améliorée en ce point. Nous allons maintenant montrer une autre méthode qui utilise la forte propriété du Web graphe, la localité, pour améliorer le temps de consultation.

22 3. Codage du graphe (suite) 3.2 localité Le grand taux de compression obtenu par lencodage du graphe en utilisant gzip peut être expliqué par la forte propriété des liens du graphe. Définissons : la distance entre deux URLs : comme la différence de leur identificateur la longueur dun lien entre deux URLs : comme la distance entre ces deux URLs. Maintenant, prenons en considération la distribution de ces distances. Cette distribution suit la loi de puissance suivante : La probabilité que la distance entre deux sommets soit égale à "i" est proportionnel à "i^-τ". Dans notre cas lexposant "τ" est égal à 1.16 voir la figure 3.

23 3. Codage du graphe (suite) 3.2 localité

24 On utilise cette localité (pour améliorer le taux de compression ainsi que le temps daccès) en encodant le graphe dans le fichier de la manière suivante : la k-ième ligne contient les successeurs de lURL k et ces successeurs sont encodés par leur distance à k. on peut ensuite utiliser la même technique dencodage que celle présentée précédemment. En essayant cette méthode, on obtient un faible taux de compression que celui de la méthode précédente. Cependant, cet encodage peut être utilisé pour accroître le temps de consultation sans trop endommager le taux de compression, comme nous allons le montrer dans la section suivante.

25 3. Codage du graphe (suite) 3.2 amélioration du temps daccès Nos expériences ont montré que 68% des URLs qui ont des liens entre eux étaient à une distance entre -255 et 255. On appelle ces liens des shorts liens. Ces liens peuvent être codé sur un byte plus un bit pour le signe. Dailleurs on a besoin dun bit de plus pour différencier les shorts liens des longs liens (les longs liens sont encodés sur 3 bytes, puisque nous avons considéré 8 millions de sommets pour le graphe). Cet arrangement permet un encodage de 1.89 bytes en moyenne pour un lien.

26 3. Codage du graphe (suite) 3.2 amélioration du temps daccès Pour aller plus loin, on peut distinguer : shorts (68% des liens, chacun encodé sur un byte) ; medium (26,75% des liens, chacun encodé sur deux bytes) ; long (5,25% des liens, chacun encodé sur trois bytes). Nous utilisons alors un bit pour chaque lien afin de distinguer le signe de la distance et un préfix pour savoir quel type de lien on a (0 for short, 10 for medium, 11 for long). De cette manière un lien peut être sauvegardé en utilisant en moyenne 1.66 bytes. En utilisant cette méthode, et en la restreignant juste aux shorts liens. On obtenait de cette manière une amélioration dun bit en moyenne, ce qui nous amenait 1.54 bytes par lien.

27 3. Codage du graphe (suite) 3.2 amélioration du temps daccès Les résultats sont illustrés dans le tableau ci-dessous.

28 3. Codage du graphe (suite) 3.2 amélioration du temps daccès

29 4. Conclusion Nous avons décrit dans cet article une méthode simple et efficace pour encoder un grand ensemble dURLs et une grande partie du Web graphe. Nous avons donné une manière de calculer la position dun URL dans une liste dURLs triées et inversement, ce qui permet la manipulation de grandes données stockées dans la RAM pour éviter les accès au disque dur. Notre gzipped blocks method de sauvegarder 400 millions dURLs et 4.6 billions de liens entre eux (entre URLs) dans 8 GB despace mémoire.

30 4. Conclusion (suite) Nous pouvons améliorer le temps daccès des liens à 20microsecondes en utilisant la seconde méthode proposée, mais en augmentant lespace requit. Nous avons donc obtenu des résultats comparables aux meilleurs de résultats connus dans la littérature, en utilisant des méthodes simples, efficaces et largement disponibles comme sort, gzip et bzip.


Télécharger ppt "Efficient and Simple Encodings for the web graph Auteurs : Jean-Loup Guillaume, Matthieu Latapy et Laurent Viennot. Présenté par RUYAGA Evrard Professeur."

Présentations similaires


Annonces Google