Recomendados
Mais conteúdo relacionado
Destaque
Destaque (14)
Semelhante a Fulltextový vyhledávač
Semelhante a Fulltextový vyhledávač (20)
Mais de seznamVyvojari
Fulltextový vyhledávač
- 2. Fulltextové hledání v internetu
- 3. Fulltextové hledání v internetu
- 4. Fulltextové hledání v internetu
- 5. Jak pracuje fulltextové hledání • Stahování dokumentů z internetu • Uložení dokumentů do úložiště • Analýza a tvorba hledací databáze • Hledání a prezentace výsledků
- 6. Jak pracuje fulltextové hledání ? WWW INDEX DOKUMENTY
- 7. Získání a uložení dokumentů • Jak efektivně stahovat dokumenty? • Kolik dokumentů chceme mít? • Kam je uložíme? • Jak často je budeme obnovovat?
- 8. Získání a uložení dokumentů PLÁNOVAČ WWW DOWNLOADER DOKUMENTY ANALÝZA
- 9. SeznamBot • datové úložiště přes více jak 130 strojů • obsahuje cca 700M dokumentů • celkem 500TB dat • denně stáhne cca 50M dokumentů • datový tok stahování v řádech GBit/s
- 10. Tvorba hledací databáze - indexace • co je indexace? • fulltext index (invertovaný soubor) vstup: Doc1: "a b c", Doc2: "b c", Doc3: "a“ index: "a" - { Doc1,Doc3 } "b" - { Doc2 } "c" - { Doc2 }
- 11. Indexace FEEDER DOKUMENTY INDEXER MERGE INDEX
- 12. Indexace 115x FEEDER DOKUMENTY INDEXER INDEXER MERGE MERGE INDEX INDEX
- 13. Indexy pod lupou • Složení indexu – seznam dokumentů a jejich atributy – seznam dokumentů pro každé slovo – extrakt textu dokumentů pro úryvky • Druhy indexů – complete – daily – fresh
- 14. Indexace v číslech • index je rozdělen na 115 svazků • každý svazek má 36GB nebo 14GB velký index • celkem více jak 4TB dat • index sestavuje více jak 100 strojů
- 15. Hledání a prezentace výsledků • zpracování uživatelského dotazu • distribuované hledání • prezentace výsledků
- 16. Hledání a prezentace výsledků ? Příprava dotazu Hledání INDEX
- 17. Hledání - zpracování dotazu Zpracováni dotazu - metasearch •oháčkování •doplnění skloňovaných tvarů slov •detekce čísel •generování podobných slov •desambiguace •detekce zkratek •....
- 18. Hledání - zpracování dotazu sip tmobile babybox weisser universita
- 19. Hledání - distribuované hledání Příprava dotazu A A A H H I 115x I
- 20. Hledání - prezentace výsledku • generování úryvku (snippet) • náhled • související dotazy
- 21. Hledání a prezentace v číslech • 4 webovky • 4 příprava dotazu • 10 agregátorů • 115 hledání • 2 serverovny (2x)
- 22. Fulltextové hledání v internetu
- 23. Fulltextové hledání v internetu
- 24. Děkuji za pozornost… Tomáš Hlucháň
Notas do Editor
- 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 ?
- 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
- 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
- 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 ...
- 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.
- - 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.
- 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.
- indexfeeder je zodpovedny za distribuci dokumentu ke spravnemu indexeru. takze mam vznikne 115 hledacich DB - 115 indexu
- - 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
- 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.
- 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.
- 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. ~
- Blog zde mame dotaz uzivatele, a vidime jeho predzpravanou podobu, resp. jeho reprezentaci v podobe stromu dotazu.
- 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
- 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
- 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.