Kompresja grafu webowego Szymon Grabowski

Kolejność odnośników bez znaczenia (tj. nie musi być zachowana). Graf webowy Graf webowy – zorientowany graf połączeń (bez etykiet) między stronami (dokumentami) www. G = (V, E), zbiór n = |V| wierzchołków oraz m = |E| krawędzi Wierzchołki – indywidualne dokumenty (zwykle HTML-owe). Krawędzie – odnośniki wychodzące. Kolejność odnośników bez znaczenia (tj. nie musi być zachowana). Zastosowania: szeregowanie dokumentów relewantnych (PageRank etc.), walka ze spamem webowym, analiza wspólnot internetowych, wykrywanie replikacji…

Dlaczego kompresja? W maju 2011 r. wyszukiwarka Google indeksowała ok. 32 mld stron webowych ( http://www.worldwidewebsize.com/ ) Naiwna reprezentacja: listy sąsiedztwa, założenie: ok. 20 odnośników na stronę, odnośniki na 8 bajtach (=64 bity): >5.1 TB. Alternatywa: indeksy 5-bajtowe  >3.2 TB. O wiele za dużo dla pamięci RAM! Cel kompresji: zmniejszyć znacznie zużycie pamięci przy zachowaniu szybkiego dostępu do list sąsiedztwa.

Założenia kompresji Cały graf w pamięci RAM. Interfejs podstawowy: Szybka obsługa zapytania forward_neighbors(x) dla dowolnego dokumentu x. Interfejs rozszerzony: Szybka obsługa zapytania reverse_neighbors(x), tj. zwrócenie listy dokumentów z odnośnikami do x. Obsługa zapytania isNeighbor(x, y) (szybsza niż trywialne wykorzystanie forward_neighbors(x)).

Stan wiedzy Randall i in. (2001): 5,55 bit / link (test na kolekcji 61 mld URLi z ok. 1 mld linków). Boldi i Vigna (2004): ok. 2,5–5,5 bit / link, ekstrakcja listy ok. 4 μs (C2Q 2,66 GHz). Claude i Navarro (2008): ponad 3 bit / link, b. dobry czas dostępu (ok. 2x szybciej niż w alg. B–V). Asano i in. (2008): ok. 2–3 bit / link, b. wolny swobodny dostęp (2–30 ms na C2D 2,4 GHz). Brisaboa i in. (2009): symetryczna struktura drzewiasta, obsługuje zapytania „w obie strony” (forward / reverse). Dobry kompromis między pamięcią a szybkością. Grabowski i Bieniecki (2011): łączenie list w blokach + zip, ok. 1,3–2,4 bit / link, ekstrakcja listy 6,5–10 μs (C2D 2,66 GHz)

Przykładowe dane testowe ( http://law.dsi.unimi.it/ )

Podstawowe przesłanki Dokumenty (strony) są ponumerowane. Są one posortowane wg serwerów, listy wychodzących linków posortowane  kodowanie różnicowe. Kolejne listy zwykle mają dużo wspólnego (np. wspólna struktura nawigacji w obrębie serwera)  redundancja. Podział na bloki: bezpośredni dostęp do co L-tego wiersza.

Algorytm Boldiego i Vigny (B & V, 2004) Każda lista zakodowana w odniesieniu do jednej (wskazanej) z poprzednich list. …Chyba że łańcuch referencji byłby zbyt długi (wtedy lista rozpoczynająca „łańcuch” jest kodowana samodzielnie). Flagi binarne informujące czy dany element z listy referencyjnej występuje na liście bieżącej. Pozostałe elementy na liście bieżącej (residua) kodowane różnicowo i kodem Eliasa.

Algorytm Re-Pair (Larsson & Moffat, 2000; Claude & Navarro, 2008) Założenia Dane dwie listy sąsiedztwa zwykle albo mają niewiele wspólnego, albo dzielą znaczną liczbę odsyłaczy (wychodzących) Podobne listy można efektywnie kompresować algorytmami słownikowymi (np. LZ78, RePair).

Re-Pair, przykład

Re-Pair dla grafu webowego, przykład Empty or non-empty list? Źródło: Claude & Navarro (2010), p. 11, www.dcc.uchile.cl/~gnavarro/ps/tweb10.pdf 11

Re-Pair, ulepszenia Transformata różnicowa: Rezultat: więcej par małych wartości  wyższa efektywność RePair. Transformata różnicowa w innych algorytmach: niższa entropia (przynajmniej rzędu zerowego)  bardziej efektywne kodowanie statystyczne (np. algorytmem Eliasa czy Huffmana).

Re-Pair, ulepszenia, c.d. Inny porządek odnośników na listach RePair: 7  (2, 3), 8  (5, 6). W rezultacie: RePair(Lista1) = 1, 7, 8 RePair(Lista2) = 7, 4, 8 Można lepiej: wykorzystać wspólną podlistę 2, 3, 5, 6. Rozwiązanie z [CN10]: po każdym przejściu RePair otrzymane listy są sortowane (w przykładzie: 1, 7, 8 i 4, 7, 8  para (7, 8) może być wykorzystana w następnym przejściu). Sortowanie jest tylko heurystyką! Problem jest trudny (Fink & Voss, 2003, Shieh et al., 2003, Buehrer & Chellapilla, 2008).

Prymitywy graficzne w macierzy binarnej (Asano et al., 2008) 6 rodzajów bloków złożonych z jedynek (prostokąt, przekątna, litera L…).

Odnośniki intra-host i inter-host (Asano et al., 2008) Standardowe listy sąsiedztwa (po prawej) Użycie indeksów lokalnych (host: add.com/) Mniejsze liczby  kompresja!

Przykładowe bloki 1024 x 1024 (EU-2004)

Przykładowe bloki 1024 x 1024 (EU-2004), c.d.

Drzewo k2 (Brisaboa et al., 2009) k = 2  każdy węzeł ma 0 lub k2 = 4 dzieci

Drzewo k2, nawigacja Drzewo reprezentowane jako dwie tablice: T (tree) i L (leaves). T = 1011 1101 0100 1000 1100 1000 0001 0101 1110 L = 0100 0011 0010 0010 1010 1000 0110 0010 0100 T[x] = 1  childi(x) na pozycji rank(T, x) * k2 + i , w T::L

Prosty algorytm 2D (Grabowski & Bieniecki, 2010) Skrajnie uproszczona wersja algorytmu bazującego na drzewie k2 (Brisaboa et al., 2009): zamiast wielu poziomów bloków (rozcinanych rekurencyjnie) wykorzystujemy tylko jeden poziom. Prezentacja na przykładzie zbioru EU-2005 (listy sąsiedztwa: 77 MB, przy reprezentacji naiwnej). Macierz binarna M (n = 862,664 węzłów) dzielona na bloki (kwadraty) o boku B = 1024. Flagi binarne (blok pusty / niepusty) zajmują łącznie 89 KB. Bloki niepuste, ułożone wierszami, otrzymują etykiety 1, 2, ..., będące offsetami do tablicy A[1..|A|] wskaźników do właściwej (skompresowanej) zawartości niepustych bloków.

Reprezentacja niepustych bloków Tablica A, ze wskaźnikami do skompresowanych bloków

Szybkie algorytmy dla grafu skompresowanego (Karande i in., 2009) Podstawowa technika: zastąpienie kliki dwudzielnej gwiazdą z węzłem wirtualnym. węzeł wirtualny Ta transformacja może być powtarzana wielokrotnie.

Przeszukiwanie grafu wszerz (BFS) w reprezentacji skompresowanej (Karande i in., 2009) 1. Wprowadź wagi dla krawędzi: 2. Wykonaj prawie standardowy algorytm BFS o złożoności O(|V| + |E|), zmiany są następujące: uwzględnij wagi, Q musi być kolejką dwustronną (deque).

Przeszukiwanie grafu wszerz (BFS) w reprezentacji skompresowanej, c.d. Wniosek: jeśli liczba tworzonych węzłów (wirtualnych) będzie mniejsza niż liczba usuwanych krawędzi, to BFS wykona się szybciej po kompresji. … + w(u, v) if v is virtual then ENQUEUE(Q, v, start) else ENQUEUE(Q, v, end)

Kompresja grafów sieci społecznościowych Przykłady grafów ( http://law.dsi.unimi.it/webdata/ ): hollywood-2009: graf nieskierowany aktorów, krawędź istnieje, jeśli dana para aktorów (węzłów) wystąpiła razem przynajmniej w jednym filmie, ljournal-2008: krawędź z x do y, jeśli y jest jednym z przyjaciół x, dblp-2010: krawędź istnieje, jeśli dana para naukowców ma co najmniej jeden wspólny artykuł.

Czym sieci społecznościowe różnią się od grafu webowego wyższa entropia niektóre sieci symetryczne (grafy nieskierowane) nawet jeśli graf skierowany, to dużo krawędzi dwukierunkowych (y jest na liście znajomych x i vice versa) Boldi i in., 2010 Kompresja w bpe w zależności od permutacji węzłów.

Problemy otwarte Jak scharakteryzować dany graf (np. pod kątem wyboru algorytmu / parametrów kompresji)? 2. Czy charakterystykę grafu można oszacować przy pomocy małej jego próby? 3. Algorytm RePair oferuje dobry kompromis pomiędzy stopniem kompresji a dostępem do skompresowanych danych; czy da się opracować jego wariant o dużo mniejszych kosztach budowy słownika? czy da się zwiększyć jego kompresję korzystając z wiedzy o danym grafie?