�ݺ�ߣ

Editor's Notes

1. Fulltextove hledani z pohledu uzivatele vypada nasledovne - polozime dotaz - dostaneme odpoved vyhledaci engine je schopen behem zlomku vteriny najit mezi miliony dokumety ty spravne/relevatni ale co vsechno musi predchazet samotnemu hledani ?
2. fulltext vyhledavace jsou vpodstate vsechny stejny, nejdrive musi dokumety stahnout, nasledne je analyzuji a pripravuji hledaci databazi a teprve az ted je mozne rychle a relevatne odpovedt na dotaz. Drive nebyly dokumnety ulozeny, ale ted uz jsou ulozny
3. ulltext vyhledac muzem zjednodusene namalovat takto - robot - ktery stahuje dokumenty z internetu a uklada jej do kolekce dokumnetu - priprava - parsovani/indexace kdy dochazi k analyze dokumentu a priprave hledaci databaze, ktera je navrzena tak aby dokazala dat rychlou odpoved na dotaz - samotne hledani a prezentace vysledku
4. Je treba si uvedomit ze nemuzeme mit vsechno, vzdy budem mit stahnout jen cast dokumentu, je tedy treba vedet - JAK budem dokumenty stahovat, ktere nejdrive ? (ty kvalitni ? ) jak efektivne je stahovat (vyporadat se s duplicitama, nezatezovat web server kde dokumenty lezi, resit vlastnii konektivitu i konektivitu zdroje) - museme vedet KOLIK dokumentu budem chtit mit v ulozisti a tedy jak velke bude uloziste, dale musime zvazit KAM je ulozime, jak s dokumenty budeme dale pracovat... - a v neposledni rade, JAK CASTO budeme dokumenty obcerstvovat Hledání může být jen tak dobré, jak dobré máme dokumenty ...
5. Robot - SeznamBot  je postaven nad technologiema z projektu Hadoop. Pro ukladani dat pouzivame NoSQL uloziste HBase a frameworku pro distribuovane vypocty Map/Reduce. HBase je vyborne skalovatelna databaze postavena nad distribuovanym filesystemem (HDFS). A prave pomoci Map/Reduce uloh nad daty muzeme provadet ruzne analyzy/vypocty a tedy planovat jake dokumenty stahneme, obnovime, pripadne smazeme.
6. - dokumenty mame stazeny, ale primo v nich hledat nemuzeme, protoze bychom je museli postupne vsechy projit.... aby mohlo byt fulltextove hledani pouzitelne, musime predpripravit index - neco jako rejstrik v knizce. priklad - Doc 1 az 3, slova, a index podle slov.
7. mame uloziste kde nam robot drzi aktualni dokumenty. indexselect periodicky bezici vypocet nad daty, ktery oznackuje dokumenty ktere chceme indexovat (ne vse co robot stahne chceme mit ve hledaci databazi) indexfeeder takto vybrane dokumenty posila po davkach indexeru a jednotlive vystupni davky z indexeru se spoji do  indexu finalnim mergem. - kdyby byl index jeden pro vsechny dokumenty, tak by zabral cca 4T dat a hledani v nem by nebylo taky moc pohodlne, takze hledaci index mame rozdelen do nekolika mensich indexu, presneji na 115 svazku.  
8. indexfeeder je zodpovedny za distribuci dokumentu ke spravnemu indexeru. takze mam vznikne 115 hledacich DB - 115 indexu
9. - doc - seznam dokumentu ve svazku a informace o nich (tady jsou ranky) - word  - pro kazde slovo je zde seznam dokumenu z doc barrelu a pozice slova - tittle - predzpracovane texty dokumentu, ktere se vy zobrazeni vysledku pouzivaji pro generovani "snipetu" - tj. fragment textu ktery obsahuje hledanou frazi - a indexu mame vice, protoze vygenerovani celeho indexu je casove narocne, pocitame jej jednou za par tydnu, tak je treba zajistit aby byl index aktualni, a proto k nemu generujeme kazdy den  denni aktualizaci - neco jako inkrementalni "zaplatu" - a pak jeste specialni "fresh" index, ktery zajistuje pristu rychle se menicich dokumentu jeste rychleji nez jednnou denne
10. na pocatku mame polozeny dotaz v hledacim formulari, kdychom polozeny dotaz 1:1 zahledali v indexu, tak bychom sice nasli prislusna dokumenty, ale vysledek by nebyl vubec dobry. - Je tedy treba dotaz analyzovat, pokusit zjistit co vlasne uzivatel chtel najit, nenechat se zmast chejicima carkama a hackame, preklepy, jinym slovnim tvarem atd... - Z pripravy indexu vime, ze index je tvoren z 115 svazku, a takze dotaz na posleme na vsechny indexy, pozbirame vysledku a ty podle informacich v nich obsazenych seradime, - Ted jiz mame nachystanu prvni destiku nalezenych dokumentu, a musime k nim vygenrovat titlky. pripadne se rozhodnout pro vhodny nahledovy obrazek.
11. metasearch provaci analyzu a upravy dotazu - zde je jadro porozumneni dotazu a jeho dobre interpretace search agregator se stara do distribuci dotazu na vsechny basesearch a nasledne pozbirani odpovedi a po vybrani prvnich 10 se jeste oslovi titulkovace pro vygerovani vhodneho fragmentu textu ke kazdemu vysledku.
12. Zpracování dotazu je základní součástí vyhledávače, které podstatnou měrou ovlivňuje relevanci výsledků. Provádí se s každým dotazem na vyhledávání a je tedy treba jej provest hodnekrat za vterinu.K základním úlohám zpracování dotazu patří oháčkování a doplnění skloňovaných tvarů slov. Kromě těchto operací se v dotazu provádí detekce čísel a jejich typů (desetinné číslo, datum, apod.), vygenerování podobných slov, desambiguace, detekce zkratek a mnoho dalších činností, kterým se tato komponenta hledání věnuje. ~                                                    
13. Blog zde mame dotaz uzivatele, a vidime jeho predzpravanou podobu, resp. jeho reprezentaci v podobe stromu dotazu.
14. predzpracovny dotaz, je poslan na kazdy hledaci svazek, kde jsou vyhledany prislusne dokument, a odpovedi jsou postupne posilany zpet, slucovany a trideny, a ziskame finalni seznam odpovedi
15. Viz blog - snippety snippet ma za ucel poskytnou uzivateli predstavu o obsahu stranky a ovlivnuje uzvatelksky zazitek. snazime se na malem prostoru zobrazit co nejvice informaci, proto zobrazujeme snimek obrazovky a uryvek
16. ukazat - nasel se jiny tvar slova, je videt ze je ohackovany atd.... a fragment textu a nesmime zapominat i dalsi komponenty jako screenshot releated searche, pripradnou opravu preklepu a atd.