Obsah
Současný návrh systému RAINBOW počítá s tím, že se zdrojové webové stránky předzpracují do podoby znalostní báze. Systém tedy bude funkční pouze pro omezenou část webových stránek, které budou předem zpracovány. V této části práce se proto podíváme na způsoby, jakými lze z Internetu stahovat kolekce webových stránek pro další zpracování. Nejprve stručně zhodnotíme jednotlivé přístupy k tomuto problému a poté se seznámíme s implementací vlastního stahovacího robota použitého v projektu RAINBOW.
Ještě než můžeme ze stránek získávat nějaké informace a ukládat je do znalostní báze, musíme někde stránky získat. Dnes se pro tuto činnost běžně používají weboví roboti,[8] což jsou programy, které stáhnou zadanou webovou stránku a uloží ji. Kromě toho stejným způsobem zpracují i všechny stránky, na které z původní stránky vedly odkazy. Tímto způsobem lze po určité době získat podstatnou část webových stránek. Většina robotů samozřejmě stahuje stránky jen z omezeného počtu serverů – např. pro účely českých vyhledávacích serverů roboti obvykle stahují jen dokumenty z národní domény .cz. Pokud naopak chceme získat co nejvíce stránek, můžeme z WHOIS serverů obsahujících zaregistrované domény získat seznam potencionálnách webových serverů a pokusit se je všechny zpracovat.
Pro projekt RAINBOW webového robota samozřejmě potřebujeme. Stáli jsme proto před rozhodnutím, jakého robota použít. Při rozhodování byla nejdůležitější především následující dvě kritéria:
uložené stránky musí být snadno přístupné pro další aplikace;
proces stahování by měl jít ovlivnit – např. by mělo být možné upravovat seznam povolených a zakázaných domén, měla by být podporována různá česká kódování apod.
Pro samotné uložení stahovaných stránek se nabízejí tři možnosti:
uložení do souborů na disku tak, že každé stránce odpovídá jeden soubor;
uložení do relační databáze tak, že každé stránce odpovídá jeden záznam;
uložení do vlastního formátu, kde bude více stránek v jednom fyzickém souboru.
Výčet není samozřejmě kompletní. Pro ukládání bychom mohli využít i některou z nativních XML databází nebo dokumenty dekomponovat na úroveň elementů a ty ukládat jako jednotlivé záznamy do relační databáze. Dekompozice na elementy pro naší aplikaci však nepřináší žádnou výhodu, spíše naopak, protože většina dokumentů pracuje s dokumentem jako s celkem. Nativní XML databáze jsou zatím v počátku svého vývoje.
Stahování stránek do souborů je implementačně nejjednodušší, protože lze využít již existující programy (např. WGET [44] nebo w3mir [43]). Stahování stránek do souborů má však i následující nevýhody:
většina operačních systémů má limit pro počet souborů na disku, který se pohybuje obvykle v řádu desítek až stovek tisíc;
nad procesem stahování nemáme kontrolu, takže nemůžeme snadno detekovat duplicitní dokumenty, sjednotit kódování dokumetů apod.;
procesem stahování na disk jsou změněny odkazy, kdy některé vedou k dalším stránkám na disku a některé stále odkazují na Internet – sestavení orientovaného grafu znázorňujícího odkazy mezi stránkami je obtížné, ne-li nemožné;
pro další zpracování a využití ostatními moduly není uložení do souborů moc šikovné.
Ukládání stránek do relační databáze si vynutí napsání vlastního robota (nebo úpravu stávajícího) určeného pro stahování stránek. To však není zas tak obtížný úkol. Získáme tím navíc plnou kontrolu nad celým procesem stahování stránek. Můžeme pak detekovat například duplicitní stránky, sjednotit kódování dokumentů apod.
Samotné využití relační databáze přinese následující výhody:
do relační databáze lze velice snadno přistupovat z téměř libovolného jazyka, nebude proto problém využívat získaná data v dalších analytických modulech;[9]
databázové servery obvykle ukládají všechna data do jednoho souboru, proto nejsme limitováni počtem souborů (webových stránek);
k databázovému serveru lze přistupovat i vzdáleně pomocí TCP/IP – není problém celý systém rozložit na několik počítačů.
Na druhou stranu existují limity pro maximální velikost souboru (obvykle okolo 2 GB) a některé starší databázové servery obvykle neumějí rozdělit jednu tabulku nebo databázi do více souborů.
Nevýhodou databázového serveru je, že používané datové struktury a přístupové algoritmy nejsou plně optimalizovány pro naši úlohu. Kdybychom napsali vlastní specializovanou jednoúčelovou databázi, mohli bychom dosáhnout vyšší efektivity. Náročnost této úlohy, nutnost implementovat síťový přístup apod. nás myslím opravňují použít již existující databázový systém, který možná bude o pár procent pomalejší a paměťově náročnější, ale ušetří nám spoustu práce. Zvláště pokud celý systém RAINBOW chápeme jako prototypovou implementaci.
Rozhodneme-li se pro uložení stažených stránek do databáze, musíme se shodnout na datovém modelu, který se pro ukládání stránek bude používat.
Ačkoliv by se na první pohled mohlo zdát, že si pro ukládání stránek vystačíme s jednou tabulkou, opak je pravdou. Není neobvyklé, že jedna stránka se na Webu objevuje v několika exemplářích s různými URL adresami.[10] To je pro nás sama o sobě důležitá informace a navíc nám to umožní ušetřit místo potřebné pro uložení dat. Informace o stažených stránkách proto uložíme do dvou tabulek Page a URL se vzájemným vztahem 1:N (viz obrázek 6.1).
Tabulka 6.1. Struktura tabulky Page
| Název atributu | Typ | Popis |
|---|---|---|
| id | int, automaticky zvětšovaný | Identifikátor stránky, slouží jako umělý primární klíč tabulky |
| md5 | char(32) | Výtah zprávy používaný při kontrole změny obsahu stránky a hledání kopií jedné stránky |
| md5dia | char(32) | Výtah zprávy bez diakritiky používaný při kontrole změny obsahu stránky a hledání kopií jedné stránky |
| type | varchar(128) | MIME typ stránky (např. text/html, text/plain) |
| data | longvarchar/clob | Samotný obsah stránky |
| modified | timestamp | Datum a čas poslední modifikace záznamu tj. stránky |
Tabulka 6.2. Struktura tabulky URL
| Název atributu | Typ | Popis |
|---|---|---|
| url | varchar(1024) | URL zdroje, primární klíč tabulky |
| page_id | int | Identifikátor stránky, kterou dané URL obsahuje |
| fetched | datetime | Datum a čas prvního stažení URL |
| checked | datetime | Datum a čas poslední kontroly URL |
| expires | datetime | Datum a čas vypršení platnosti zdroje |
| status | int | Poslední HTTP stavový kód získaný při čtení URL |
Některé moduly mohou potřebovat i informaci o odkazech mezi dokumenty. Struktura odkazů není nic jiného než orientovaný graf. Ten lze v relačním modelu zachytit například jako seznam uspořádaných dvojic zdrojového a cílového uzlu.
Tabulka 6.3. Struktura tabulky Link pro ukládání odkazů mezi stránkami
| Název atributu | Typ | Popis |
|---|---|---|
| source | int | Identifikátor zdrojové stránky |
| target | int | Identifikátor cílové stránky |
Primární klíč je v tabulce Link přitom tvořen oběma dvěma atributy. Tato struktura umožňuje velice jednoduše zjistit přímého předka a následníka každé stránky. Pro hledání nepřímých vazeb (přes více stránek) však jazyk SQL, který se používá pro dotazování v tabulkách, nenabízí vhodné prostředky.
[8] Někdy též známí pod angl. názvem spider nebo crawler.
[9] Později při implementaci RAINBOW jsme se rozhodli jít cestou webových služeb a přístup ke stránkám je zprostředkován samostatnou službou, která ostatní moduly od skutečného úložiště stránek odstíní.
[10] Do této skupiny patří i verze stránky v různých kódováních, které jsou dostupné na drobně odlišných URL adresách.