w celu imitowania zwykłych odsyłaczy (np. znaki / oraz miały większe praw-dopodobieństwo). Czas generowania linku nie miał wpływu na wykonany pomiar opóźnienia.
Rysunek 2.2: Średnie opóźnienie [s] dodania jednego linku podczas dodawania 3 mln odsyłaczy do repozytoriów adresów.
Dla każdych 100 000 adresów, które zostały dodane do bazy wyznaczono śred-nie opóźśred-nieśred-nie bazy na dodaśred-nie jednego adresu. Zebrane wyniki zostały przedsta-wione na rysunku 2.2. Na osi X oznaczono ilość linków w bazie, na osi Y ozna-czono wartość będącą średnim opóźnieniem dodania jednego linku. Jak widać rozwiązanie DB Berkeley charakteryzuje się dużą odpornością na wolumen prze-chowywanych adresów (nie wpływa ona w wykonanym badaniu na opóźnienie), występują jedynie sporadyczne zwiększające się opóźnienia wynikające najpraw-dopodobniej z metod synchronizacji I/O zastosowanych w tej bazie. Rozwiązanie oparte na bazie danych wykazuje liniowy trend wzrostu opóźnienia w zależności od wolumenu.
2.6 Definicja zadania crawlingowego i rozwiązywanie
kon-fliktów
W zależności od celu crawlingu budowa wewnętrzna systemu crawlingowego może mieć różną granularność. W przypadku indeksacji treści na potrzeby bu-dowy wyszukiwarki internetowej system crawlingowy utrzymuje spójny globalny system repozytorium linków URL, w którym zapewnia rozwiązywanie konfliktów
- czyli taką synchronizację pracy crawlerów, w której roboty nie wykonują pracy w sposób redundantny.
W przypadku query driven crawlingu, na którym bazowane są opisywane w tej pracy eksperymenty wprowadzić można dodatkowy podział procesu crawlin-gowego na zadania crawligowe.
Zadanie crawlingowe w query driven crawlingu jest to proces pobierania i prze-twarzania treści z Internetu, zdeterminowany poprzez wyspecyfikowaną funkcję oceny treści, strategię doboru i priorytetyzacji odsyłaczy URL oraz adresy starto-we.
Zgodnie z podaną definicją każde zadanie powiązane jest z aparatem oceny treści co oznacza, że dla każdego tematu dla którego konstruuje się crawling two-rzy się niezależne repozytorium adresów z własną priorytetyazją i przestrzenią adresową. Rozwiązywanie konfliktów crawlingu polegające na synchronizacji pra-cy crawlerów odbywa się wobec tego na poziomie zadania crawlingowego, ponie-waż problem ten rozwiązywany jest w repozytorium linków, które jak już zostało wspomniane, jest niezależne wobec każdego zadania.
Rozdział 3
Eksperymenty z użyciem metod
klasycznych doboru linków
Przyjęta metodyka przeprowadzenia eksperymentów zakłada wykorzystanie crawlingu opisywanego w literaturze jako „query driven crawling”. Ten rodzaj crawlingu służy do przeglądania wycinka sieci w kontekście poszukiwania ściśle określonych dokumentów zawierających treści interesujące z punktu widzenia te-matu wyszukiwania. Query driven crawling realizuje więc zadanie typu Document Retrieval w oparciu o sieć Internet jako korpus na którym przeprowadzone jest wyszukanie. W celu przeprowadzenia oceny porównawczej analizowana będzie metryka zbieżności tematycznej.
Dokumenty HTML, których crawler poszukuje, wyznacza się z puli wszyst-kich dokumentów HTML znajdujących się w wycinku sieci za pomocą funkcji oceny. Cho et al. [12] opisuje wiele metryk, które mogą posłużyć do budowy funkcji oceny, natomiast w opisywanej metodyce ze względu na charakter badań przyjęto metrykę „Similarity to a Driving Query”. Przyjmując notację za [12] me-tryka ta zakłada, że dla wzorca Q i dokumentu P funkcja I(P, Q) określa stopień podobieństwa pomiędzy wzorcem i dokumentem. Problem oceny podobieństwa tekstu jest tematem dobrze rozpoznanym w literaturze dotyczącym Information Retrieval (IR) [57] i stosowanym szeroko w środowisku WWW [71]. W opisywa-nej metodyce przyjęto metrykę w charakterze oceny semantyczopisywa-nej wykorzystującą odrębnie dwa aparaty semantyczne: metody słów kluczowych opisywanych w roz-dziale 4.3 oraz metody ekstraktora skryptów opisanego w rozroz-dziale 4.4. Ocena ta w pierwszym przypadku ma charakter logiczny („tak” / „nie”), a w drugim lo-giczny z uwzględnieniem miary stopnia dopasowania do wzorca wyrażonego liczbą naturalną (to znaczy ocena składa się z decyzji czy nastąpiło dopasowanie oraz z wagi liczbowej oznaczającej szczegółowość dopasowania).
Należy mieć na uwadze fakt, że crawler aż do zakończenia procesu crawlin-29
gowego nie jest świadomy globalnego zbioru wszystkich adresów, ani ostatecznej topologii odsyłaczy. Działa on na zasadzie rozpoczęcia przeglądania dokumen-tów HTML począwszy od linku startowego, odkrywając kolejne adresy kolejno ze stron, które odwiedza. Oznacza to, że w każdej chwili crawler dysponuje jedynie zbiorem stron, które już zostały przez niego odwiedzone oraz dysponuje uporząd-kowaną listą adresów (podzbiór wszystkich adresów w przeglądanym wycinku), które należy odwiedzić. Ma to wpływ na sposób oceny wyników, ponieważ przy-padek idealnego crawlera, który wśród N stron ma znaleźć k stron interesujących wcale nie oznacza, iż minimalnie potrzebuje on k odwiedzeń linków, ponieważ jest to możliwe wtedy i tylko wtedy gdy strona początkowa znajduje się w zbiorze stron interesujących i zawiera w sobie odsyłacze do wszystkich pozostałych k− 1 stron interesujących – co będzie przypadkiem niezwykle rzadkim i specyficznym. Sposób wyznaczania porządku listy adresów do odwiedzenia nazywany jest w tej pracy strategią doboru linków. Jest ona kluczowa dla efektywności „query driven crawlera” i stanowi główny obiekt eksperymentów.
We wszystkich prezentowanych w tym rozdziale wykresach na osi OX ozna-czono liczbę dokumentów, które zostały przetworzone z puli wszystkich odsy-łaczy, natomiast na osi OY oznaczono odpowiadającą im procentową wartość odwiedzonych stron interesujących w stosunku do puli wszystkich interesujących dokumentów. Interpretując wykres graficznie, krzywe biegnące od strony lewej do prawej, które są mocno rosnące na samym początku przedziału osi OX opty-malnie do osiągnięcia wartości 100% na jak najkrótszym odcinku wzdłuż osi OX oznaczają metody o wysokiej jakości. Odwrotnie, krzywe będące słabo monoto-niczne na początku przebiegu, rosnące gwałtowanie pod koniec przedziału OX interpretuje się jako metody o niskiej jakości.
3.1 Architektura systemu crawlingowego
W opracowanym w ramach badań systemie crawlingowym o nazwie Picus spośród przedstawionych w rozdziale 2.4 modeli przyjęto architekturę scentrali-zowaną typu klient – serwer. Wybór taki stanowił kompromis pomiędzy łatwością implementacji oraz możliwościami skalowania rozwiązania.
Przedstawiona na rysunku 3.1 architektura rozwiązania składa się z dwóch głównych części. Pierwszy element stanowi system crawlingowy Picus, który moż-na przystosować do pracy z różnorodnymi rozwiązaniami wymagającymi przeglą-dania treści z Internetu. Drugą część stanowi moduł odpowiadający za wykorzy-stanie aparatu semantycznego w celu ewaluacji treści znajdowanych przez system crawlingowy.
Picus składa się z centralnego serwera crawlingowego, odpowiedzialnego za synchronizację i kontrolę pracy klientów. Do zadań serwera należy między inny-mi rozdział zadań crawlingowych, utrzymanie dedykowanych repozytoriów linków
31
Internet
Crawler Serwer
DB zadań crawlingowych
System crawlingowy Picus
Moduł ekstrakcji informacji semantycznej
Kolejka Kolejka Ekstraktor skrypów CD Ekstraktor skrypów CD Ekstraktor skrypów CD Korpus Korpus Korpus Crawler Klient Crawler Klient Crawler Klient Repozytorium linków zadania crawlingowego Repozytorium linków zadania crawlingowego Repozytorium linków zadania crawlingowego
Rysunek 3.1: Architektura systemu crawlingowego.
dla zadań crawlingowych, zarządzanie procesem doboru linków oraz ich priory-tetyzacji między zadaniami crawlingowymi. Do zadań klientów należy fizyczna realizacja procesu pobierania treści z adresów pobranych z serwera, raportowanie statusu realizacji pobierania, oraz dalsze dysponowanie treścią.
System został zaprojektowany w sposób asynchroniczny, tzn. nieblokujący działanie klienta crawlera ze względu na opóźnienie wynikające z przetwarza-niem treści. Klienci przekazują pobrane treści do bufora będącego kolejką. W kolejnym kroku odpowiednie procesy ekstraktorów skryptów CD pobierają z ko-lejki teksty poddając je ocenie semantycznej. Teksty z dołączonymi informacjami nagłówkowymi trafiają do następnej kolejki skąd mogą zostać zapisane w kor-pusie. Dodatkowo wynik ewaluacji semantycznej trafia także do repozytorium linków w celu przeliczenia wag linków interesujących.
Taka architektura systemu pozwala na dużą swobodę w rozwijaniu architek-tury przy zapewnieniu skalowalności. W przypadku wydłużenia lub skrócenia średniego czasu przetwarzania strony przez ekstraktor skryptów CD możliwe jest odpowiednie dostosowanie liczby procesów obsługujących crawling.