Fulltextové vyhledávání v Unicorn ES pomocí Lucene

Transkript

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
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 ▪
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).
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</listener-class>
<load-on-startup>1</load-on-startup>
</listener>
▪ 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
▪ 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
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 ▪
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" >
<lst name="master">
<str name="replicateAfter">startup</str>
<str name="replicateAfter">commit</str>
<str name="backupAfter">optimize</str>
<str name="confFiles">schema.xml,xyz.txt,xyz.xml</str>
<str name="commitReserveDuration">00:00:10</str>
</lst>
</requestHandler>
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" >
<lst name="slave">
<str name="masterUrl">http://master_host:port/solr/corename/replication</str>
<str name="pollInterval">00:00:20</str>
<str name="compression">internal</str>
<str name="httpConnTimeout">5000</str>
<str name="httpReadTimeout">10000</str>
<str name="httpBasicAuthUser">username</str>
<str name="httpBasicAuthPassword">password</str>
</lst>
</requestHandler>
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">
<cores adminPath="/admin/cores" defaultCoreName="collection1">
<core name="collection1" instanceDir="." shard="shard1"/>
</cores>
</solr>
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
start.jar
4. Replica 2 (konzole 4)
1. ADR = SolrCloud/example2B
start.jar
▪ 56 ▪
--Výše zmíněným postupem se dopracujeme zhruba k následujícímu stavu. Viz. obrázek níže.
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 č. 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 č. 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 č. 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
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 ▪

Fulltextové vyhledávání v Unicorn ES pomocí Lucene

Transkript

Podobné dokumenty

lukas_krecan_spring

videotelefon 4FP 211 04, 05 - Tesla Stropkov

oznámení_Krematorium Hýskov

Novinky ze sv¥ta grid

UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

JMS

Recenzovaný vědecký časopis / Peer

informace pro uživatele software Esri Digitální mapa veřejné správy

Prezentace ke stažení [PDF - 837 kB]

Kanonizace MathML pro vyhledávání matematiky

Formát PDF

Workshop Perspektivní projekty vývoje řídicích a senzorických