Vyhledávání Google

Pro dosažení co nejrychlejší odezvy jsou formáty uložených dat optimalizovány tak, aby byly přístupy na disk co nejřidší (v dnešním počítači je disk zdaleka nejpomalejší částí – přečtení informace trvá okolo 10ms, což je řádově milionkrát pomalejší než přístup do paměti).

Repository obsahuje úplný HTML kód každé zaindexované webové stránky. Stránky jsou uloženy zkomprimované pomocí knihovny zlib (přestože nabízí horší kompresní poměr než bzip, byla upřednostněna pro svou rychlost) jedna za druhou, přičemž před každou je uloženo její docID, délka a URL. K přístupu k repository nejsou nutná žádná další data, takže v případě potřeby je možné z jeho kopie rekonstruovat všechny ostatní struktury.

V indexu dokumentů (document index) jsou uloženy informace o každém dokumentu (stránce). Používá strukturu ISAM (Indexed Sequential Access Method), v níž jsou všechny záznamy pevné délky uloženy sekvenčně za sebou, přičemž hashovací tabulky pro urychlení přístupu podle docID jsem uloženy mimo hlavní data.

Každá položka obsahuje aktuální stav dokumentu, ukazatel do repository, kontrolní součet souboru a různé statistiky. Pokud byl dokument rozparsován, je v položce také odkaz do souboru docinfo, v němž je zaneseno URL dokumentu a jeho titulek. V opačném případě odkazuje do URLlistu, který obsahuje pouze URL. Motivací tohoto řešení byla kompaktnost datové struktury a schopnost načíst záznam v jednom přístupu na disk.

Také existuje soubor pro převod URL na docID – setříděný seznam hashů URL a odpovídajících docID. Pro převod se spočítá hash URL a v tabulce se vyhledá příslušné docID. Pomocí slévaní je možné najít docID pro více URL najednou; tuto techniku používá URLresolver.

Slovník je implementován jako sekvenční seznam slov oddělených nulami a hašovací tabulkou s ukazateli do ní. U prototypu vyhledávače slovník obsahoval 14 miliónů slov a vešel se do 256 MB operační paměti (což je klíčové pro jeho rychlou použitelnost). Slovník je zdrojem problémů při paralelizaci indexování – při běžném provozu musí být indexery schopny přidávat do slovníku nová slova. Tento problém byl vyřešen jeho zafixováním: nálezy nových slov se zapisují do zvláštního souboru, který na konci zpracuje poslední indexer. Vzhledem k velikosti slovníku je tento dodatečný soubor relativně malý, a jeho zpracování tudíž nezabere mnoho času.

Seznamy hitů obsahují údaje o výskytu slov v dokumentech, a to včetně informací o pozici, velikosti písma a kapitalizaci. Protože tvoří většinu obsahu indexu i zpětného indexu, je důležité je ukládat co možná nejefektivněji; Google pro uložení hitu používá dva bajty. Hity se rozlišují na obyčejné a důležité, přičemž do důležitých se počítají slova obsažená v URL, titulku, textu a odkazů a v meta tazích.

Ve vlastních indexech se před seznam hitů ukládá jeho délka. Aby se dále ušetřilo místo, je délka zkombinovaná s wordID (resp. docID ve zpětném indexu), čímž pro délku zbývá 8, resp. 5 bitů. Pokud je hitů více, obsahuje pole pro délku escape kód, a samotná délka je uložena v následující dvou bajtech. Index se rozdělen do skupiny kontejnerů (barrels; prototyp používá 64), přičemž každý kontejner pokrývá určitou část wordID – index je už tedy částečně setříděn. Pokud dokument obsahuje slova, jejichž wordID spadají do daného kontejneru, je do kontejneru přidáno jeho docID, následované příslušnými wordID a jejich hitlistu. To sice vyžaduje o něco více prostoru kvůli duplikovaným docID, ale zato významně zjednodušuje náročnost úkolu pro třídič(e). Současně umožňuje místo celých wordID (které mají 32 bitů) ukládat jen rozdíl od minimálního wordID v rozsahu – tím pádem pro wordID stačí jen 24 bitů a 8 je možno použít pro počet hitů.

Zpětný index se skládá ze stejných kontejnerů jako index normální; kontejnery jsou jen přetříděny podle wordID. Pro každé platné wordID je pak do slovníku doplněn odkaz do kontejneru s odpovídajícím seznamem dokumentů, které slovo obsahují. Důležitou otázkou je, v jakém pořadí uváděn docID v tomto seznamu. Jednoduchým řešením je řadit je dle docID – to umožňovalo snadné slučování seznamů při zpracování víceslovných dotazů. Další možností je řadit je dle PageRanku dokumentů. Potom jsou odpovědi na jednoslovné dotazy trivialitou a je pravděpodobné, že i nejlepší odpovědi na dotazy víceslovné budou blízko začátku. Google používá kompromisní řešení: má dvě sady kontejnerů: “krátká” obsahuje pouze hity v titulcích a odkazech, “dlouhá” je úplná. Při prohledávání se potom nejprve prověří první sada, a teprve při příliš malém počtu nalezených výsledků se zkoumá druhá.

Ohodnocování výsledků dotazů nezahrnuje pouze PageRank, ale i pozici hledaného slova v dokumentu. Hodnocení v Google byla navrženo tak, aby žádný jednotlivý faktor nemohl mít příliš velký vliv na výsledek.

Je-li vyhodnocován jednoslovný dotaz, zkoumá se seznam hitů pro dané slovo. Google má u každého hitu uložen i jeho druh (titulek, text odkazu, URL, obyčejný text velkým písmem, obyčejný text malým písmem, …); každému druhu je pak přiřazena určitá váha. Na tyto váhy lze nahlížet jako na vektor. Stejně tak je ohodnocen počet hitů pro každý druh – ohodnocení na začátku roste lineárně s počtem, ale pak se závislost “narovnává”, takže pokud počet výskytů překročí určitou mez, ohodnocení dále neroste.

Skalární součin vektoru vah a vektoru ohodnocení počtu výskytů tvoří ohodnocení relevance dokumentu, jehož kombinace s PageRankem určí konečné pořadí dokumentu ve výsledku.

Pro víceslovné dotazy je situace komplikovanější – musí se procházet několik seznamů hitů najednou, aby bylo možné ohodnocovat výsledky na základě vzdálenosti jednotlivých výskytů. Pro každou nalezenou skupinu hitů je spočítána vzdálenost výskytu všech nalezených slov v textu dokumentu (nebo odkazu), které je přiřazeno jedno z deseti ohodnocení. Počty výskytů se potom nepočítají jen pro různé druhy hitů, ale i pro každou dvojici druh-vzdálenost. Oba tyto údaje jsou převedeny na příslušná ohodnocení, a jejich skalární součin tvoří ohodnocení relevance dokumentu.

Do vyhledaváného výrazu je možné zadat operátory:

• uvozovky – vyhledání přesného výrazu
• OR – logické NEBO,
• AND – logické A,
• minus, NOT – výraz, který se ve vyhledaném dokumentu nesmí nacházet,
• hvězdička – náhradní výraz za různá slova mezi zadanými slovy,
• závorky – určují prioritu při zpracování výrazů s AND a OR,
• dvě tečky – definují interval.[2]

Popularita Google umožnila jeho zakladatelům založit inzertní systém Google AdWords a Google AdSense. AdWords je v podstatě administrátorské rozhraní, které umožňuje inzerentům, kteří mají u Google založený účet a na něm vloženy finanční prostředky, vytvořit inzerát, který se pak bude zobrazovat u fulltextových výsledků označený jako sponsored listings. Tento malý inzerát je svázán pevnými pravidly – má limitovaný rozsah a i jeho obsah je omezen. Inzerenti si pro každý inzerát stanoví i tzv. keywords, čili klíčová slova, po jejichž zadání do vyhledávače Google nebo některé z jeho přidružených stránek, se zobrazí právě onen inzerát. Inzerent platí Google částku, kterou si sám stanoví (min. částku stanoví Google), za každé kliknutí na jeho inzerát. Pořadí inzerátů je stanoveno systémem na základě kombinace několika faktorů – ceny za klik (cost per click) a míry prokliků (click through rate).

Po příchodu do datacentra je HTTP požadavek přesměrován hardwarovým load-balancerem (prvkem vyrovnávajícím zátěž) na jeden z webových serverů (Google Web Server – GWS). Webserver pak koordinuje zpracování dotazu a formátuje výsledek do HTML odpovědi, kterou na závěr posílá uživateli.

První fází zpracování dotazu je vyhledání odpovídajících dokumentů ve zpětném indexu. Princip je v zásadě stejný jako u prototypu, jediným rozdílem je velikost zpětného indexu. Aby bylo dosaženo adekvátní rychlosti, je zpětný index rozdělen na větší počet fragmentů (shards), přičemž každý pokrývá náhodně vybranou podmnožinu dokumentů. Požadavky na každý fragment obsluhuje více počítačů (jejich sada se označuje jako pool). Při zpracování požadavku na nějaké slovo pak load balancer pošle dotaz jednomu stroji pro každý fragment. Ten vyřídí svou část úkolu, a spojené odpovědi dají celkový výsledek pro celý index v čase, který zabere prohledání jednoho fragmentu.

Pokud jeden z počítačů selže, load balancer na něj přestane směrovat dotazy a další prvky obsluhující cluster se jej pokusí oživit, případně jej nahradí jiným strojem. V průběhu poruchy je kapacita systému snížena úměrně podílu celkové kapacity, který počítač představoval.

Výsledkem prohledávání je setříděný seznam docID. Další fází zpracování je přiřadit ke každému docID URL, titulek a úryvek textu relevantní k dotazu. K tomu slouží dokumentové servery (docservers), které najdou příslušný záznam v repository a získají z něj potřebné informace. Rychlost odezvy je řešena stejným způsobem jako u vyhledávání v indexu: repository je rozdělen na více fragmentů, každý z nich obsluhuje pool serverů a požadavky jsou distribuovány load balancerem. Jakmile úryvky a další informace z docserverů dorazí, vyřazují se z výsledků duplicity a provádí se klastrování podle doménového jména.

Kvůli replikaci nutné pro zajištění dostupnosti a rychlosti odezvy tak Google v clusterech dokumentových serverů přechovává několik kopií celého webu.

Zároveň s těmito hlavními aktivitami ještě webserver získává další informace, jako jsou návrhy na možné opravy pravopisu (například při zadání dotazu „Csech Republic“ se kromě výsledků hledání uživateli zobrazí také otázka, zda náhodou neměl na mysli „Czech Republic“) a reklamy cílené na klíčová slova zadaná uživatelem. To vše je následně sloučeno do HTML stránky, která je odeslána zpět uživateli.