Embed Size (px)
Citation preview
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 MathieuUniversité de Genève 2005-2006Cours Algo-Web.
Résumé
L’article propose un ensemble de méthodes basées sur des outils simples, libres : Pour stocker et manipuler un large ensemble d’URLs
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 d’URLs et le graphe. Conversion "URLs" → "idenficateurs d’URLs" soit la
plus vite possible. Obtention de tous les successeurs d’un URL d’une
manière efficace.
Plan
Introduction Codage d’URLs Codage du graphe Conclusion
1.Introduction
Comprendre la structure du graphe est essentiel pour beaucoup d’application récentes (Recherche d’information, 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 d’espace.
L’élément clé de l’encodage est d’associer un identificateur unique à chaque URL ce qui nous permettra ensuite de pouvoir encoder le graphe.
1.Introduction (suite)
A titre indicatif, stocker l’url 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 d’un 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.
1.Introduction (suite)
Ainsi l’efficacité de l’encodage d’un graphe devient donc un élément crucial.
Le challenge sera de trouver le bon équilibre entre l’espace et le temps nécessaire pour l’encodage.
NB : Les expériences ont été faites sur un compaq, 800 Mhz, pentium 3, 1 GB de mémoire sous système d’exploitation linux 2.4.9 kernel.
2.Codage d’URLs
Soit un ensemble donné d’URLs 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 l’ensemble contenant les URLs d’une manière lexicographique
Ainsi l’identificateur assigné à un URL correspondrait au rang de l’ URL dans l’ensemble.
Nous allons maintenant montrer que le choix d’une telle méthode permet d’obtenir un encodage efficace.
2. Codage d’URLs (suite)
Premièrement notons que le fait juste de trier l’ensemble 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 l’arrangement.
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)
2. Codage d’URLs (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. L’URL 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 d’un URL n’augmente 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.
2. Codage d’URLs (suite)2.1 Encoding by gzipped blocks
La conversion "URL" → "identificateur" se procède ainsi : trouver le block qui contient l’URL à 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 l’identificateur de l’URL 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).
2. Codage d’URLs (suite)2.1 Encoding by gzipped blocks
Réciproquement, la conversion "identificateurs" → "URLs" se procède ainsi : trouver le block qui contient l’identificateur à
convertir : Comme les blocks contiennent le même nombre d’URLs, 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.
2. Codage d’URLs (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 d’un 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
2. Codage d’URLs (suite)2.1 longueur d’URLS 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 l’URL) 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 = ).
2. Codage d’URLs (suite)2.1 longueur d’URLS fixe
Ainsi, on obtient le tableau suivant (amélioration effectuée à l’étape 3) :
2. Codage d’URLs (suite)2.1 longueur d’URLS fixe
Notons que l’optimisation 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).
CompressionEn 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 consultationLe temps de consultation dépend la plupart des fois de la
longueur du block, ainsi l’on doit avoir la plus petite taille possible pour permettre un bon mapping.
2. Codage d’URLs (suite)2.1 longueur d’URLS fixe
Le résultat de ces phénomènes est représenté ci-dessous :
2. Codage d’URLs (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 l’ensemble 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 d’une grande partie du Web graphe.
3. Codage du graphe
Un lien est défini par un couple d’entiers, entier qui représente l’identificateur d’un 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 l’espace réservée à un lien.
3. Codage du graphe (suite)
Dans cette partie on va proposer deux méthodes pour encoder les liens d’un Web graphe.
L’une 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 d’accès aux successeurs d’un 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 l’autre sens (c'est-à-dire étant un URL donner tous les URLs qui contiennent un lien vers cet URL).
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 d’un 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.
3. Codage du graphe (suite)3.1 Encoding by gzipped blocks
Cependant, la majeure partie des opérations faites sur les graphes concerne l’exploration 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.
3. Codage du graphe (suite)3.2 localité
Le grand taux de compression obtenu par l’encodage 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 d’un 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 l’exposant "τ" est égal à 1.16 voir la figure 3.
3. Codage du graphe (suite)3.2 localité
3. Codage du graphe (suite)3.2 localité
On utilise cette localité (pour améliorer le taux de compression ainsi que le temps d’accès) en encodant le graphe dans le fichier de la manière suivante :
la k-ième ligne contient les successeurs de l’URL k et ces successeurs sont encodés par leur distance à k.
on peut ensuite utiliser la même technique d’encodage 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.
3. Codage du graphe (suite)3.2 amélioration du temps d’accè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.
D’ailleurs on a besoin d’un 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.
3. Codage du graphe (suite)3.2 amélioration du temps d’accè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 d’un bit en moyenne, ce qui nous amenait 1.54 bytes par lien.
3. Codage du graphe (suite)3.2 amélioration du temps d’accès
Les résultats sont illustrés dans le tableau ci-dessous.
3. Codage du graphe (suite)3.2 amélioration du temps d’accès
4. Conclusion
Nous avons décrit dans cet article une méthode simple et efficace pour encoder un grand ensemble d’URLs et une grande partie du Web graphe.
Nous avons donné une manière de calculer la position d’un URL dans une liste d’URLs 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 d’URLs et 4.6 billions de liens entre eux (entre URLs) dans 8 GB d’espace mémoire.
4. Conclusion (suite)
Nous pouvons améliorer le temps d’accès des liens à 20microsecondes en utilisant la seconde méthode proposée, mais en augmentant l’espace 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.
