BAKALÁŘSKÁ PRÁCE. Fulltextové vyhledávání v Unicorn ES pomocí Lucene. Fulltext searching in Unicorn ES by Lucene. Miroslav Škařupa

BAKALÁŘSKÁ PRÁCE Fulltextové vyhledávání v Unicorn ES pomocí Lucene Fulltext searching in Unicorn ES by Lucene Miroslav Škařupa

Un ico rn Co lle ge © 20 10 Un ico rn Co lle ge , V K ap slo vn ě 27 67 /2 , P ra h a 3 , 1 30 00 Ná ze v p rá ce v ČJ: Ná ze v p rá ce v AJ:

Fu llt e xt o vé vyh le d á vá n í v Un ico rn E S p om ocí Lu cen e Fu llt e xt se a rch in g in Un ico rn E S b y Lu ce ne

Au to r:

Miro sla v Š ka řu pa

Aka de m ický ro k:

20 09 /2 0 10

Ko nt a kt:

E -ma il: ska ru pa . m ire k@ vo ln y. c z Te l. : (+4 20 ) 7 74 15 1 7 57

Bakalářská práce Fulltextové vyhledávání v Unicorn ES pomocí Lucene Fulltext searching in Unicorn ES by Lucene

1.

ZADÁNÍ

▪3▪


2.

ABSTRAKT

Cílem této bakalářské práce je, na základě doporučených technologií (Lucene, Java, Tomcat, Linux, Hadoop), navrhnout použitelnou Open Source alternativu dosavadního fulltextového vyhledávání v Unicorn ES, závislého na Oracle. Práce je z části rešerše, z části analytickou (analýza požadavků) i architektonickou dokumentací (4+1 view) a v neposlední řadě obsahuje samotnou implementaci navrhovaného řešení. V závěru je uvedeno celkové shrnutí navrženého řešení a přínosy pro samotného autora této bakalářské práce. V úvodní (rešeršní) části je nastíněna problematika a specifika fulltextového vyhledávání jako takového a představení hlavního použitého nástroje Lucene. Nemalé úsilí bylo věnováno pochopení motivace zadavatele ke změně dosavadního způsobu fulltextového vyhledávání a jakých cílů chce tímto dosáhnout. Dále bylo nezbytné správně identifikovat, porozumět a zachytit veškeré požadavky zadavatele na optimální fungování fulltextového vyhledávání. Toto vše je obsaženo v následující (analytické) části. Nutností pro započetí návrhové (architektonické) části bylo pochopení architektury Unicorn ES jako takové, což zahrnovalo seznámení se s dílčími principy vnitřní skladby a fungování komponent, artefaktů a dalších jeho součástí, jež byly na straně Unicorn ES zapojeny do procesu vyhledávání, měly s ním určitým způsobem co do činění a ovlivňovaly implementaci fulltextového vyhledávání. Na základě znalostí z předešlých fází bylo možno přistoupit k započetí práce na návrhu implementace fulltextového vyhledávání v nyní již zmapovaném prostředí Unicorn ES. Tato část ve velké míře obsahuje popis a hlavně diagramy a modely, zachycující jak strukturální skladbu navrhovaného řešení, tak dynamickou podobu fungování jednotlivých součástí. Samotná implementace řešení je součástí této práce v podobě přiloženého CD. V poslední části je celkové shrnutí celého projektu a zároveň jsou zde uvedeny přínosy pro samotného autora této bakalářské práce, jež jejím vypracováním získal.

Klíčová slova: fulltextové vyhledávání, indexace, Lucene, Solr, Java, distribuované úložiště idexů, Tomcat, Linux, webové služby, Hadoop, ActiveMQ, Axis2

▪4▪


3.

ABSTRACT

The goal of this bachelor thesis is, on the base of recommended technologies (Lucene, Java, Tomcat, Linux, Hadoop), to design applicable Open Souce alternative to the current fulltext searching in Unicorn ES, dependent on Oracle. This work is partly recherche, partly analytical (requirements) also architectural documentation (4+1 view) and last but not least consists of the proposed solution implementation. In the end is mentioned the proposed solution conclusion and benefits for author of this work. In the opening (recherche) part are outlined problems and specifics of the fulltext searching and introduction of the main applied tool Lucene. There was a big effort dedicated to understanding the submitter's motivation for current way of fulltext search change and what is the goal, that should be reached by this. Another goal was to identify, understand and collect all the submitter's requirements, necessary for proper fulltext searching function. All this is written in the (analytical) part. There was necessity to understand Unicorn ES architecture before entering the design (architectural) part. This includes familiarization with the principles of the inner structure and component, artifacts and other components principles, which has something to do with the fulltext searching implementation and affects it. On the base of knowledges from the previous phases was possible to start the fulltext searching implementation design. This part mostly consists of description, but also diagrams and models, noting structural and dynamical view of certain parts functioning. CD with implementation is also supplement of this work. The last part is the whole project conclusion and also mentions the benefits for author of this work.

Keywords: fulltext searching, indexing, Lucene, Solr, Java, distributed index storage, Tomcat, Linux, web services, Hadoop, ActiveMQ, Axis2

▪5▪


4.

PROHLÁŠENÍ

Prohlašuji, že svou bakalářskou práci na téma Fulltextové vyhledávání v Unicorn ES pomocí Lucene jsem vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou též uvedeny v seznamu literatury a použitých zdrojů. Jako autor uvedené bakalářské práce dále prohlašuji, že v souvislosti s vytvořením této bakalářské práce jsem neporušil autorská práva třetích osob, zejména jsem nezasáhl nedovoleným způsobem do cizích autorských práv osobnostních a jsem si plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb.

V Praze dne 10.8.2010

…….……Miroslav Škařupa…………. jméno příjmení

▪6▪


5.

PODĚKOVÁNÍ

Děkuji vedoucímu bakalářské práce Mgr. Peteru Buchlákovi za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce. Dále děkuji Ing. Petru Ciochoňovi za konzultační činnost, potřebnou pro správné pochopení konkrétní problematiky a požadavků na fulltextové vyhledávání ve firmě Unicorn a.s..

▪7▪


6.

OBSAH

1. 2. 3. 4. 5. 6. 7. 8.

Zadání.......................................................................................................................................... 3 Abstrakt....................................................................................................................................... 4 Abstract....................................................................................................................................... 5 Prohlášení................................................................................................................................... 6 Poděkování................................................................................................................................. 7 Obsah.......................................................................................................................................... 8 Úvod........................................................................................................................................... 10 Teorie Fulltextového vyhledávání.......................................................................................... 11 8.1 Úvod.................................................................................................................................. 11 8.2 Fulltextové vyhledávání.................................................................................................. 11 8.2.1 Princip fungování fulltextového vyhledávání............................................................11 8.2.2 Index (Forward & Inverted index)..............................................................................13 9. Představení Lucene/Solr........................................................................................................ 14 9.1 Úvod.................................................................................................................................. 14 9.2 Historie.............................................................................................................................. 14 9.3 Důvod výběru Lucene/Solr............................................................................................. 14 9.4 Lucene............................................................................................................................... 15 9.5 Solr.................................................................................................................................... 17 10. Představení Hadoop.............................................................................................................. 18 10.1 Úvod................................................................................................................................ 18 10.2 Hadoop Distributed File System..................................................................................18 10.3 MapReduce.................................................................................................................... 19 11. Analýza................................................................................................................................... 21 11.1 Úvod................................................................................................................................ 21 11.2 Popis problému.............................................................................................................. 21 11.3 Návrh řešení................................................................................................................... 22 11.4 Klíčoví uživatelé............................................................................................................ 22 11.5 Popis systému................................................................................................................ 22 11.5.1 High-level pohled....................................................................................................... 23 11.5.2 Rozdělení na komponenty........................................................................................ 23 11.5.3 Rozhraní systému...................................................................................................... 24 11.6 Funkční požadavky....................................................................................................... 25 11.7 Nefunkční požadavky.................................................................................................... 26 11.8 Usecase model.............................................................................................................. 26 12. Design..................................................................................................................................... 28 12.1 Úvod................................................................................................................................ 28 12.2 4+1 view.......................................................................................................................... 28 12.2.1 Logický pohled............................................................................................................ 28 12.2.2 Vývojový pohled......................................................................................................... 30 12.2.3 Procesní pohled......................................................................................................... 33 12.2.4 Fyzický pohled............................................................................................................ 36 12.2.5 Usecase pohled – UC-1 Vytvořit index...................................................................38 12.2.6 Usecase pohled – UC-4 Vyhledat výraz v indexu.................................................39 12.3 Plán cílového řešení..................................................................................................... 40 12.3.1 Jazyková analýza....................................................................................................... 40 12.3.2 Bezpečnost................................................................................................................. 42 12.3.3 Distribuovanost........................................................................................................... 45 13. Implementace......................................................................................................................... 52 13.1 Úvod................................................................................................................................ 52 13.1.1 Vytvoření indexační zprávy......................................................................................52 13.1.2 Zpracování indexační zprávy...................................................................................53 ▪8▪


13.1.3 Vyhledávací dotaz na Apache Solr..........................................................................54 13.1.4 Zpracování vyhledávací odpovědi Apache Solr.....................................................55 13.1.5 Spuštění, testování výsledného řešení...................................................................55 13.1.6 Spuštění ukázky distribuovanosti............................................................................56 13.1.7 Dodatek....................................................................................................................... 58 14. Závěr....................................................................................................................................... 59 14.1 Komunikace.................................................................................................................... 59 14.2 Indexování, distribuovanost......................................................................................... 59 14.3 Vyhledávání.................................................................................................................... 60 14.4 Vícejazyčnost................................................................................................................. 60 14.5 Bezpečnost..................................................................................................................... 60 14.6 Prototyp.......................................................................................................................... 60 14.7 Open Source řešení...................................................................................................... 60 14.8 Osobní přínos................................................................................................................ 61 15. Conclusion.............................................................................................................................. 62 15.1 Communication.............................................................................................................. 62 15.2 Indexing, distributed solution.......................................................................................62 15.3 Searching........................................................................................................................ 62 15.4 Multi-language support................................................................................................. 63 15.5 Security........................................................................................................................... 63 15.6 Prototype........................................................................................................................ 63 15.7 Open Source solution................................................................................................... 63 15.8 Personal benefits........................................................................................................... 63 16. Seznam použité literatury..................................................................................................... 65 17. Seznam použitých symbolů a zkratek................................................................................67 18. Seznam tabulek..................................................................................................................... 68 19. Seznam obrázků.................................................................................................................... 69 20. Seznam příloh........................................................................................................................ 70 20.1 Příloha č. 1 – CD s implementací...............................................................................70 20.1.1 Adresář SW................................................................................................................. 70 20.1.2 Adresář Solr................................................................................................................ 70 20.1.3 Adresář SolrCloud...................................................................................................... 71

▪9▪


7.

ÚVOD

Smyslem a cílem této práce je nejlépe zcela vyřešit, spíše však nastínit možné řešení konkrétního a reálného problému s dosavadním způsobem vyhledávání v informačním systému Unicorn ES firmy Unicorn a.s. (dále zadavatel). V současnosti u zadavatele vyhledávání funguje na základě funkčnosti „interMedia Index“ používané databáze Oracle 10g Standard Edition společnosti Oracle, což sebou nese určité problémy. Problémem je omezení Standard Edition na čtyři procesory, omezení funkčnosti v oblasti Oracle interMedia Index … nelze provádět online přepočítávání indexů, silně je omezena škálovatelnost, atd. Jedním z možných řešení je přejít na Oracle Enterprise Edition, ale vzhledem k její finanční náročnosti na licenci bylo rozhodnuto o hledání Open Source alternativy dané problematiky, kdy jedním z možných by mohlo být řešení, založené na fulltextové vyhledávací knihovně Lucene od Apache Software Foundation, čemuž se právě věnuje tato bakalářská práce. Práce je rozdělena do několika hlavních částí. Jako úvod do problematiky jsou v kapitole Teorie fulltextového vyhledávání představeny principy tohoto typu vyhledávání. V následujících kapitolách jsou představeny hlavní nástroje Apache Lucene / Solr, jako indexovací, vyhledávací nástroj a Apache Hadoop, jako možné distribuované řešení indexu. Kapitola s názvem Analýza dává odpovědi na otázky, týkající se popisu stávajícího stavu, jaké požadavky jsou kladeny na nové řešení a lze zde najít hrubý koncept možného řešení, včetně schématických modelů. Smyslem kapitoly Design je, pomocí 4+1 view, popsat z několika pohledů specifika navrženého řešení, jehož některé významné implementační momenty jsou zachyceny v kapitole Implementace. V Závěru je formulace finálního shrnutí celé práce a míra úspěšného splnění očekávaného.

▪ 10 ▪


8.

8.1

TEORIE FULLTEXTOVÉHO VYHLEDÁVÁNÍ

Úvod

Hlavním nosným tématem této práce je problematika fulltextového vyhledávání. Proto je vhodné, jako úvod do této problematiky, uvést několik aspektů s tím spojených. Kapitola stručně shrnuje hlavní principy fulltextového vyhledávání a slouží jako úvod do této oblasti, přičemž si neklade za cíl detailně zmapovat oblast fulltextového vyhledávání jako takového. Dále je zde představen použitý nástroj Lucene, taktéž důvody pro jeho volbu, včetně popisu vlastností a principů jeho fungování.

8.2

Fulltextové vyhledávání

Fulltextové vyhledávání je speciální typ vyhledávání, převážně ve velkých objemech dat, kdy pomocí předpřipravených datových struktur (indexů) výrazným způsobem urychlují zpřístupnění výsledkové sady uživateli.

8.2.1

Princip fungování fulltextového vyhledávání

▪ 11 ▪


Obrázek č. 1 – Princip fungování fulltextového vyhledávání[1] Získání dat - Nejprve je pochopitelně potřeba získat nějaká data, která poté budou vyhledávána. Data mohou pocházet z různých zdrojů (např. souborový systém, databáze, web, manuálně zadaná data) a také mohou být v různých formátech. Nejčastější je tzv. fulltextové vyhledávání (full text search), ale kromě textu je možné vyhledávat třeba obrázky nebo video. Kromě toho text nemusí pocházet v plain-textové podobě, ale i jiných formátech - HTML, XML, PDF, Open Docu ment Format, MS Office formátech apod. Parsování - Jelikož data přicházejí v různých formátech, je nutné je napřed rozparsovat. Během parsování si search engine připraví informace, které použije pro vyhledání původních dat. Dokumenty pro indexaci - Search engine si vstupní data převede do formátu určeného k tzv. in dexaci. Tyto "dokumenty" obsahují informace, ze kterých search engine dokáže vyrobit/rozšířit svůj index. Index – Index je datová struktura, v níž je uloženo mapování obsahu na jeho umístění [28]. Index slouží k rychlému získávání informací. Prostřednictvím indexu je search engine schopen vyhledávat informace mnohem efektivněji než prostým procházením samotných dat (což by znamenalo značnou spotřebu času i výpočetního výkonu). Např. 10000 dokumentů lze pomocí indexu prohledat v řádech milisekund, ale prohledání všech 10000 dokumentů by mohlo trvat řádově hod-

▪ 12 ▪


iny. Index sice zabírá dodatečné místo navíc (oproti samotným datům) a je třeba jej spravovat a aktualizovat, nicméně tyto náklady se kvůli zrychlení vyhledávání určitě vyplatí. Zdroj: [1]

8.2.2

Index (Forward & Inverted index)

Forward index tvoří uspořádané dvojice dokumentu a slov v něm obsažených (viz. Tab. č. 1). Vytváří se při pársování a přípravě dokumentu pro indexaci, kdy je vhodné si ke konkrétnímu dokumentu rovnou zaznamenat slova jím obsažená. Setříděním této struktury ne dle dokumentu, ale dle jednotlivých slov se z Forward indexu vytvoří Inverted index. Forward index Dokument

Slova obsažená v dokumentu

Dokument 1

Skákal, pes, přes, oves

Dokument 2

Skákal, přes

Dokument 3

Skákal

Tabulka č. 1 – Forward index[2], upraveno Inverted index tvoří uspořádané dvojice slov a dokumentů, jež tato slova obsahují (viz. Tab. č. 2). Jak již bylo uvedeno výše, lze jej vytvořit setříděním Forward indexu dle slov. Jelikož nás ve fulltextovém vyhledávání primárně zajímají uživatelem zadaná hledaná slova a až na základě těchto poté následně hledáme dokumenty, ve kterých jsou obsažena, je právě tato datová struktura vhodná pro účely fulltextového vyhledávání (u každého slova máme ihned „po ruce“ odkazy na soubory, obsahující tato slova). Inverted index Hledané slovo Dokument(y) obsahující hledané slovo Skákal

Dokument 1, Dokument 2, Dokument 3

pes

Dokument 1

přes

Dokument 1, Dokument 2

oves

Dokument 1

Tabulka č. 2 – Inverted index[2], upraveno

▪ 13 ▪


9.

PŘEDSTAVENÍ LUCENE/SOLR

9.1

Úvod

Jelikož je jádrem navrženého řešení knihovna Lucene, je vhodné si ji blíže představit, což je náplní této kapitoly. Zdroj: [3]

9.2

Historie

IR (Information Retrieval) knihovna Lucene je původním dílem autora jménem Doug Cutting, který ji nejdříve nabízel pomocí webových stránek SourceForge. V roce 2001 se Lucene stala součástí rodiny Jakarta, náležející pod The Apache Software Fundation, kde se v roce 2005 stala top-level Apache projektem, který dnes již zahrnuje řadu vlastních subprojektů (např.: Lucene Java, Droids, Lucene.Net, Lucy, Mahout, PyLucene, Solr, Open Relevance Project).

9.3

Důvod výběru Lucene/Solr •

knihovna Lucene byla již předvybrána a zadavatelem doporučena

•

free Open Source licence Apache License, Version 2.01

•

za Lucene stojí silná skupina The Apache Software Foundation

•

kladné ohlasy a hodnocení ve srovnání s jinými nástroji (Zdroj: [5], [6], [7])

•

reference na projekty, jež knihovnu Lucene používají (Apple, Eclipse IDE, the Encyclopedia Britannica CD-ROM/DVD, FedEx, the Mayo Clinic, Netflix, Linked In, Hewlett-Packard, New Scientist magazine, Salesforce.com, Atlassian (Jira), Epiphany, MIT’s OpenCourseware and Dspace, Akamai’s EdgeComputing platform, Digg a mnoho dalších2)

1

- Apache License, Version 2.0, http://www.apache.org/licenses/LICENSE-2.0

2

- Projekty založené na Lucene, http://wiki.apache.org/lucene-java/PoweredBy ▪ 14 ▪


9.4

Lucene

Lucene: •

je vysoce výkonná, škálovatelná knihovna pro vyhledávání informací

•

je poskytována The Apache Software Foundation pod open-source licencí Apache License, Version 2.0

•

obsahuje snadno srozumitelné a použitelné API pro indexaci a vyhledávání

•

je implementováná v jazyce Java

•

je schopna pracovat s velkým množstvím formátů dat (lokální i vzdálené dokumenty, Microsoft Word dokumenty, XML, PDF a další formáty, ze kterých je možno extrahovat textové informace … emaily, instant messenging chat, atd.)

•

je schopna pracovat s dotazy typu: „+George +Rice -eat -pudding, Apple -pie +Tiger, animal:monkey AND food:banana“

•

je dodávána jako JAR soubor bez dalších dodatečných závislostí, který je potřeba zakomponovat do celkového konceptu příslušné aplikace

•

je portována do dalších jazyků (Perl, Python, C++, C#, .NET)

•

není „ready-to-use“aplikace

▪ 15 ▪


Obrázek č. 2 – Kompetence Lucene3[3] Díky výše uvedenému patří Lucene mezi jedny z nejpoužívanějších vyhledávacích nástrojů.

3

- Kompetence Lucene, šedě zabarvené součásti jsou v kompetenci Lucene ▪ 16 ▪


9.5

Solr

Zdroj: [4] Solr je Open Source (Apache License, Version 2.0) platforma pro enterprise vyhledávání od The Apache Software Foundation, využívající knihovnu Lucene. Kromě jiného nabízí výkonné fulltextové vyhledávání, dynamický clustering, práci s mnoha formáty dat, škálovatelnost, distribuované vyhledávání, replikaci indexu a další.

▪ 17 ▪


10.

10.1

PŘEDSTAVENÍ HADOOP

Úvod

Apache Hadoop je Open Source (licence ASL 2.0) projekt The Apache Software Foundation. Zahrnuje (kromě jiných) subprojekty Hadoop Distributed File system a MapReduce. Jedná se o software pro spolehlivé, škálovatelné a distribuované výpočty. Zdroj: [25].

10.2

Hadoop Distributed File System

Hadoop Distributed File System (HDFS) je distribuovaný souborový systém, určený pro běh na běžně používaném serverovém hardware. Zajišťuje vysokou míru tzv. fault-tolerance, přístupu k datům a je vhodný pro aplikace s velkým množstvím dat. Jedná se o architekturu typu master / slave, jejímiž hlavními součástmi jsou tzv. NameNode a DataNode. NameNode je master server, který drží a spravuje informace o DataNode, které zároveň řídí. DataNode je slave server, který přímo řídí ukládání dat. Data mohou být rozložena na několik bloků a tyto bloky separátně uloženy na několika DataNode, popřípadě pomocí replikace rozkopírována.

▪ 18 ▪


Obrázek č. 3 – HDFS architektura[25]

10.3

MapReduce

MapReduce je model pro hromadné zpracování dat. Pracuje na principu rozděl a panuj a dále také na předpokladu, že je lépe přenést výpočetní úlohu za daty, než přenášet data za výpočetní úlohou. V praxi to znamená to, že složitá úloha, jejíž výpočet na jednom serveru by byl neúměrně časově náročný, se rozloží na vícero dílčích úloh na jednotlivých serverech a tyto se poté agregují do jedné výsledkové sady. Model MapReduce se skládá ze dvou hlavních částí. První je funkce Map, která obsahuje výpočetní logiku, která se provádí nad jednotlivými distribuovanými daty. Druhá je funkce Reduce, která dílčí výsledky jednotlivých Map funkcí agreguje a zpracovává konečný výsledek.

▪ 19 ▪


Obrázek č. 4 – MapReduce[26]

▪ 20 ▪


11.

ANALÝZA

11.1

Úvod

V analytické části jsou zachyceny veškeré informace, sloužící ke správnému pochopení motivace a cílů zadavatele pro změnu v přístupu koncepce vyhledávání a taktéž požadavků, jež na nově navržené řešení klade. Dále je zde obecně nastíněno nové řešení a jeho přínosy.

11.2

Popis problému

Společnost Unicorn provozuje vlastní informační systém Unicorn ES, který obsahuje funkčnost fulltextového vyhledávání. Unicorn ES je mimo samotných zaměstnanců společnosti Unicorn nabízen jako Software As A Service. Společnost Unicorn je ve stávajícím řešení fulltextového vyhledávání v Unicorn ES závislá na technlogii Oracle. V Unicorn ES je dosud možno zadávat pouze jednoduché vyhledávací dotazy. Zadavatelem požadováno zadávat vyhledávací dotazy typu: "Najdi všechny aktivní artefakty, za které je kompetentní ředitel UCL a nachází se v organizační jednotce Management v teritoriu UCL a mají na sobě přílohu ve formátu Powerpoint a v jejich popisu je slovo "student"". Společnost Unicorn bude muset perspektivně, s narůstajícím objemem indexů v databázi, řešit rostoucí požadavky na úložiště dat. Současné řešení fulltextového vyhledávání je: •

založeno (závislé) na technologii Oracle 10g Standard Edition

•

řešeno funkčností Oraclu 10g "InterMedia Index"

•

indexy nelze přepočítávat online

•

řešeno indexací pouze textového obsahu (v XML) artefaktu

•

potencionálně rizikové z hlediska neustálého růstu indexů (z důvodu zachování funkčního vyhledávání nelze indexy zálohovat)

•

omezena škálovatelnost

▪ 21 ▪


11.3

Návrh řešení

Nově navržené řešení bude realizováno, vzhledem k Unicorn ES, formou samostatného satelitního subsystému s maximálním využitím Open Source technologií, vlastním operačním systémem a serverem, na kterém bude nasazena komponenta, která bude volána z Unicorn ES a jejíž moduly budou zajišťovat jak indexování a vyhledávání dokumentů, tak ukládání indexů pomocí distribuovaného file systému. Nově navržené řešení je založeno na Open Source technologiích, čímž řeší závislost na komerčním produktu Oracle. Samotné indexování obsahu dokumentů a jejich následné vyhledávání je řešeno pomocí knihovny Lucene/Solr (psané v Javě) od The Apache Software Foundation. Toto Open Source řešení nabízí jak snadnou implementaci a plnohodnotné vyhledávací funkce v mnoha různých formátech dat, tak ukládání a čtení rostoucího množství informací v podobě indexů, formou dynamického clusteringu, škálovatelnosti, distribuovanému vyhledávání a replikaci indexu. Vyhledávání bude řešeno synchronně pomocí SOAP webových služeb (Apache Axis2), indexace asynchronně formou zasílání zpráv na messaging server (Apache ActiveMQ).

11.4

Klíčoví uživatelé

Uživatel

Popis uživatele

Odhadovaný počet uživatelů

Unicorn ES (jeho uživatelé)

Uživatel Unicorn ES, který má potřebu vyhledávat. Může se jednat o uživatele v různých rolích, ale jejich práce v oblasti vyhledávání bude v zásadě velice podobná, ne-li totožná.

V řádech 1.000, max. 10.000 lidí (aktuálně), postupem doby stále rostoucí

Tabulka č. 3 – Klíčoví uživatelé[27]

11.5

Popis systému

Kapitola poskytuje stručný náhled na navrhované řešení formou komentovaných schémat a diagramů.

▪ 22 ▪


11.5.1

High-level pohled

Architektura navrhovaného řešení je koncipována jako klasická architektura klient – server, kdy v roli klienta vystupuje server UnicornES a v roli serveru server UnicornESToSolrAdapter, který dále komunikuje se serverem Search Engin, realizující fyzickou indexaci dat. Message Broker, popř. web service provider (Apache Axis2) plní roli jakéhosi komunikačního kanálu klienta se serverem a naopak. Viz. obrázek níže.

Obrázek č. 5 – High level pohled

11.5.2

Rozdělení na komponenty

Na následujícím obrázku je v jednoduchosti zobrazena struktura package komponenty (UnicornESToSolrAdapter), zajišťující indexaci a vyhledávání v indexu. Obě tyto package dále závisí na package, obsahující třídu, poskytující spojení se serverem Search Engine (Apache Solr).

▪ 23 ▪


Obrázek č. 6 – Komponenty

11.5.3

Rozhraní systému

Klient při indexaci zadává nutné parametry, jimiž jsou: •

artefakt - hrubá data k indexaci

•

id artefaktu

•

jméno artefaktu

•

true/false – pokud chce smazat index daného artefaktu s daným id

•

preferovaný jazyk indexace

Tyto jsou odeslány ve formě zprávy (asynchronní) na frontu v Message Brokeru, odkud si ji převezme server (UnicornESToSolrAdapter), přetransformuje ji na požadavek pro Search Engine, který indexaci fyzicky provede. Klient nečeká na výsledek indexace. --Klient při vyhledávání zadává nutné parametry, jimiž jsou: •

výraz pro vyhledávání – co, popř. jak hledáme

▪ 24 ▪


•

počet záznamů ve výsledkové sadě – kolik chceme vrátit výsledků

•

číslo stránky výsledkové sady

Tyto jsou formou volání webové služby (synchronně, pomocí Web service providera) předány na server (UnicornESToSolrAdapter), který z nich vytvoří a odešle požadavek na Search Engine, který serveru vrátí specifickou odpověď s výsledky hledání. Server z této specifické odpovědi extrahuje informace, které klienta zajímají, což je seznam id nalezených artefaktů, který vloží do výsledkové sady pro klienta, ale navíc, na první místo tohoto seznamu ještě uvede údaj o max. možném potencionálním počtu nalezených artefaktů, který klient potřebuje pro svou funkci stránkování této výsledkové sady. Výsledkovou sadu server vrátí na klienta.

11.6

Funkční požadavky

Název požadavku

Popis požadavku

Základní UC

Vytvořit index

Systém vytvoří nový index

UC-1, UC-5

Upravit index

Systém aktualizuje stávající index

UC-2, UC-5

Smazat index

Systém smaže index dle id artefaktu

UC-3, UC-5

Systém v uložených indexech nalezne Vyhledat výraz v požadovaný výraz a odešle příslušnou indexu výsledkovou sadu do Unicorn ES

UC-4, UC-5

Tabulka č. 4 – Funkční požadavky[27]

▪ 25 ▪

Rizikovost

Priorita


11.7

Nefunkční požadavky

Název požadavku

Popis požadavku

Bezpečnost

Přístup jednotlivých rolí pouze k odpovídajícím informacím

Lokalizace

Schopnost systému fungovat s více jazyky. Minimálně angličtina, španělština, čeština

Rizikovost

Priorita

Vzhledem k neustálému rostoucímu objemu indexů a jejich Škálovatelnost nemožnosti archivace, z důvodu zachování funkčnosti vyhledávání, poroste požadavek na růst datového úložiště Dostupnost

Funkčnosti, poskytované pomocí FSE, musí být zajištěny pro dostatečný počet uživatelů

Komunikace vzdáleným voláním rozhraní

FSE bude s Unicorn Universe komunikovat pomocí vzdáleného volání, bez nutnosti implementace prezentační vrstvy. Úlohu jakési prezentační vrstvy přebírá rozhraní, definované na FSE.

Obecně - využití Open Source technologií, platformová nezávislost Operační systém - Linux Implementační Server - Tomcat požadavky Programovací jazyk - Java Doporučený vyhledávací engine - Apache Lucene/Solr Funkčnosti, poskytované pomocí FSE, musí být zajištěny s odpovídající časovou odezvou

Rychlost

Tabulka č. 5 – Nefunkční požadavky[27]

11.8

Usecase model

Navrhované řešení (FSE) obsahuje pět základních funkčností, které jsou využívány ze strany Unicorn ES. Poznámka: funkčnosti Smazání indexu a zvláště Vytvoření indexu a Úprava indexu, jsou si do jisté míry, z implementačního hlediska dosti podobné a proto jsou dále v části Design a zvláště Implementace realizovány ve formě jedné metody, která přebírá dle potřeby různé parametry. Název

Popis

Rizikovost Priorita

UC-1

Vytvořit index

Vytvořit index v případě vytváření nového dokumentu vytvoří nový index a uloží jej

UC-2

Upravit index

V případě aktualizace již existujícího dokumentu funkčnost Upravit index pouze zajistí aktualizaci stávajícího indexu a uložení těchto změn

UC-3

Smazat index zajistí v případě smazání Smazat index dokumentu odstranění příslušného, již nepotřebného indexu k danému dokumentu

▪ 26 ▪


Funkčnost Vyhledat výraz v indexu zajišťuje schopnost vyhledávat v indexu (dokumentech) a vrací seznam odkazů na dokumenty, jež obsahují hledaný výraz

UC-4

Vyhledat výraz v indexu

UC-5

Získat spojení Funkčnost zajistí získání odkazu na Search se Search Engine Engine

Tabulka č. 6 – Popis usecase

Obrázek č. 7 – Use case diagram

▪ 27 ▪


12.

DESIGN

12.1

Úvod

Východiskem pro kapitolu design je předchozí část analytická, ze které je potřeba vycházet a ve které jsou definovány základní předpoklady, principy a očekávání, jež má část designová naplnit.

12.2

4+1 view

Kapitola design je vypracována ve formě architektonické dokumentace (tzv. 4+1 view 4), jejímž cílem je poskytnout srozumitelný pohled na navrhované řešení ze 4+1 perspektiv pro různé role pracovníků, kteří by se na případném zavedení do provozu mohli podílet. Správné pochopení problematiky a úmyslů tvůrce designu je klíčové pro úspěch celého projektu. Každé tzv. view má svou vhodnou formu (diagramy, modely, atd.), jež nejlépe vystihují daný pohled na věc.

12.2.1

Logický pohled

Logický pohled je zaměřen na logickou strukturu systému a jeho rozdělení do logických komponent / vrstev. Architektura navrhovaného řešení je koncipována jako klasická architektura klient – server, kdy v roli klienta vystupuje server UnicornES a v roli serveru server UnicornESToSolrAdapter, který dále komunikuje se serverem Search Engin, realizující fyzickou indexaci dat. Message Broker, popř. web service provider (Apache Axis2) plní roli jakéhosi komunikačního kanálu klienta se serverem a naopak. Viz. obrázek níže.

4

4+1 view - http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model ▪ 28 ▪


Obrázek č. 5 – High level pohled Klient při indexaci zadává nutné parametry, jimiž jsou: •

artefakt - hrubá data k indexaci

•

id artefaktu

•

jméno artefaktu

•

true/false – pokud chce smazat index daného artefaktu s daným id

•

preferovaný jazyk indexace

Tyto jsou odeslány ve formě zprávy (asynchronní) na frontu v Message Brokeru, odkud si ji převezme server (UnicornESToSolrAdapter), přetransformuje ji na požadavek pro Search Engine, který indexaci fyzicky provede. Klient nečeká na výsledek indexace. --Klient při vyhledávání zadává nutné parametry, jimiž jsou: •

výraz pro vyhledávání – co, popř. jak hledáme

•

počet záznamů ve výsledkové sadě – kolik chceme vrátit výsledků

•

číslo stránky výsledkové sady

Tyto jsou formou volání webové služby (synchronně, pomocí Web service providera) předány na server (UnicornESToSolrAdapter), který z nich vytvoří a odešle požadavek na Search Engine, který serveru vrátí specifickou odpověď s výsledky hledání. Server z této specifické odpovědi extrahuje informace, které klienta zajímají, což je seznam id nalezených artefaktů, který vloží do výsledkové sady pro klienta, ale navíc, na první místo tohoto seznamu ještě uvede údaj o max. možném potencionálním počtu nalezených artefaktů, který klient potřebuje pro svou funkci stránkování této výsledkové sady. Výsledkovou sadu server vrátí na klienta. ---

▪ 29 ▪


Na níže uvedeném obrázku je schématicky popsána struktura indexu, v němž jsou data pro indexaci ukládána a následně vyhledávána. Pro zjednodušení si můžeme pod objektem Index představit klasickou excelovskou tabulku. Poté objekt Document bude představovat jeden záznam / řádek této tabulky. Objekty id, name, content, popř. content_en, es, cs, name_en, es, cs budou představovat jednotlivé sloupce dané tabulky / řádky. Sloupec id obsahuje id artefaktu, který indexujeme a je povinný. Navíc je unikátní pro danou tabulku. Sloupec name obsahuje jméno artefaktu, je taktéž povinný. Sloupec content obsahuje extrahovaný textový obsah z původního artefaktu, zaslaného klientem k indexaci, je povinný a může obsahovat vícenásobný textový obsah. Sloupec content_en, es, cs je obdobou sloupce content, pouze s jinou jazykovou verzí. Obdobně je to u sloupce name_en, es, cs. Navržené řešení podporuje vícejazyčnost a to tak, že si obsah, ve kterém se bude vyhledávat ukládá defaultně v anglickém jazyce a navíc v jazyce, který zvolí klient. Poté (při indexaci, nebo vyhledávání) se na danou jazykovou verzi aplikují patřičné filtry, zlepšující výsledky hledání v tom daném jazyce. Pokud není zvolen klientem preferovaný jazyk, užívá se právě defaultní anglická jazyková verze.

Obrázek č. 8 – Domain diagram – index

12.2.2

Vývojový pohled

Vývojový pohled zobrazuje systém z pohledu vývojáře, rozdělení systému na subsystémy / moduly / komponenty z pohledu implementace.

▪ 30 ▪


Na níže uvedeném obrázku je v jednoduchosti zobrazena struktura package komponenty (UnicornESToSolrAdapter), zajišťující indexaci a vyhledávání v indexu. Obě tyto package dále závisí na package, obsahující třídu, poskytující spojení se serverem Search Engine (Apache Solr).

Obrázek č. 6 – Komponenty Na níže uvedeném obrázku je zobrazena vnitřní struktura tříd package, zajišťující indexaci. Hlavní funkčnost je zde soustředěna ve třídě MyMessageConsumer, jejímž hlavním úkolem je, v krátkosti řečeno, transformovat data k indexaci od klienta a přeposlat je na server Search Engine (Apache Solr). Toto je implementováno tak, že třída je v konfiguračním souboru web.xml registrována jako Listener s parametrem load-on-startup, viz. níže. web.xml <listener> <listener-class>cz.skarupa.mirek.index.MyMessageConsumer 1

▪ 31 ▪


Tento

fakt,

plus

skutečnost,

že

třída

implementuje

rozhraní

ServletContextListener

a

MessageListener a dále její konstruktor, obsahující metodu (metoda startConnection) pro navázání spojení s Message Brokerem, umožňuje, aby při startu aplikace došlo k vytvoření instance této třídy a tím pádem k započetí odposlouchávání fronty cz.unicorn.indexQueue na Message Brokeru (Apache ActiveMQ). Pokud je z Message Brokeru přijata zpráva, je spuštěna metoda onMessage. V těle této metody je soustředěna logika indexace. Pokud je zpráva určena k smazání indexu, je odeslán příslušný požadavek na Search Engine ke smazání indexu. Pokud je cílem zprávy vytvoření / úprava indexu, je potřeba z obsahu artefaktu, určeného k indexaci extrahovat pouze odpovídající textový obsah (provádí třída TextHandler), popřípadě doplnit ID a název artefaktu. Jelikož systém podporuje více jazyků, dochází zde také k nastavení jazyku, ve kterém budou informace zaindexovány. Poté jsou data odeslána k indexaci.

Obrázek č. 9 – Class diagram – UnicornESToSolrAdapter.cz.skarupa.mirek.index Na níže uvedeném obrázku je zachycena vnitřní struktura tříd package, zajišťující vyhledávání v indexu. Třída SearchWS obsahuje hlavní metodu searchFor, která je volána klientem (UnicornES) a zprostředkovává vyhledávání. Obsahuje obdobnou metodu searchItInSolr, která fyzicky z klientských parametrů vytvoří požadavek, odešle jej na Search Engine, přijme specifickou odpověď serveru a tu vrátí. Metoda searchFor dále pokračuje tím, že ze specifické odpovědi serveru extrahuje požadované informace (seznam ID a max. možný počet nalezených artefaktů), tyto vloží do seznamu a jako výsledkovou sadu vrátí klientovi.

▪ 32 ▪


Obrázek č. 10 – Class diagram – UnicornESToSolrAdapter.cz.skarupa.mirek.search Na níže uvedeném obrázku je zachycena vnitřní struktura tříd package, zajišťující uskutečnění spojení se Search Engine (Apache Solr). Jelikož je potřebné v rámci celé aplikace zajistit to, aby se spojení uskutečňovalo pomocí jediné instance tohoto připojení, nabízí se implementace této třídy (SolrServerFactory) formou vytvářecího návrhového vzoru Singleton.

Obrázek č. 11 – Class diagram – UnicornESToSolrAdapter.cz.skarupa.mirek.solr

12.2.3

Procesní pohled

Procesní pohled popisuje dynamický aspekt systému, vysvětluje systémové procesy a jejich komunikaci se zaměřením na runtime chování systému. Níže si popíšeme dva základní procesy / funkčnosti, které navržené řešení nabízí. Je to indexace artefaktu a vyhledávání. Co se týká indexace, je schématicky popsána na níže uvedeném obrázku a jak již bylo zmíněno výše, jelikož se implementačně vytváření, úprava a smazání indexu velice podobají, popisujeme i zde tyto tři funkčnosti jednorázově s tím, že uvedeme jejich případné rozdílnosti.

▪ 33 ▪


Na

indexaci

se

podílí

všechny

tři

součásti

navrhovaného

řešení

(Message

Broker,

UnicornESToSolrAdapter, Search Engine), plus samozřejmě klientská aplikace (UnicornES). Základním aspektem při procesním pohledu na indexaci je předpoklad, že tato funkčnost je volána klientem při ukládání, úpravě, nebo mazání artefaktu a to tak, že klient na výsledek indexace nečeká a pokračuje dál v toku svého use case a i v případě, že by indexace jako taková v některém svém kroku selhala a nedošlo by k požadované změně, nejedná se o žádnou fatální záležitost, která by se na straně klienta výrazně projevila. To znamená, že se tu jedná o úlohu typu „fire & forget“, kde lze a je to výhodou, použít asynchronní zasílání zpráv. Toto je zde řešeno formou messagingu mezi klientem a UnicornESToSolrAdapter, který zprostředkovává fronta na Message Brokeru. Další komunikace směrem k Search Engine je již formou klasických HTTP požadavků. Rozdíly mezi vytvořením, úpravou a smazáním indexu jsou následující. Vytvoření a úprava indexu se liší pouze ve výsledku pro Search Engine, který tyto procesy přinášejí (vytvoření: vytvoří se nový index, úprava: přepíše se stávající index), jinak jsou to naprosto totožné procesy. Naproti mazání indexu, kde se nepřenášejí žádné informace k indexaci (mimo Id artefaktu), je potřeba extrahovat informace k indexaci a přetransformovat obsah artefaktu, přicházejícího od klienta, na formát, který je vhodný pro indexaci. Výsledkem smazání indexu je odstranění daného záznamu z indexu dle jeho ID.

Obrázek č. 12 – Activity diagram – indexace

▪ 34 ▪


Co se týče procesu vyhledávání, tento je již, na rozdíl od procesu indexace, řešen synchronně. To znamená, že klient vyvolá funkčnost vyhledávání a čeká na její dokončení (vrácení výsledkové sady) a až poté pokračuje ve svém usecase dál. Na vyhledávání se tím pádem již nepodílí Message Broker, ale do hry vstupuje volání metod pomocí web service (SOAP). Klient předává parametry vyhledávání pomocí volání web service na UnicornESToSolrAdapter, který tyto přeposílá na Search Engine a tento prohledává záznamy ve svém indexu a vrací výsledkovou sadu zpět na UnicornESToSolrAdapter ve formě Solr response. Zde je potřeba extrahovat data, která klienta zajímají. Těmi jsou seznam ID artefaktů, které odpovídají vyhledávacímu výrazu klienta a dále max. možný počet nalezených artefaktů (toto je blíže popsáno / odůvodněno v předešlých kapitolách). Informace jsou klientovi vráceny v podobě výsledkové sady.

Obrázek č. 13 – Activity diagram – hledání

▪ 35 ▪


12.2.4

Fyzický pohled

Fyzický pohled popisuje systém z pohledu fyzického rozdělení (topologie) systému a komunikace mezi jednotlivými uzly. Jelikož se do celkového finálního konceptu řešení nepodařilo zahrnout jeho distribuovanost, je níže uvedený fyzický pohled navržen v jakési základní formě (bez distribuovanosti). Určitý nástin potencionání distribuovanosti je řešen dále v oddělené kapitole tohoto dokumentu. Přestože by bylo možno nasadit veškeré funkčnosti navrženého řešení na jeden hardwarový server, byl zde brán v úvahu fakt, že se jedná o řešení pro enterprise prostředí, s velkým (v čase rostoucím) počtem uživatelů, proto se celek rozdělil dle svých funkčností na 3 samostatné servery. Fyzické rozložení navrhovaného řešení je zachyceno na obrázku níže. UnicornES vystupuje ve formě klienta, který vysílá zprávy, požadavky, popřípadě přijímá odpovědi. Řešení je rozloženo na tři samostatné servery, kdy každý plní určitou logicky ohraničenou oblast funkčnosti systému jako celku. Každý server obsahuje OS Linux a Javu a dále buď Jetty, respektive Tomcat. Apache ActiveMQ je Message Broker, který obsahuje frontu, plnící svůj účel při indexaci. Pomocí messagingu

s

ním

komunikuje

jak

klient

(UnicornES),

tak

vyhledávací

aplikace

(UnicornESToSolrAdapter.war). UnicornESToSolrAdapter.war je vyhledávací aplikace, která při indexaci stahuje zprávy z Message Brokeru a dále získané informace přepošle na Search Engine. Při vyhledávání komunikuje s klientem pomocí webových služeb (SOAP) … zajišťuje Apache Axis2.ear a opět požadavek přeposílá na Search Engine a jeho odpověď vrací zpět na klienta (UnicornES). Apache Solr je Search Engine, komunikující s vyhledávací aplikací (UnicornESToSolrAdapter.war) při indexaci dokumentů a hledání výrazů, klasicky, pomocí HTTP.

▪ 36 ▪


Obrázek č. 14 – Deployment diagram

▪ 37 ▪


12.2.5

Usecase pohled – UC-1 Vytvořit index

KRÁTKÝ POPIS Na základě klientem zadaných parametrů systém (server) vytvoří v indexu záznam. PODMÍNKY PRO SPUŠTĚNÍ --ZÁKLADNÍ TOK #

Klient 1

Server

Klient odešle asynchronní zprávu s parametry, potřebnými k vytvoření indexu

2 Klient pokračuje dál v toku svého use case

Server přijme zprávu od klienta

3

Server extrahuje text k indexaci z přijaté zprávy do SolrInputDocumentu

4

Server extrahuje id, jméno artefaktu k indexaci z přijaté zprávy do SolrInputDocumentu

5

Spustí se usecase Získat spojení se Search Engine, čímž Server získá odkaz na Search Engine

6

Server odešle na Search Engine SolrInputDocument, čímž dojde k indexaci

Tabulka č. 7 – UC-1, základní tok ALTERNATIVNÍ TOKY A1 – Výjimka #

Klient

Server

Tento alternativní tok nastává v kterémkoli kroku základního toku 1

Na serveru je vyvolána výjimka

2

Server zaloguje potřebné informace

Tabulka č. 8 – UC-1, alternativní tok HLAVNÍ SCÉNÁŘE ZT ZT → A1 PODMÍNKY PO DOKONČENÍ Buď je vytvořen index nebo je zalogována výjimka. SPECIÁLNÍ POŽADAVKY DALŠÍ INFORMACE A DIAGRAMY ▪ 38 ▪


Aktivity diagram, schématicky postihující danou problematiku, je k dispozici v sekci 4+1 view Procesní pohled.

12.2.6

Usecase pohled – UC-4 Vyhledat výraz v indexu

KRÁTKÝ POPIS Na základě klientem zadaných parametrů systém (server) vyhledá odkazy na artefakty, vyhovující hledanému výrazu a tento seznam vrátí na klienta. PODMÍNKY PRO SPUŠTĚNÍ --ZÁKLADNÍ TOK #

Klient 1

Server

Klient spustí synchronní metodu s parametry, potřebnými k vyhledávání

2

Server přijme parametry od klienta

3

Server z příchozích parametrů vytvoří SolrQuery

4

Spustí se usecase Získat spojení se Search Engine, čímž Server získá odkaz na Search Engine

5

Server odešle na Search Engine SolrQuery, čímž získá SolrResponse

6

Server extrahuje id artefaktů ze SolrResponse do výsledkové sady

7

Server extrahuje max. počet potencionálně nalezených artefaktů ze SolrResponse do výsledkové sady

8

Server vrátí tuto výsledkovou sadu na klienta

9

Klient přijme výsledkovou sadu od serveru a pokračuje ve svém toku use case

Tabulka č. 9 – UC-2, základní tok

▪ 39 ▪


ALTERNATIVNÍ TOKY A1 – Výjimka #

Klient

Server

Tento alternativní tok nastává v kterémkoli kroku základního toku 1

Na serveru je vyvolána výjimka

2

Server propaguje výjimku na klienta

3

Klient přijme výjimku a pokračuje ve svém toku use case

Tabulka č. 10 – UC-2, alternativní tok HLAVNÍ SCÉNÁŘE ZT ZT → A1 PODMÍNKY PO DOKONČENÍ Buď je serverem vrácena na klienta výsledková sada nebo propagována výjimka. SPECIÁLNÍ POŽADAVKY DALŠÍ INFORMACE A DIAGRAMY Aktivity diagram, schématicky postihující danou problematiku, je k dispozici v sekci 4+1 view Procesní pohled.

12.3

Plán cílového řešení

Jelikož se nám bohužel (z růných důvodů zmíněných dále) nepodařilo splnit veškeré požadavky kladené na implementační část navrženého řešení v úvodní analytické části v plné míře, budeme se těmto věnovat alespoň teoreticky v této kapitole. Jedná se zejména o oblast distribuovanosti, oblast jazykové analýzy při indexaci a vyhledávání a také zde zmíníme oblast bezpečnosti.

12.3.1

Jazyková analýza

Jedním z požadavků bylo, aby navržené řešení, kromě jiného, splňovalo také požadavek na podporu vícejazyčnosti. Minimálně se jedná o jazyk anglický, španělský a český. Jazyková analýza může (je to vhodné) probíhat jak při indexaci, tak při vyhledávání (abychom v indexu nalezli opravdu to, co jsme do něj uložili). Jazyková analýza může zajistit takové funkce,

▪ 40 ▪


jakými jsou např. stemování slov, lematizace, převod velkých písmen na malé, využívání synonym a obdobných výrazů, využívání stopwords, atd. Stemování je automatické zkracování slov podle slovních kořenů . Kmen je část slova, která se v různých tvarech tohoto slova opakuje. Výsledné slovo nemusí dávat jazykový smysl. Např. slovo žena – žen, vařit – vaři, atd. [11]. Lematizace je proces, kdy se dané slovo převádí na jeho základní gramatický tvar. Např. slova running, runs – run, stromový, stromy – strom. [10]. Tzv. stopwords jsou slova hojně vyskytovaná, která ovšem pro účel indexace, popř. vyhledávání nejsou důležitá. Jsou to např. a, able, about, above, nebo v češtině dnes, cz, timto. [12]. Nástroj, použitý k fulltextovému vyhledávání má zabudovány možnosti, jak využít možností různých nástrojů (knihoven) pro jazykovou analýzu. Jedná se o nastavení v konfiguračním souboru schema.xml, kde lze nastavit různé filtry a analyzéry pro jednotlivé jazykové verze. Zvažovány byly především dvě knihovny, které poskytují jazykovou analýzu. Knihovna Snowball a knihovna Hunspell. Knihovna Snowball je defaultní knihovnou nástroje ApacheSolr a kromě jazyků, které byly využity v této práci (angličtina a španělština) nabízí mnoho dalších. Bohužel nenabízí anylýzu jazyka českého. Knihovna je do Apache Solr zapojena tak, že její jar soubor je nakopírován do lib adresáře a její použití je nastaveno v již výše zmíněném souboru schema.xml. [8]. Knihovna Hunspell byla původně vyvinuta pro maďarský jazyk a postupem doby se rozvíjela i pro ostatní jazyky, jež neměly takovou podporu. Mezi takové můžeme zařadit i jazyk český.[9]. Knihovna se do prostředí Apache Solr integruje stejně jak je uvedeno u knohovny Snowball, ale navíc je do konfiguračního adresáře nutno nakopírovat dva další soubory. První z nich je pomocný soubor cs_CS.aff, druhým je soubor cs-CS.dic, obsahující pomocný slovník. Bohužel se tuto knihovnu, i za použití návodu, jak použít knihovnu Hunspell v prostředí ApacheSolr [13], nepodařilo

zprovoznit,

proto

bylo

zvoleno

jako

alternativní

řešení

použití

třídy

org.apache.lucene.analysis.cz.CzechAnalyzer, která poskytuje velice slabou funkčnost v oblasti jazykové analýzy, a to pouze využití stopwords. Pro plnohodnotné vyhledávání v českém jazyce v případném produkčním nasazení by tedy bylo nutno zprovoznit funkčnost knihovny Hunspell na Apache Solr, popřípadě využít jiného podobného nástroje pro jazykovou analýzu.

▪ 41 ▪


12.3.2

Bezpečnost

Vzhledem k faktu, že samotná problematika řízení přístupu a zabezpečení je dosti komplexní záležitost (zvláště potom v Unicorn ES), která by mohla být jako taková předmětem samostatné bakalářské práce a hlavním nosným tématem této práce je ověřit užití Apache Lucene pro účely zadavetele, bylo dohodnuto již na konzultacích se zadavetelem, že problematiku bezpečnosti není nutno implementovat. Přesto je jistě vhodné tuto oblast zmapovat alespoň v teoretické rovině a to bude cílem této kapitoly. Nejdříve tedy popíšeme, jakým způsobem je řešena oblast řízení přístupu k informacím v Unicorn ES. Skládá se ze tří základních částí / principů: Teritorium, Security level a Autorizace. Teritorium je jakási vymezená datová oblast, v níž se může uživatel Unicorn ES pohybovat (např. student se pohybuje pouze v rámci teritoria UCL a nedostane se k podnikovým datům z teritoria Unicorn). Přístup uživatele do teritoria se zřizuje pomocí tzv. AccesRole, což je objekt, reprezentující uživatele v teritoriu (uživatel jich má tolik, do kolika teritorií má přístup).

Obrázek č. 15 – Teritorium-1[27]

▪ 42 ▪


Obrázek č. 16 – Teritorium-2[27] Security level klasifikuje každý dokument v systému podle stupně utajení a uživatel, reprezentovaný AccesRolí v daném teritoriu má opět jakýsi stupeň prověření pro přístup k informacím. Tyto dva údaje se při požadavku uživatele na přístup k dokumentu porovnají a přístup je buď povolen, nebo odmítnut.

▪ 43 ▪


Obrázek č. 17 – Security level[27] Předmětem autorizace jsou hned tři záležitosti. Je to role, use case a objekt zájmu role. Neboli jinak řečeno, určitý uživatel se snaží spustit určitou funkčnost nad určitým dokumentem.

Obrázek č. 18 – Autorizace[27] --Výsledné řešení by tedy z pohledu problematiky Teritoria vypadalo asi následovně. Musí zajistit, že uživatel bude hledat jen v Teritoriu, kde má přístup. To bude zajištěno tím, že v indexačním

▪ 44 ▪


dokumentu bude sloupec teritorium, který bude obsahovat označení teritoria, ve kterém se dokument nachází. Volání klienta při indexaci tedy bude navíc obsahovat tento parametr. To samé platí při vyhledávání. Při vyhledávání bude docházet k selekci také podle tohoto kritéria. Výsledné řešení z pohledu Security level by vypadlo následovně. Indexační dokument bude mít navíc sloupec security_level, obsahující stupeň utajení daného dokumentu. Při indexaci přibude tento parametr k ostatním klientským parametrům dané metody. Při vyhledávání klient zadá navíc stupeň svého prověření a následně dojde k porovnání tohoto údaje se stupněm utajení daného dokumentu v indexu. Zpřístupněny budou pouze dokumenty se stejným, nebo nižším stupněm utajení, než je stupeň prověření klienta. Z pohledu Autorizace vyhledávání zde vstupuje do hry autorizace dvou základních práv. Prvním je právo Hledej (zobrazení vyhledávacího formuláře na straně klienta). Toto řeší klientská strana, kde se autorizuje uživatel vůči use case Prohledej teritorium, proto to není předmětem této práce. Druhým právem je právo Hledej a zobraz hledaný objekt. Zde je již situace složitější, protože do hry vstupuje autorizace uživatele, use case a navíc ještě objektu (hledaného dokumentu). Zřejmě se tedy budou porovnávat user_id, usecase_id a object_id (můžeme také chápat jako id dokuemntu v indexu). Z pohledu indexace tedy klient nemusí zadávat další dodatečné informace. Z pohledu vyhledávání klient navíc zašle user_id, usecase_id. Object_id serverová strana načte z vlastního indexu. Průběh vyhledávání na straně serveru tedy bude probíhat tak, že pro každý záznam potencionální výsledkové sady bude serverem volána jakási funkčnost na klintovi, které se předají user_id, usecase_id, object_id a tato funkčnost vrátí logickou hodnotu, na základě které serverová strana tento konkrétní záznam zařadí, popř. nezařadí do výsledné návratové sady pro klienta, potažmo pro konkrétního uživatele.[14].

12.3.3

Distribuovanost

Implementační část této práce obsahuje řešení, které sice ověřuje, že doporučený nástroj Apache Lucene, potažmo Apache Solr je vhodný k fulltextovému vyhledávání dle potřeb zadavatele, ale toto demonstruje pouze řekněme v single-server módu. Plnohodnotným řešením, kterého se v implementační části nepodařilo dosáhnout nástrojem Apache Hadoop (pro jeho netriviální použití a nízkoúrovňové implementaci), by bylo distribuované řešení, jimž se bude, nyní alespoň teoreticky, zabývat tato kapitola. Distribuovaným řešením se má na mysli distribuované úložiště rostoucích dat (indexu), potažmo distribuovanost dalších komponent, spojených s vyhledáváním.

▪ 45 ▪


Samotný Apache Solr nabízí možnosti distribuovaného řešení, založeného, kromě jiného, na replikaci dat[15], distribuovaném vyhledávání[16] a na nástroji, který předešlé integruje[17]. --Replikací se zde míní proces kopírování a udržování instancí jednoho objektu (indexu) na více výpočetních jednotkách (servrech) viz obrázek níže. Replikace může sloužit jednak pro zajištění redundantnosti dat vzhledem k možnému výpadku jednoho zdroje, dále je redundantnost vhodná pro škálovatelnost aplikace při potřebě obsloužení většího počtu příchozích požadavků.

Obrázek č. 19 – Replikace Replikace se nastaví na Master serveru v konfiguračním souboru solrconfig.xml následovně: <requestHandler name="/replication" class="solr.ReplicationHandler" > <str name="replicateAfter">startup <str name="replicateAfter">commit <str name="backupAfter">optimize <str name="confFiles">schema.xml,xyz.txt,xyz.xml <str name="commitReserveDuration">00:00:10

Soubor - solrconfig.xml

▪ 46 ▪


Replikace se nastaví na Slave serveru v konfiguračním souboru solrconfig.xml následovně: <requestHandler name="/replication" class="solr.ReplicationHandler" > <str name="masterUrl">http://master_host:port/solr/corename/replication <str name="pollInterval">00:00:20 <str name="compression">internal <str name="httpConnTimeout">5000 <str name="httpReadTimeout">10000 <str name="httpBasicAuthUser">username <str name="httpBasicAuthPassword">password

Soubor - solrconfig.xml Replikace funguje tak, že Master server neví o Slave serverech, které si opakovaným dotazováním na Master server kontrolují svoji verzi indexu s verzí indexu Master serveru. Pokud má Slave server verzi indexu rozdílnou, spustí proces replikace, který se skládá z: •

Slave server požádá Master server o seznam souborů s pomocnými metadaty

•

Slave server porovná seznam svých lokálních souborů se seznamem od Master serveru a případně si z něj stáhne chybějící soubory (do svého temp adresáře). V případě, že spojení selže, naváže se znovu v bodě předchozího selhání. Toto v případě potřeby proběhne pětkrát, pak by se již proces replikace zastavil.

•

Po úspěšném stažení souborů je Slave server nakopíruje do tzv. živého indexu a upraví svou verzi indexu

•

Slave server provede commit a soubory jsou již připraveny k použití

▪ 47 ▪


Obrázek č. 20 – Časová náročnost replikace[15] --Distribuované vyhledávání se používá v případě, kdy je index příliš velký na to, aby se vešel na jeden server. Z tohoto důvodu se potom tedy indexuje na více serverů (shards). Způsobů jak tohoto dosáhnout je několik. Jedním z nich může být třeba použití proxy serveru, který na principu round-robin příchozí požadavky střídavě posílá na vícero serverů, kde jsou tyto ukládány.

▪ 48 ▪


Obrázek č. 21 – Sharding Podmínkou pro použití distribuovaného vyhledávání na principu Apache Solr je fakt, že id dokumentu v indexu musí být ukládáno (lze nastavit v konfiguračním souboru schema.xml) a dále je nutné zajistit unikátnost id dokumentu v indexu nejenom na daném serveru, ale v rámci všech serverů, na nichž se distribuované vyhledávání realizuje. Implementačně se distribuované vyhledávání realizuje tak, že se vytvoří požadavek na server s parametrem shards, viz. níže. http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/ solr&indent=true&q=ipod+solr

SolrCloud využívá sadu Solr funkcionalit k tomu, aby se distribuované vyhledávání posunulo o řád výše. SolrCloud je nástroj, který je zatím stále ve fázích raného vývoje. SolrCloud využívá Apache Zookeeper[15] ke koordinaci mezi shards a udržování informací o stavu clusteru (virtuálního prostoru). SolrCloud není standardní součástí distribuce Apache Solr. Má svoji vlastní distribuci, obsahující dané funkcionality. SolrCloud má centrální konfigurační soubor, jímž je solr.xml, viz. níže. SolrCloud zde vytvoří jakýsi virtuální prostor (zde collection1) pro celý cluster serverů a dále se zde určí, ve kterém shard daný počítač bude zapojen (zde shard1).

▪ 49 ▪


<solr persistent="false">

Soubor - solr.xml Volání klienta na SolrCloud při indexaci poté může vypadat následovně. Volá se pouze virtuální prostor (collection1) a SolrCloud zajistí vše ostatní. http://localhost:8983/solr/collection1/update

Volání klienta na SolrCloud při vyhledávání poté může vypadat následovně. Parametr distrib=true zajistí, že bude požadavek přenesen na všechny servery ve virtuálním prostoru (collection1). http://localhost:8983/solr/collection1/select?distrib=true&q=*:*

Za pomoci výše zmíněných nástrojů v této kapitole by mělo být možno vytvořit takové řešení, které by bylo dostatečně distribuované, redundantní pro případ výpadku a škálovatelné z důvodu rostoucího počtu jak klientů, tak tím pádem velikosti indexů. Takové řešení by se dalo schématicky zachytit následovně.

▪ 50 ▪


Obrázek č. 22 – Schéma možného distribuovaného řešení Systém se skládá z virtuálního prostoru Collection 1, jež je spravován pomocí Apache Zookeeper a na serveru Collection 1 Manager. Collection 1 Manager_copy je jeho záloha pro zajištění fault tolerance v případě výpadku. Virtuální prostor se skládá z jednotlivých serverů (Server 1, Server 2) a jejich kopií (Replica 1, Replica 2), vytvářených pomocí replikace. Servery jsou uspořádány do logických celků (Shard 1, Shard 2). --Mezi další nástroje, které by mohly být výhledově vhodné pro řešení distribuovaného vyhledávání jsou následující: •

Katta (Zdroj: Seznam použité literatury [19])

•

Elastic Search (Zdroj: Seznam použité literatury [20])

•

Compass (Zdroj: Seznam použité literatury [21])

▪ 51 ▪


13.

IMPLEMENTACE

13.1

Úvod

Nedílnou součástí této bakalářské práce je i CD s implementovanými funkčnostmi, popsanými v předchozích kapitolách. Tato kapitola popíše způsob instalace, spuštění a testování navrženého řešení. Obsahem budou též ukázky zásadní části kódu implementace. V kapitole 4+1 view, konkrétně podkapitola Vývojový pohled, je dostatečně popsána funkčnost jednotlivých tříd navrženého řešení, proto by bylo duplicitní toto zde opětovně uvádět. Zde uvedeme příklady významných částí s ukázkou kódu a s popisným komentářem.

13.1.1

Vytvoření indexační zprávy

Message message; // objekt zprávy jako takový if (deleteIndex == true || deleteAll == true) { message = session.createObjectMessage(null); // pokud mažeme index, neposíláme žádná data k indexaci (vytvoříme prázdnou ObjectMessage s parametrem null) } else { message = session.createObjectMessage(data); // pokud indexujeme (create, update), parametrem, představujícím data k indexaci, je objekt data (pole bytů), zaslaný klientem } // nastavíme id, jméno artefaktu a preferovaný jazyk k indexaci dokumentu. V případě mazání indexu taky parametry mazání (true, false) message.setStringProperty("artId", artId); message.setStringProperty("artName", artName); message.setBooleanProperty("deleteIndex", deleteIndex); message.setBooleanProperty("deleteAll", deleteAll); // uživatelský parametr, využívaný pouze pro účely spouštění testů (hromadné mazání celého indexu) message.setStringProperty("lang", lang);

Soubor – UnicornESClient.java (metoda createMessage)

▪ 52 ▪


13.1.2

Zpracování indexační zprávy

ObjectMessage message = (ObjectMessage) msg; // příchozí zpráva try { SolrServer solr = SolrServerFactory.getServer(); // objekt spojení na Apache Solr boolean deleteIndex = message.getBooleanProperty("deleteIndex"); boolean deleteAll = message.getBooleanProperty("deleteAll"); if (deleteAll == true) { // smažeme celý index solr.deleteByQuery("*:*"); } else { // vytváříme, nebo upravujeme index, popřípadě mažeme index podle id artefaktu String artId = message.getStringProperty("artId"); if (deleteIndex == true) { // mažeme index podle id artefaktu solr.deleteById(artId); } else { // vytvoření a úprava indexu je zde implementačně totožné // získáme data od klienta k indexaci byte[] bytes = (byte[]) message.getObject(); String artName = message.getStringProperty("artName"); lang = message.getStringProperty("lang"); SolrInputDocument solrDoc = new SolrInputDocument(); // objekt, pomocí nějž budeme indexovat solrDoc.addField("id", artId); if (lang != null) { // nastavíme jeden z preferovaných jazyků k indexaci (pokud jej klient zadal) if (lang.equals("en")) { solrDoc.addField("name_en", artName); } else if (lang.equals("es")) { solrDoc.addField("name_es", artName); } else if (lang.equals("cs")) { solrDoc.addField("name_cs", artName); } } solrDoc.addField("name", artName); // vždy zadáme defaultní jazyk (en) pro hledání podle jména artefaktu

▪ 53 ▪


extractTextContentToSolrDocument(bytes, solrDoc); // extrahujeme textový obsah z dat od klienta solr.add(solrDoc); // samotné provedení indexace (až po commitu) } } solr.commit(); } catch (Exception ex) { LOGGER.error(ex.getMessage()); }

Soubor – MyMessgaeConsumer.java (metoda onMessage)

13.1.3

Vyhledávací dotaz na Apache Solr

Vytvoření dotazu a jeho zaslání na server je intuitivní a snadné. Viz. ukázka níže.

QueryResponse response = new QueryResponse(); // Objekt reprezentující odpověď serveru SolrServer solr = SolrServerFactory.getServer(); // získání připojení k serveru SolrQuery solrQuery = new SolrQuery(); // vytvoření objektu dotazu solrQuery.setQuery(query); // vyhledávací dotaz od klienta se nastaví jako parametr solrQuery.setRows(itemsPerResultSet); // nastaví se počet položek, které chceme zobrazit ve výsledkové sadě solrQuery.setStart(resultSetPageNo * itemsPerResultSet – itemsPerResultSet); // nastaví se index položky, která bude první ve výsledkové sadě solrQuery.setParam("fl", "id"); // parametr fl určuje sloupce v indexu, které chceme ve výsledkové sadě vrátit (zde nás zajímá pouze id artefaktu) solrQuery.setSortField("score", SolrQuery.ORDER.desc); // výsledkovou sadu seřadíme podle skóre úspěšnosti hledání response = solr.query(solrQuery); // objekt dotazu se předá jako parametr metody query na objektu, reprezentující připojení k serveru. Návratovou hodnotou je objekt, reprezentující odpověď serveru, nesoucí (kromě jiného) výsledkovou sadu.

Soubor – SearchWS.java (metoda searchItInSolr)

▪ 54 ▪


13.1.4

Zpracování vyhledávací odpovědi Apache Solr

// metoda searchItInSolr vrací odpověď Apache Solr (viz. předchozí kapitola) QueryResponse solrResponse = searchItInSolr(query, itemsPerResultSet, resultSetPageNo); SolrDocumentList solrResult = solrResponse.getResults(); // získáme výsledkovou sadu // abychom odstínili klienta od implementace Apache Solr, získáme z jeho výsledkové sady id artefaktu a vložíme do předem připraveného seznamu (resultSet) for (int i = 0; i < solrResult.size(); i++) { resultSet.add(solrResult.get(i).getFieldValue("id").toString()); } // parametr numFound určuje celkový počet nalezených dokumentů vůbec. Tento parametr také vložíme do seznamu (na index=0). Pro klienta je důležitý stran stránkování. resultSet.add(0, new Long(solrResult.getNumFound()).toString());

Soubor – SearchWS.java (metoda searchFor)

13.1.5

Spuštění, testování výsledného řešení

Struktura CD je popsána v kapitole Seznam příloh → Příloha č. 1 – CD s implementací → Adresář Solr Postup spuštění navrženého řešení (ve formě jUnit testů) je následující (dodržovat pořadí kroků) 1. spustit Message Broker Apache ActiveMQ (AAMQ) 1. spustit soubor AAMQ/bin/activemq.bat (v termínálu stačí napsat „activemq“) 2. spustit Search Engine (SE) 1. spustit soubor SE/example/start.jar (v terminálu napsat „java -jar start.jar“) 3. spustit webový kontejner Apache Tomcat (AT) 1. AT/bin/startup.sh (v terminálu napsat „sh startup.sh“) 4. V Netbeans otevřít projekt UnicornESClient (nastavit mu použití dříve registrovaného serveru Apache Tomcat, popř. namapovat knihovny z CD/Solr/lib) 5. Spustit testovací třídy v balíčku cz.unicorn.test.language.* 1. pravé tlačítko myši → Test File --Popis funkčnosti testovacích tříd je asi následující.

▪ 55 ▪


Každá ze tříd testuje jednu jazykovou verzi. Metoda s anotací @Before zaindexuje testovací data. Metoda s anotací @Test provádí vlastní testování. Na zaindexovaných testovacích datech se spouštějí různé vyhledávací výrazy s cílem demonstrovat hlavně jazykové schopnosti navrženého řešení. Funkčnost vytváření, úpravy, smazání indexu je zřejmé z pomocných oanotovaných metod. Bližší popis je formou komentáře přímo v testovacích třídách. Metoda s anotací @After testovací data z indexu opět smaže.

13.1.6

Spuštění ukázky distribuovanosti

Struktura CD je popsána v kapitole Seznam příloh → Příloha č. 1 – CD s implementací → Adresář SolrCloud. Tato demonstrace distribuovaného řešení je dosti umělá a vychází z tohoto zdroje[17], tím pádem zde nebude detailně opakován postup, jak došlo k dosažení daného stavu instalace (uživatel tohoto příkladu zde nemusí řešit). --Příklad lze spustit následovně (přejít do adresáře ADR a zadat v konzoli příkaz COMM) 1. Server 1 (konzole 1) ◦

ADR = SolrCloud/example

◦

COMM = java -Dbootstrap_confdir=./solr/conf -Dcollection.configName=myconf -DzkRun -jar start.jar

2. Server 2 (konzole 2) 1. ADR = SolrCloud/example 2 2. COMM = java -Djetty.port=7574 -DhostPort=7574 -DzkHost=localhost:9983 -jar start.jar 3. Replica 1 (konzole 3) 1. ADR = SolrCloud/example B 2. COMM = java -Djetty.port=8900 -DhostPort=8900 -DzkHost=localhost:9983 -jar start.jar 4. Replica 2 (konzole 4) 1. ADR = SolrCloud/example2B 2. COMM = java -Djetty.port=7500 -DhostPort=7500 -DzkHost=localhost:9983 -jar start.jar ▪ 56 ▪


--Výše zmíněným postupem se dopracujeme zhruba k následujícímu stavu. Viz. obrázek níže.

Obrázek č. 22 – Schéma možného distribuovaného řešení Viz. http://localhost:8983/solr/admin/zookeeper.jsp. Systém se skládá z virtuálního prostoru Collection 1, jež je spravován pomocí Apache Zookeeper a na serveru Collection 1 Manager. Virtuální prostor se skládá z jednotlivých serverů (Server 1, Server 2) a jejich kopií (Replica 1, Replica 2), vytvářených pomocí replikace. Servery jsou uspořádány do logických celků (Shard 1, Shard 2). Collection 1 Manager_copy je záloha pro zajištění fault tolerance v případě výpadku (na obrázku je, ale v praxi se jej nepodařilo nasimulovat … webový tutorial, tak i celý projekt SolrCloud jako takový je v rané fázi vývoje). Cílem této demonstrace je ukázat možnost distribuovaného vyhledávání. Na adrese http://localhost:7500/solr/collection1/select?distrib=true&q=*:* lze vidět, že virtuální prostor vrátil v jedné výsledkové sadě agregovaný výsledek 2, respektive 4 dotazů na servery ve virtuálním prostoru.

▪ 57 ▪


Dále, pokud některý ze serverů zastavíme (CTRL+C v jeho konzoli), distribuované vyhledávání stále funguje beze změny.

13.1.7

Dodatek

Řešení bylo spouštěno na PC •

Pentium Dual-Core, 2.10GHz

•

RAM 2.00 GB

•

Linux Ubuntu

▪ 58 ▪


14.

ZÁVĚR

V závěru se vypořádáme a shrneme požadavky, definované v úvodní fázi práce a jejich naplnění, plus osobní přínos pro autora. Můžeme říci, že se nám podařilo prověřit využití nástroje Apache Solr, jako Implementace Apache Lucene v procesu indexace a vyhledávání ve třech zvolených jazykových mutacích. Dále se podařilo navrhnout vhodnou formu komunikace mezi klientem a serverem. Ač teoreticky, byly nastíněny důležité body, týkající se bezpečného přístupu k informacím a částečně také nastíněno možné distribuované řešení. Dosažení výše uvedeného bylo realizováno za použití Open Source nástrojů, v převážné míře z rodiny The Apache Software Foundation a ukázková implementace je k dispozici na přiloženém CD. Jednotlivé body jsou níže blíže rozebrány.

14.1

Komunikace

Bylo potřeba vytvořit asynchronní způsob komunikace pro indexaci a synchronní pro vyhledávání. Pro komunikaci klienta se serverem za účelem indexace bylo zvoleno asynchronní zasílání zpráv pomocí Message Broker od Apache ActiveMQ, čímž vzniklo velice flexibilní spojení mezi klientem a serverem, pomocí něhož je možno snadno škálovat počet výpočetních uzlů na straně serveru, které budou přijímat a zpracovávat indexační zprávy. Klient realizuje vyhledávání formou synchronního volání webové služby na serveru s Apache Axis2, což odstiňuje klienta a server od vzájemné vnitřní implementace a závislosti na zvoleném programovacím jazyce.

14.2

Indexování, distribuovanost

Požadováno bylo distribuované řešení ukládání indexu. Je potřeba přiznat, že tuto oblast se nepodařilo uspokojivě vyřešit (zapojit doporučenou knihovnu Apache Hadoop). Ve snaze o eliminaci tohoto nedostatku bylo alespoň teoreticky popsáno možné distribuované řešení pomocí funkčností Apache Solr s demonstrační ukázkou na přiloženém CD.

▪ 59 ▪


14.3

Vyhledávání

Z pohledu vyhledávání bylo potřeba ověřit schopnost použití nástroje Apache Lucene pro účely zadavatele a taktéž byla požadována schopnost provádět i složitější dotazy dle různých kritérií. Za vyhledávací nástroj byl zvolen Apache Solr jako implementace Apache Lucene, který splnil požadované parametry. Vyhledávání lze realizovat dle id, jména, nebo textového obsahu zaindexovaného dokumentu a rozšíření o další vyhledávací kritéria je snadné.

14.4

Vícejazyčnost

Řešení mělo podporovat minimálně jazyk anglický, španělský a český, včetně jejich jazykové analýzy. Co se týká prvních dvou jazyků, můžeme říci, že díky knihovně Snowball, byl tento požadavek splněn, včetně možnosti rozšíření o vícero dalších jazyků. Naopak u jazyka českého se nepodařilo zapojit zamýšlenou knihovnu Hunspell a zůstalo pouze u základní knihovny z rodiny Lucene, jež nabízí pouze užití tzv. stopwords.

14.5

Bezpečnost

Otázka bezpečnosti byla, po konzultaci se zástupcem zadavatele, řešena teoretickou formou, kde byly zmíněny základní aspekty, které je nutno brát do úvahy při případném produkčním nasazení.

14.6

Prototyp

Požadován byl prototyp, prověřující schopnost splnit požadavky zadavatele. Nedílnou součástí této práce je přiložené CD s implementací.

14.7

Open Source řešení

Požadováno bylo Open Source řešení. Drtivá většina použitých nástrojů pochází z produkce The Apache Software Foundation pod licencí ASL 2.0.

▪ 60 ▪


14.8

Osobní přínos

Mezi hlavní osobní přínosy pro autora této práce je možno zahrnout •

samostatná práce dle zadání z praxe, kde není předem jasné a jednoznačné řešení

•

obsáhlé studium předem dosud autorem nezmapovaných technologií

•

čerpání z převážně cizojazyčných zdrojů

•

poučení z (podcenění) netriviálních částí této práce (viz. nedořešená distribuovanost)

▪ 61 ▪


15.

CONCLUSION

At the end we make the conclusion of the satisfaction with the requirements, defined in the previous chapters. We also mention the benefits for the author of this work. We can say, that we proved how to use Apache Solr for indexing and searching in three language mutations. We also designed suitable communication channel both for client and server too. We theoretically mentioned security and distribution topic. All this was realized with Open Source tools, mainly from The Apache Software Foundation family. CD with implementation is included. The details are specified in the chapters below.

15.1

Communication

There was a need of asynchronous communication for indexing and searching. Indexing is realized with asynchronous messages throught the Message Broker from Apache ActiveMQ. This is very flexible solution, which alows easy scalability. Searching is realized with synchronous web service method on the server with Apache Axis2. This solves the problem with dependency on the inner implementation or programming language change.

15.2

Indexing, distributed solution

Distributed storage was requested. It is necessary to admit, that this area was not solved succesfully (include recomended Apache Hadoop library). There was an attempt to eliminate this with theorecically description of the Apache Solr distributed features with some sample demonstration on the enclosed CD.

15.3

Searching

It was necessary to proove, that Apache Lucene is the applicable tool as was requested, plus make multi-criterion search query. As the search engine was selected Apache Solr. The implementation of Apache Lucene. It is possible to query the server with id, name, text content parameter and extend it is quite easy.

▪ 62 ▪


15.4

Multi-language support

Supported languages should be English, Spanish and Czech, including theirs analyse. English and Spanish is suppoerted thanks to the Snowball library. For Czech language was chosen the Hunspell library, but implementation of it was not succesful. The basic Lucene library, but with very poor features (stopwords), was selected to cover this topic in the end.

15.5

Security

After a little bit of conversation with the contractor's representative was agreed, that this topic will be covered only on the theoretical base, which includes basic security aspects description, that has to be taken into account before production deployment.

15.6

Prototype

Prototype should prove ability to fulfil requestor's needs. Prototype is the integral part of this work, enclosed on the CD.

15.7

Open Source solution

Open Source solution was requested. Overwhelming majority of used tools comes from The Apache Software Foundation with ASL 2.0 licence.

15.8

Personal benefits

They are mainly •

the instruction from (undervaluation) non-trivial part of this work (see unsolved distributed solution)

•

individual work according to the true-life demand, with no unique solution in advance

•

big amount of technologies, not awared in advance ▪ 63 ▪


•

mainly foreign information sources

▪ 64 ▪


16.

SEZNAM POUŽITÉ LITERATURY

[1] – Studijní materiál Unicorn College [online], ISA Perzistentní vrstva (str. 20), ISA Úvod do architektury informačních systémů (2009), červenec 2010,dostupné pod: ISA.CZ/LEC05/GL [2] – Index (search engine), Wikipedia [online], červenec 2010, http://en.wikipedia.org/wiki/Search_engine_indexing [3] – McCANDLESS Michael, HATCHER Erik, GOSPODNETIČ Otis, Lucene in Action, Second Edition, Manning Publications Co., květen 2008, ISBN: 1933988177 [4] – SMILEY David, PUGH Eric, Solr 1.4 Enterprise Search Server, Packt Publishing Ltd., srpen 2009, ISBN: 978-1-847195-88-3 [5] – SINGH, Vik, zooie.wordpress.com [online], červenec 2010, http://zooie.wordpress.com/2009/07/06/a-comparison-of-open-source-search-engines-andindexing-twitter/ [6] - MIDDLETON, Christian, BAEZA-YATES Ricardo, A Comparison of Open Source Search Engines [online], červenec 2010, http://wrg.upf.edu/WRG/dctos/Middleton-Baeza.pdf [7] - RUSSAKOVSKII, Artem, beerpla.net [online], červenec 2010, http://beerpla.net/2009/09/03/comparison-between-solr-and-sphinx-search-servers-solr-vs-sphinxfight/ [8] – Snowball [online], srpen 2010, http://snowball.tartarus.org/ [9] – Hunspell [online], srpen 2010, http://hunspell.sourceforge.net/ [10] – Vydavatelství VSCHT [online], http://vydavatelstvi.vscht.cz/knihy/uid_es005/hesla/lematizace.html [11] – Vydavatelství VSCHT [online], srpen 2010, http://vydavatelstvi.vscht.cz/knihy/uid_es005/hesla/stemming.html [12] – Stopwords, Wikipedia [online], červenec 2010, http://en.wikipedia.org/wiki/Stop_words [13] – Robert Muir's blog [online], červenec 2010, minority language support for lucene and solr, http://rcmuir.wordpress.com/2010/03/02/minority-language-support-for-lucene-and-solr/ [14] – Portál bakalářských prací Unicorn College[Miroslav Škařupa] [online], Meet 02 - UCL, Škařupa Miroslav, Buchlák Peter, (Ciochoň Petr) - BPUES_LUCENE, ISA Úvod do architektury informačních systémů (2010), červenec 2010, dostupné pod: ucla013.BT/MEET02 [15] – SolrReplication, Solr Wiki [online], červenec 2010, http://wiki.apache.org/solr/SolrReplication

▪ 65 ▪


[16] – DistributedSearch, Solr Wiki [online], červenec 2010, http://wiki.apache.org/solr/DistributedSearch [17] – SolrCloud, Solr Wiki [online], červenec 2010, http://wiki.apache.org/solr/SolrCloud [18] – Apache Zookeeper [online], červenec 2010, http://hadoop.apache.org/zookeeper/ [19] – Katta [online], červenec 2010, http://katta.sourceforge.net/ [20] – Elastic Search [online], srpen 2010, http://www.elasticsearch.com/ [21] – Compass [online], červen 2010, http://www.compass-project.org/overview.html [22] – Ubuntu [online], srpen 2010, http://www.ubuntu.cz/ziskejte/stahnout [23] – www.troubleshooters.com, Adding a Directory to the Path [online], srpen 2010, http://www.troubleshooters.com/linux/prepostpath.htm [24] – How to set JAVA_HOME [online], srpen 2010, http:///bbs/html/oss/236.html [25] – Hadoop [online], květen 2010, http://hadoop.apache.org/ [26] – 4.bp.blogspot.com [online], Hadoop Map / Reduce Implementation, červenec 2010, http://horicky.blogspot.com/2008/11/hadoop-mapreduce-implementation.html [27] – Komunikace se zástupcem zadavatele [online], Meet 02 - UCL, Škařupa Miroslav, Buchlák Peter, (Ciochoň Petr) - BP-UES_LUCENE (2010), červenec 2010, dostupné pod: ucla013.BT/MEET02 [28] – Wikipedia [online], Inverted

index, srpen 2010, http://en.wikipedia.org/wiki/Inverted_index

▪ 66 ▪


17.

SEZNAM POUŽITÝCH SYMBOLŮ A ZKRATEK

Zkratka

Popisek

zadavatel

Unicorn a.s.

Unicorn ES

Unicorn Enterprise System – informační systém pro řízení klíčových firemních procesů

UC

Use Case – případ užití

FSE

Fulltext Search Engine – označení nově navrhovaného řešení v tomto dokumentu

Tabulka č. 11 – Seznam použitých symbolů a zkratek

▪ 67 ▪


18.

SEZNAM TABULEK

Tabulka č. 1 – Forward index[2], upraveno Tabulka č. 2 – Inverted index[2], upraveno Tabulka č. 3 – Klíčoví uživatelé[27] Tabulka č. 4 – Funkční požadavky[27] Tabulka č. 5 – Nefunkční požadavky[27] Tabulka č. 6 – Popis usecase Tabulka č. 7 – UC-1, základní tok Tabulka č. 8 – UC-1, alternativní tok Tabulka č. 9 – UC-2, základní tok Tabulka č. 10 – UC-2, alternativní tok Tabulka č. 11 – Seznam použitých symbolů a zkratek

▪ 68 ▪


19.

SEZNAM OBRÁZKŮ

Obrázek č. 1 – Princip fungování fulltextového vyhledávání[1] Obrázek č. 2 – Kompetence Lucene5[3] Obrázek č. 3 – HDFS architektura[25] Obrázek č. 4 – MapReduce[26] Obrázek č. 5 – High level pohled Obrázek č. 6 – Komponenty Obrázek č. 7 – Use case diagram Obrázek č. 8 – Domain diagram – index Obrázek č. 9 – Class diagram – UnicornESToSolrAdapter.cz.skarupa.mirek.index Obrázek č. 10 – Class diagram – UnicornESToSolrAdapter.cz.skarupa.mirek.search Obrázek č. 11 – Class diagram – UnicornESToSolrAdapter.cz.skarupa.mirek.solr Obrázek č. 12 – Activity diagram – indexace Obrázek č. 13 – Activity diagram – hledání Obrázek č. 14 – Deployment diagram Obrázek č. 15 – Teritorium-1[27] Obrázek č. 16 – Teritorium-2[27] Obrázek č. 17 – Security level[27] Obrázek č. 18 – Autorizace[27] Obrázek č. 19 – Replikace Obrázek č. 20 – Časová náročnost replikace[15] Obrázek č. 21 – Sharding Obrázek č. 22 – Schéma možného distribuovaného řešení

5

- Kompetence Lucene, šedě zabarvené součásti jsou v kompetenci Lucene ▪ 69 ▪


20.

SEZNAM PŘÍLOH

20.1

Příloha č. 1 – CD s implementací

CD s implementací je přiloženo v zadní části této bakalářské práce CD obsahuje celkem 3 adresáře •

SW – obsahuje potřebný software

•

Solr – hlavní část, obsahující klientskou a serverovou část navrženého řešení

•

SolrCloud – samostatná provizorní ukázka distribuovaného řešení pomocí SolrCloud

20.1.1

Adresář SW

Obsahuje •

Apache Tomcat – webový kontejner (INSTALACE HOTOVÁ)

•

Apache ActiveMQ – zajišťuje messaging (INSTALACE HOTOVÁ)

•

Apache Solr – indexovací a vyhledávací nástroj (INSTALACE HOTOVÁ)

•

Apache Ant – buildovací nástroj (INSTALACE HOTOVÁ)

•

Apache Axis2 – zajišťuje webové služby (INSTALACE HOTOVÁ)

•

Java (JDK, JRE) (INSTALACE)

•

Netbeans 6.9 – vývojové prostředí (INSTALACE). Po instalaci je potřeba přes GUI průvodce Netbeans stáhnout plugin axis2 a registrovat Apache Tomcat jako server v Netbeans.

•

Linux Ubuntu – je možno stáhnout[22] (INSTALACE)

Tyto programy je potřeba nainstalovat (programy s poznámkou INSTALACE) a případně nastavit systémovou proměnnou PATH a home directory[23], [24].

20.1.2

Adresář Solr

Obsah adresáře •

Solr/lib – odtud se načítají potřebné knihovny

▪ 70 ▪


•

Solr/UnicornESClient – klientská část, představující server Unicorn ES

•

Solr/UnicornESToSolrAdapter – serverová část, představující navržené řešení ---

Klientská část kromě jiného, obsahuje důležité balíčky (třídy) •

META-INF.wsdl.localhost_8080.UnicornESToSolrAdapter – wsdl soubor webové služby

•

cz.unicorn.fulltextHandling.UnicornESClient – hlavní klientská třída, která indexuje dokumenty a vyhledává v indexu.

•

cz.unicorn.test.language.* - obsahuje třídy s JUnit testy pro každý z podporovaných jazyků

•

javadoc – v adresáři dist

Serverová část kromě jiného, obsahuje důležité balíčky (třídy) •

cz.skarupa.mirek.index.* – třídy zajišťující indexaci dokumentů

•

cz.skarupa.mirek.search.* - třídy zajišťující vyhledávání v indexu

•

cz.skarupa.mirek.solr.* - třídy zajišťující spojení se Search Engine

•

javadoc – v adresáři dist

20.1.3

Adresář SolrCloud

V adresáři SolrCloud je obsažena distribuce Apache Solr pro distribuované řešení. Předpokládáme zde již nainstalované nástroje JAVA (JDK, JRE).

▪ 71 ▪

BAKALÁŘSKÁ PRÁCE. Fulltextové vyhledávání v Unicorn ES pomocí Lucene. Fulltext searching in Unicorn ES by Lucene. Miroslav Škařupa

Recommend Documents