Masarykova univerzita Fakulta informatiky
Indexovanie v dokumentoch pomocou platformy Apache Solr
Bakalárska práca
Martin Kuchár
Brno, jar 2017 Vyhlásenie vyhlasujem, že táto bakalárska práca je mojím pôvodným autorským dielom, ktoré som vypracoval samostatne. Všetky zdroje, pramene a literatúru, ktoré som pri vypracovaní používal alebo z nich čerpal, v práci riadne citujem s uvedením úplného odkazu na príslušný zdroj.
Martin Kuchár
Vedúci práce: RNDr. Jaroslav Bayer
i Poďakovanie
Týmto by som sa chcel poďakovať hlavne za trpezlivosť pri samotnom výbere témy, ako aj za poskytnuté návrhy na vylepšenie vedúcemu práce Jaroslavovi Bayerovi, celej rodine, ktorá ma podporovala po- čas celého štúdia, no najmä rodičom. Ďalej veľká vďaka patrí mojej priateľke, ktorá ma podporila aj v časoch, keď to sama nemala ľahké. Najväčšia vďaka však patrí kolegom z firmy Siemens Healthcare s.r.o., ktorí mi umožnili vypracovanie tejto témy, menovite Alexander Roth, a za postrehy a návrhy na spôsob práce Erikovi Kudrovi, Marekovi Višnovskému a kolegyni z Nemecka, Tatjane Rehfeldt.
ii Zhrnutie
Práca sa zaoberá možnosťou vyhľadávania dokumentov z medicín- skeho prostredia pomocou nástroja Apache Solr. V teoretickej časti práce sa zaoberám problematikou fulltextového vyhľadávania, význa- mom a spôsobmi indexovania. Stručne sú zhrnuté najväčšie problémy pri fulltextovom vyhľadávaní. Ďalej sa práca zaoberá možnosťami ná- stroja Apache Solr, jeho históriou a spôsobmi nasadenia. V praktickej časti práce je riešená analýza dát, ich mapovanie na Solr, konfigurácia samotného nástroja ako aj návrh komunikácie so Solr z klientskej apli- kácie, pre ktorú je riešenie poskytnuté. Riešenie je vypracované pre spoločnosť Siemens Healtcare s.r.o.
iii Kľúčové slová
Apache Solr, Apache Lucene, fulltextové vyhľadávanie, indexovanie, invertovaný index, Service Knowledge Base
iv Obsah
1 Úvod 1
2 Fulltextové vyhľadávanie v Apache Solr 3 2.1 Základné pojmy ...... 3 2.2 Klientska aplikácia ...... 4 2.3 Požiadavky riešenia ...... 4 2.3.1 Triedenie výsledkov ...... 4 2.3.2 Zdroje prehľadávaného textu ...... 5 2.3.3 Rôzne váhy informácií v dokumente ...... 5 2.3.4 Používanie synoným ...... 5 2.3.5 Filtrovanie ...... 6 2.3.6 Používanie logických operátorov ...... 6 2.3.7 Používanie zástupných znakov ...... 6 2.3.8 Počty dokumentov v jednotlivých kategóriách .6 2.3.9 Budovanie indexu ...... 6 2.3.10 Ostatné požiadavky ...... 7
3 Problematika fulltextového vyhľadávania 8 3.1 Indexovanie ...... 8 3.1.1 Význam indexovania ...... 8 3.1.2 Príklad záznamu v invertovanom indexe . . . . 10 3.2 Problém relevantnosti výsledkov ...... 12 3.2.1 Precision a recall ...... 12 3.2.2 False-positive a false-negative problém . . . . . 13 3.2.3 Softvér poskytujúci fulltextové vyhľadávanie . . 13
4 Apache Solr 16 4.1 História Apache Solr ...... 16 4.2 Apache Lucene ...... 17 4.3 Možnosti Solr ...... 18 4.4 Administrátorské rozhranie Solr ...... 19 4.5 Softvérové riešenia integrujúce Apache Solr ...... 19
5 Analýza problému 21 5.1 Dáta dostupné z aplikácie ...... 22 5.1.1 Súbory nevhodné na indexovanie ...... 23
v 5.1.2 Textové dáta vhodné pre indexovanie ...... 23 5.2 Analýza dát pre fulltextové vyhľadávanie ...... 24 5.2.1 Štruktúra dokumentov ...... 24 5.2.2 Štruktúra príloh ...... 26
6 Riešenie problému 27 6.1 Indexy ...... 27 6.1.1 SKBOffline Index ...... 28 6.1.2 SKBOfflineAttachments Index ...... 28 6.2 Konfigurácia jadier Solr ...... 28 6.2.1 Dopady rôznych nastavení na možnosti Solr . . 29 6.2.2 SKBOffline ...... 30 6.2.3 SKBOfflineAttachments ...... 33 6.3 Návrh komunikácie so systémom ...... 34 6.3.1 Kedy indexovať ...... 35 6.3.2 Kedy získavať potrebné informácie pre užívateľ- ské rozhranie ...... 37
7 Vyhodnotenie riešenia 39 7.1 Tvorba dotazníku ...... 39 7.2 Výsledky dotazníku a ich vyhodnotenie ...... 40
8 Záver 43
Bibliografia 44
vi Zoznam obrázkov
3.1 Grafické znázornenie false-positives a false-negatives a grafická reprezentácia vzorcov pre precision aj recall [15] 14 4.1 Ukážka administrátorského rozhrania Apache Solr 20 6.1 Zhrnutie dostupných možností a ich dôsledkov na funkcionalitu Solr podľa prípadov užitia [25] 30 6.2 Dotaz na Solr s viditeľnou URL, na ktorej je prístupný samotný vrátený objekt 35 6.3 Samostatná odpoveď serveru Solr na dotaz 36 6.4 Použitie fazetového vyhľadávania pre získanie počtov dokumentov jednotlivých typov 38 7.1 Spracované výsledky dotazníku v tabuľkovej aj grafickej podobe 42
vii 1 Úvod
Dátami môžeme označiť už prvé nástenné maľby z jaskýň po celom svete či hieroglyfy z Egypta. Ako sa ľudstvo postupne vzdelávalo a rozširovalo svoje poznatky, začali sa množiť aj zápisky o týchto po- znatkoch – dáta. Ľudia však najprv museli vedieť, kde aké informácie nájdu, čo bolo veľmi obtiažne. Fakt, že súbor informácií sa rozrastal spôsobil, že to za relatívne krátky čas nebolo možné. V knižkách sa za- čali na zadných stranách objavovať registre slov, v úvodných stránkach zas obsah kníh podľa logických celkov. Knihy zas boli združované podľa tematiky, neskôr v knihovniach podľa abecedy, autorov, roku vydania a podobne [1]. Prišla éra zjavnej snahy ľudí zadeliť informácie – dáta tak, aby bolo možné ich ľahšie a rýchlejšie nájsť. S príchodom počítačov sa objem dát začal zväčšovať doposiaľ nevídanou rýchlosťou, a bolo potrebné, aby sme sa my, ľudia, vedeli v týchto dátach oriento- vať. Najjednoduchším a najrýchlejším spôsobom orientácie v dátach je vyhľadávanie v nich. Rýchlo sme si však uvedomili, že hľadať niečo konkrétne vo všetkých dostupných dátach je príliš neefektívne, ne- potrebné a zdĺhavé. Bolo tak treba prísť s niečím, čo by nám uľahčilo a urýchlilo vyhľadávanie vo veľkých množstvách textov najprv lo- kálne na našich počítačoch, a po rozšírení internetu aj v textoch po celej dostupnej sieti. Už v roku 1968 profesor Gerard Salton prišiel so systémom na mechanickú analýzu a získavanie textu, vymyslel vekto- rový priestorový model – spôsob indexovania a hľadania podobného obsahu a v roku 1975 prišiel s teóriou indexovania. Je považovaný za otca automatickej organizácie a získavania textov [2]. Schopnosť vyhľadať pre nás relevantné dáta za dostatočne krátky čas je pre nás neodmysliteľnou súčasťou našich životov. Problém, ktorým sa budem zaoberať, priamo súvisí s vyhľadáva- ním dát a informácií. V rámci spoločnosti Siemens Healthcare, s.r.o., pre ktorú bude popisované riešenie, sa budem zaoberať schopnosťou cieľových užívateľov vyhľadávať konkrétne dáta, s prihliadnutím a za- pracovaním požiadaviek zákazníka, respektíve firmy. Témou práce je vyhľadávanie v manuáloch a technických špecifikáciách k softvéru a hardvéru, ktorý vyrába koncern Siemens. Jedná sa o „Service Kno- wledge Base“ aplikáciu, ktorej ideou je možnosť vyhľadávania v doku- mentoch a prílohách off-line. Interný používatelia systému, respektíve
1 1. Úvod
systémov, v prípade akýchkoľvek problémov alebo nezrovnalostí, po zadaní kľúčových slov do vyhľadávania budú schopní nájsť či už rieše- nie problému alebo aspoň jeho príčinu, všetko na základe dostatočne relevantných výsledkov z ich vyhľadávania. Vo svojej práci predstavím tematiku skúmaného problému, uve- diem základné pojmy s ktorými sa budem v texte zaoberať, ďalej pred- stavím požiadavky na riešenie určené firmou, respektíve zákazníkom. V teoretickej časti sa pokúsim zanalyzovať a rozpracovať problematiku fulltextového vyhľadávania, aké problémy pri ňom vznikajú, či a ako sú riešiteľné alebo eliminovateľné a rozoberiem princíp a dôležitosť indexovania dát pre účely vyhľadávania. Predstavím tiež systém Apa- che Solr, jeho použitie, výhody a nevýhody, možnosti a funkcionalitu, pokúsim sa predstaviť ako a prečo vznikol, ako aj v akom štádiu je v dnešných dňoch a akú má možnú budúcnosť. V praktickej časti po- tom preskúmam, akým spôsobom bude klientska aplikácia získavať údaje, kedy a ktoré z týchto údajov zahrniem do procesu indexovania v Solr za účelom vyhľadávania. Zanalyzujem štruktúru dát určených pre Solr, na ich základe navrhnem a implementujem schému Solr, celý systém nakonfigurujem a pripravím pre použitie z klientskej aplikácie a pokúsim sa navrhnúť, kedy dáta indexovať v kontexte synchroni- zácie, a akým spôsobom komunikovať so Solr z aplikácie. Nakoniec riešenie nechám otestovať a vyhodnotím.
2 2 Fulltextové vyhľadávanie v Apache Solr
Táto kapitola predstavuje najdôležitejšie základné pojmy z terminoló- gie z oblasti vyhľadávania, s ktorými budem pracovať, a stručný popis požiadaviek na riešenie stanovené firmou.
2.1 Základné pojmy
Apache Solr: Solr je rýchla populárna podniková vyhľadávacia plat- forma s verejným zdrojovým kódom. Pochádza z projektu Apache Lucene. Je písaný v jazyku Java a je spustiteľný ako samostatná serve- rová aplikácia. Je postavený na knižnici Lucene pre fulltextové inde- xovanie a vyhľadávanie, používa json a http/xml aplikačné rozhranie. Vďaka týmto vlastnostiam je ľahko použiteľný z takmer akéhokoľvek programovacieho jazyku [3].
Apache Lucene: Lucene je vysoko výkonná knižnica používaná ako textový vyhľadávací nástroj napísaný v jazyku Java. Je to technológia vhodná pre takmer akúkoľvek aplikáciu vyžadujúcu fulltextové vy- hľadávanie. Veľkou výhodou je podpora multiplatformových riešení. Rovnako ako Apache Solr, Lucene má verejný zdrojový kód [4].
Index: Index, alebo indexovanie, sa vzťahuje k organizácii dát, pri- čom prebieha podľa špecifickej schémy, plánu alebo vzoru. Výraz sa- motný má viacero významov, najvýstižnejší však je, že sa snaží docieliť, aby boli informácie lepšie prezentovateľné a prístupnejšie. Efektívne indexovanie má za následok, že vyhľadávanie je menej náročné na výkon a zároveň ho urýchli [5].
Fulltextové vyhľadávanie: Fulltextové vyhľadávanie je technika na hľadanie informácií v neštruktúrovaných textoch v digitálne uchova- ných dokumentoch. Fulltextové vyhľadávanie sa líši od klasických vyhľadávacích techník, keďže sa nezameriava na obdržanie štruktúro- vaných údajov z relačnej databázy, ako napríklad nadpisy, abstrakty, alebo bibliografické referencie [6].
3 2. Fulltextové vyhľadávanie v Apache Solr 2.2 Klientska aplikácia
Aplikácia, do ktorej bude riešenie fulltextového vyhľadávania pomo- cou nástroja Apache Solr integrované, sa nazýva KB2GO1. Jedná sa o internú offline, respektíve desktopovú aplikáciu pre koncern Sie- mens. Jej účelom je umožniť rýchle hľadanie a riešenie problémov so zariadeniami vyrábanými na lekárske účely ich obsluhe, technickým pracovníkom a ľudom, ktorí s nimi pravidelne prichádzajú do styku ako zamestnanci. Patria medzi nich okrem iného rôzne ultrazvukové sondy, CT prístroje, MR zariadenia a podobne. Technici v extrémnych prípadoch práce v teréne bez dostupnosti siete budú môcť prostredníc- tvom firemného počítača s nainštalovanou aplikáciou riešiť problém s príslušným zariadením priamo na mieste a sami. Požiadavky na možnosti aplikácie, jej celkový dizajn, a pre mňa dôležité možnosti vyhľadávania sú inšpirované webovou aplikáciou SKB2 Online, ktorej databáza slúži ako zdroj dát pre KB2GO. Z dô- vodu závislosti na dátach z online databázy, a faktu, že SKB Online integruje Apache Solr pre správu a vyhľadávanie dát, zameriam sa pri implementácii práve na Solr a pokúsim sa poskytnúť požadované riešenie za použitia Solr.
2.3 Požiadavky riešenia
Nasleduje prehľad požiadaviek na riešenie. Jeho úlohou je iba infor- movať o požadovanom správaní, nie popísať technologické detaily alebo bližšie vysvetliť vlastnosti používaného softvéru. Tie je možné nájsť v kapitole 4 popisujúcej systém Apache Solr a možnosti, ktoré poskytuje.
2.3.1 Triedenie výsledkov Jednou z požiadaviek je podpora triedenia výsledkov podľa viacerých kategórií. Každá z nich sa bude dať zoradiť zostupne aj vzostupne. Kategórie, podľa ktorých radiť, sú:
1. KB2GO je skrátením Knowledge Base to go, teda naznačuje typ desktopovej aplikácie, ktorá nepotrebuje nepretržité internetové pripojenie pre funkčnosť. 2. Service Knowledge Base
4 2. Fulltextové vyhľadávanie v Apache Solr
∙ názov vráteného dokumentu (abecedne),
∙ počet otvorení dokumentu,
∙ relevantnosť dokumentu (štandardné triedenie),
∙ dátum publikácie dokumentu,
∙ dátum poslednej úpravy dokumentu,
∙ hodnotenie.
2.3.2 Zdroje prehľadávaného textu
Okrem už zmienených dokumentov máme k dispozícii aj prílohy, ktoré treba tiež spracovať. Tie sami o sebe neexistujú, sú súčasťou dokumentov. Výsledky vrátené systémom Solr pre hľadaný výraz, ktorý zadal užívateľ, musia obsahovať ako dokumenty s prílohami, v ktorých sa výraz našiel, tak aj dokumenty, ktoré síce hľadaný výraz neobsahujú, ale obsahujú ho ich prílohy.
2.3.3 Rôzne váhy informácií v dokumente
Ďalšou požiadavkou je možnosť určovania váh informácií v rôznych poliach, anglicky boosting. Pre lepšie pochopenie, uvážme nasledovné. Nech štandardné triedenie výsledkov prebieha podľa relevantnosti, bo- osting je aktívny a nastavený tak, že zhoda hľadaného výrazu v názve dokumentu má väčšiu váhu ako v jeho tele, potom dokument so zho- dou v názve bude vrátený ako relevantnejší oproti druhému.
2.3.4 Používanie synoným
Pre hľadaný výraz musí vyhľadávanie vrátiť aj výsledky obsahujúce synonymá daného výrazu na základe synonymického slovníku. Za týmto účelom je potrebné použiť synonymický slovník podľa špecifi- kácie formátu pre Solr.
5 2. Fulltextové vyhľadávanie v Apache Solr
2.3.5 Filtrovanie
Užívateľ musí byť schopný odfiltrovať nežiadúce dokumenty, a to tak, že si bude môcť zvoliť kategóriu (typ) dokumentov, v ktorých chce vy- hľadávať, produkty, ku ktorým patriace dokumenty chce prehľadávať, verzie softvéru, ak sú dostupné a podobne.
2.3.6 Používanie logických operátorov
Užívateľovi by malo byť umožnené použiť medzi jednotlivými vý- razmi logické operátory AND, OR a NOT, pričom štandardný je AND. V jednoduchosti, pri hľadaní „výraz1 výraz2“ vráti Solr vý- sledky obsahujúce prvý a druhý výraz súčasne (AND logika), pri hľadaní „výraz1 OR výraz2“ vráti dokumenty obsahujúce prvý alebo druhý výraz a hľadanie „výraz1 NOT výraz2“ vráti výsledky obsahu- júce „výraz1“ a neobsahujúce „výraz2“.
2.3.7 Používanie zástupných znakov
Zástupný znak, anglicky wildcard, znamená, že za takýto znak môže systém podľa nastavenia doplniť nula, jeden alebo viacero rôznych znakov. V tomto prípade sú požadované zástupné znaky „?“ a „*“ pre doplnenie jedného, respektíve ľubovoľného počtu znakov.
2.3.8 Počty dokumentov v jednotlivých kategóriách
Fazety, anglicky facets, sú údaje o príslušnosti dokumentov do istých, predom definovaných kategórií. Požiadavka je, aby užívateľ v užívateľ- skom rozhraní pri filtroch typov dokumentov videl počty dokumentov pre danú kategóriu.
2.3.9 Budovanie indexu
Po každej synchronizácii dát musí byť vybudovaný nový index ob- sahujúci najnovšie zmeny, teda všetky pridané dokumenty, zmeny všetkých menených dokumentov, a naopak, už nesmie obsahovať do- kumenty synchronizáciou vymazané.
6 2. Fulltextové vyhľadávanie v Apache Solr
2.3.10 Ostatné požiadavky Zvyšné požiadavky zahŕňajú istotu rovnakého výsledku dotazu majú- ceho pri čísle na začiatku nulu, ako keby tam táto nula, prípadne viac núl, nebola. V praxi to znamená, aby vyhľadávanie pre výraz „error 010“ a „error 10“ vrátilo rovnaké výsledky. V neposlednom rade to je zvýrazňovanie, anglicky highlighting, hľadaných výrazov a ich synoným vo vrátených výsledkoch.
7 3 Problematika fulltextového vyhľadávania
Fulltextové vyhľadávanie môže fungovať na dvoch princípoch. V prí- pade, že obstarávame malé množstvo dát, respektíve dokumentov, alebo dokonca iba jeden dokument, pri každom dotaze od užívateľa je zvykom spracovať text celého dokumentu. Tento prístup je veľmi neefektívny v prípade, že spracovávaný dokument má stovky či do- konca tisícky stránok, poprípade sa dá očakávať výrazne vysoký počet dokumentov, v rámci ktorých bude vyhľadávanie prebiehať. V takom prípade najskôr prebieha spracovanie dokumentov a ich značkova- nie (indexovanie) a po dotaze od užívateľa vyhľadávanie prebieha vo vybudovanom indexe, nie dokumentoch samotných [6][7].
3.1 Indexovanie
Problematika indexovania bola zhrnutá vo viacerých prácach, naprí- klad [7][8]. V nasledujúcich riadkoch sa pokúsim priblížiť základné princípy a problémy indexovania, v akých prípadoch vhodný je, v akých zas nie. Pre podrobnejšie informácie neváhajte nahliadnuť do vyššie zmieňovaných prác.
3.1.1 Význam indexovania Pri riešení, aký softvér na vyhľadávanie použiť, môže byť, a do značnej miery by aj mal byť, výrazným faktorom jazyk. To, v akom jazyku bude vyhľadávanie prebiehať, a teda jazyk, v akom sú dokumenty, ovplyvňuje použitý softvér. Väčšina nástrojov podporuje bez prob- lémov anglický jazyk, v prípade nutnosti používania iného jazyku (napríklad aj toho slovenského) treba overiť, či daný nástroj ten ktorý jazyk podporuje, a ak nie, zvoliť buď iný nástroj alebo preferovaný rozšíriť. V prípade prehľadávania veľkého množstva dokumentov je pre- hľadávanie hrubou silou, teda sekvenčne, veľmi neefektívne, ako už bolo spomenuté. Tento prístup je časovo náročný a s časovou zložitos- ťou 풪(n) nie príliš efektívny. Po prevedení dát do formy vhodnej pre vyhľadávanie môžeme tento čas výrazne skrátiť. Keď sú všetky dáta, nad ktorými bude prebiehať vyhľadávanie, uložené v indexe, vieme
8 3. Problematika fulltextového vyhľadávania
dosiahnuť až logaritmickú zložitosť 풪(log n) čo je výrazné urýchlenie operácií spojených s vyhľadávaním nad dátami. Je však treba mať na pamäti udržiavanie aktuálnosti indexu voči dátam a tiež priestorovú, respektíve pamäťovú náročnosť. S pamäťovou náročnosťou na index prichádza otázka, či sa index naozaj oplatí. Vo väčšine prípadov naozaj ide o urýchlenie práce nad dátami, a čas a priestor, ktorý zaberá vytváranie indexu, je akceptova- teľný vzhľadom k ušetrenému času počas vyhľadávania. Môže však nastať situácia, keď možnosť vyhľadávania nad dátami je iba sekun- dárna a nie je očakávané, že bude využívaná frekventovane. V takomto prípade, ešte v kombinácii s faktom, že dáta by boli často upravované, menené, mazané alebo pridávané, indexovanie nie je rozumné. Po každej takejto zmene by musel byť prebudovaný index, čo zaberá veľa času, a pokiaľ je vyhľadávanie nad danými dátami zriedkavé, je prijateľnejšie mať vyhľadávanie o zložitosti 풪(n). Čo sa týka priestoru zabraného indexom, pokiaľ je index priveľký na držanie v operačnej pamäti systému, je udržiavaný na pevnom disku, čo pri frekventovanom vyhľadávaní spôsobuje časté operácie prístupu na disk, ktoré sú relatívne pomalé (oproti prístupom do ope- račnej pamäte). Taká situácia je riešiteľná takzvaným viacúrovňovým indexom, ktorý redukuje počet prístupov na disk pri vyhľadávaní a teda dané vyhľadávanie zrýchľuje. Čas prístupu na disk a nahratie dát do operačnej pamäti je totiž rádovo niekoľkokrát vyšší ako práca v rámci operačnej pamäte. Ďalšou možnosťou, ako zredukovať vybudovaný index, je odstraňo- vanie formátovacích značiek z textu. Napríklad pri indexovaní obsahu webových stránok má často text pri sebe formátovacie značky použí- vané jazykom HTML, podobne dokumenty používajúce značkovací jazyk xml. Pre užívateľa hľadajúceho konkrétnu informáciu v takýchto textoch formátovacie značky nehrajú žiadnu rolu a preto ich odstráne- nie z textu pred indexovaním má výrazný vplyv na veľkosť indexu. Pre uľahčenie procesu vyhľadávania užívateľovi sú väčšinou texty prevádzané na texty s identickou veľkosťou znakov, teda buď všetko prevedené na malé alebo veľké písmená. Všeobecne sa tak robí prevod na malé písmena. Užívateľ tak nemusí premýšľať v akom kontexte daný vyhľadávaný výraz môže byť uložený a či používať malé alebo veľké písmená. Treba však zaistiť, aby tento prevod bol ako na strane indexovaných dát, tak aj na strane užívateľovho dotazu.
9 3. Problematika fulltextového vyhľadávania
Index ide napriek už výrazným úpravám na zmenšenie zredukovať ešte viacej. Texty obsahujú veľké množstvo slov, ktoré nenesú žiadnu relevantnú informáciu, a preto ich indexovanie a vyhľadávanie v nich je zbytočné. Pre vyhľadávací nástroj preto existuje možnosť definovať tzv. stopwords list. Jedná sa o zoznam slov, ktoré spĺňajú vyššie popí- sanú špecifikáciu, tradične sú to rôzne spojky, predložky a podobne. V slovenskom jazyku by to boli slová ako „a“, „alebo“, „s“, „so“, „z“ a tomu podobné, v anglickom jazyku zas „the“, „a“, „an“, „and“ a iné. Pri indexovaní sa potom slová z tohto zoznamu preskakujú a nein- dexujú, rovnako pri vyhľadávaní sa z dotazu užívateľa odstraňujú. Takéto slová sú totiž v textoch veľmi časté a keby sa pri vyhľadávaní zohľadňovali, vrátených by mohlo byť príliš veľa dokumentov ktoré by nemali nič spoločné s hľadaným kontextom [9][10]. V neposlednom rade sa treba vysporiadať s rozmanitosťou jazyka. Slová môžu mať rôzne tvary, pády, časy a môžu byť rôzne vysklo- ňované, tiež môžu byť použité slová s rovnakým alebo podobným významom, ktoré však znejú a píšu sa ináč – synonymá. Napríklad, „pingpong“ ide napísať aj ako „stolný tenis“, „pekný“ ako „krásny“, „nôž“ ako „nožík“ a podobne. Rovnako tvar slovesa „hrať“ vo vetách „Rád hrám bowling.“, „Rád hráš bowling.“ a „Radi hráte bowling.“ majú rôzne tvary ale sú toho istého základu. K tomuto slúžia synony- mické slovníky, techniky stemmingu a lemmatizácie. Ide o techniky konverzie slova zo základného tvaru do možných tvarov v danom jazyku (napríklad zo slova „hrať“ na „hrám“, „hráš“, „hrá“, „hral“ a podobne) a naopak z rôznych tvarov slov do ich základného tvaru. Tieto techniky sú stručne popísané v práci Radka Sikoru [7]. V dnešnej dobe je veľmi používanou, a na účely vyhľadávania slova či kombinácie slov veľmi vhodnou, štruktúra nazývaná aj invertovaný index. Ide o štruktúru, kde pre každé slovo obsiahnuté v kolekcii dokumentov je uložená informácia o tom, v ktorých dokumentoch sa daný výraz nachádza a koľko krát.
3.1.2 Príklad záznamu v invertovanom indexe Invertovaný index, ako bolo spomenuté vyššie, je veľmi rozšírený a pre techniky fulltextového vyhľadávania vhodný. Pre predstavu, ako takýto index funguje, uvediem zjednodušený príklad. Každý záznam v indexe obsahuje slovo a k nemu priradený
10 3. Problematika fulltextového vyhľadávania
zoznam výskytov v tvare: (
11 3. Problematika fulltextového vyhľadávania 3.2 Problém relevantnosti výsledkov
Stále ostáva preskúmať otázku, či fulltextovým vyhľadávaním vrátené výsledky sú pre užívateľa hodnotné a či nesú požadované množstvo informácií. Reč je o relevantnosti výsledkov, čo ju ovplyvňuje a ako s nežiadúcim efektom nedôležitých, nerelevantných výsledkov bojo- vať. Načrtnem tri najčastejšie vyskytujúce sa a riešené problémy s rele- vantnosťou súvisiace, jeden z nich je v anglickej terminológii označo- vaný ako „precision and recall“, druhý „false-positive“ a tretí „false- negative“ problém.
3.2.1 Precision a recall Precision a recall v slovenčine nemá rozumný a dostatočne krátky preklad, avšak dá sa preložiť ako presnosť a úplnosť. Pre jednoznačnosť terminológie ostanem však pri anglických výrazoch. Precision a recall sú v kontexte získavania, respektíve vyhľadá- vania, dát stupnice, na základe ktorých sa meria schopnosť systému vrátiť relevantné výsledky na užívateľov dotaz. Tie sú definované nasledovne:
∙ precision: pomer vrátených dokumentov, ktoré sú relevantné, ku všetkým vráteným dokumentom,
∙ recall: pomer vrátených dokumentov, ktoré sú relevantné, ku všetkým relevantným dokumentom dostupným v prehľadáva- nej databáze.
Dá sa povedať, že precision (tiež označovaný ako pozitívna predik- tívna hodnota, anglicky positive predictive value) je zlomok vrátených dokumentov, ktoré sú relevantné, a recall (tiež označovaný ako citli- vosť, anglicky sensitivity) je zlomok relevantných dokumentov, ktoré sú vrátené (obrázok 3.1). Obe sú teda založené na porozumení a schop- nosti merať relevantnosť informácií [12]. Medzi precision aj recall existuje vzťah, ktorý súvisí s výkonom získavania dát. Ukázalo sa, že so stúpajúcim recall ma precision ten- denciu klesať. Tiež je dokázané, že istý kompromis medzi precision a recall je nevyhnutný vo všetkých prípadoch, kde výkon získavania
12 3. Problematika fulltextového vyhľadávania
dát je konštantne vyšší ako náhodné hľadanie. S veľkými databázami, alebo setmi dát, s obmedzenými možnosťami vyhľadávania, bývajú spojené isté výhody vo vyhľadávaní. Vyhľadávanie môže prebiehať v dvoch štádiách, prvotné vyhľadávanie s vysokým parametrom recall (veľké množstvo vrátených dokumentov bude relevantných), nasledo- vané detailnejším vyhľadávaním nad setom dát vrátených z prvého vyhľadávania. Takýmto štýlom ide zvýšiť precision aj recall zároveň. Napriek tomu však kompromis medzi precision a recall nemizne a ostáva. Viac o tomto probléme a jeho teórii nájdete v práci, ktorú spracovali Michael Buckland a Fredric Gey [13].
3.2.2 False-positive a false-negative problém False-positive a false-negative problémy sú chybové stavy pri vyhľa- dávaní. False-positive, alebo falošne pozitívny, je taký výsledok vyhľadá- vania, ktorý síce nesplňuje požiadavky (neobsahuje požadované frázy, alebo nie je relevantný), ale bol vrátený v kolekcii výsledkov. False-negative, alebo falošne negatívny, je taký dokument v kon- texte fulltextového vyhľadávania, ktorý síce splňuje požiadavky uží- vateľa, ale vrátený v kolekcii výsledkov nebol (obrázok 3.1) [14]. Oba tieto stavy, či problémy, sú chybové, a čím častejší je ich výskyt v kontexte vyhľadávacieho nástroja, tým väčšmi sú výsledky menej relevantné. Vznikajú hlavne kvôli rôznorodosti a nejednoznačnosti ľudského jazyka. Výskyt týchto problémov je možné obmedziť napríklad technikami zoskupovania, anglicky clustering, za použitia tzv. Bayesianského algo- ritmu. Napríklad pre hľadané slovo „list“ môže byť clustering použitý na vytvorenie kategórií „príroda a životné prostredie“ a „spôsoby ko- munikácie“. Na základe kategórií všetkých hľadaných slov zužujeme výber výsledkov na konkrétny kontext a tak znižujeme výskyt falošne pozitívnych výsledkov [16].
3.2.3 Softvér poskytujúci fulltextové vyhľadávanie Nasleduje zoznam niekoľkých riešení ponúkajúcich možnosti fulltex- tového vyhľadávania a indexovania. Všetky uvedené produkty sú bezplatné a majú verejný zdrojový kód.
13 3. Problematika fulltextového vyhľadávania
Obr. 3.1: Grafické znázornenie false-positives a false-negatives agra- fická reprezentácia vzorcov pre precision aj recall [15] 14 3. Problematika fulltextového vyhľadávania
∙ Clusterpoint server1,
∙ Ioda2,
∙ DBSight3,
∙ Domino4,
∙ KinoSearch5,
∙ Sphinx6,
∙ Lucene-search7,
∙ Pylucene8,
∙ Plucene9,
∙ Apache Solr10 [17].
1. https://www.clusterpoint.com/ 2. https://sourceforge.net/projects/ioda/ 3. http://www.dbsight.net/ 4. https://www.ibm.com/developerworks/downloads/ls/lsds/ 5. http://search.cpan.org/~creamyg/KinoSearch-0.315/lib/KinoSearch. pod 6. http://sphinxsearch.com/ 7. https://meta.wikimedia.org/wiki/Installing_Lucene_search 8. http://lucene.apache.org/pylucene/ 9. http://search.cpan.org/~tmtm/Plucene-1.25/lib/Plucene.pm 10. http://lucene.apache.org/solr/
15 4 Apache Solr
Solr je rýchla a populárna podniková vyhľadávacia platforma s ve- rejným zdrojovým kódom. Pochádza z projektu Apache Lucene. Je písaný v jazyku Java a je spustiteľný ako samostatná serverová apli- kácia. Je postavený na knižnici Lucene pre fulltextové indexovanie a vyhľadávanie, používa json a http/xml aplikačné rozhranie. Vďaka týmto vlastnostiam je ľahko použiteľný z takmer akéhokoľvek progra- movacieho jazyku. Apache Solr je dodávaný ako samostatná aplikácia, anglicky stan- dalone application, s užívateľským administrátorským rozhraním, ktoré umožňuje správu systému, dokumentov, samotné vyhľadáva- nie a obdržanie výsledkov pre účely vývoja a iné (nie je určený pre koncového užívateľa, ale pre vývojára). To samotná knižnica Apache Lucene, ktorú Solr používa, neumožňuje, a preto sa dá hovoriť o istých výhodách systému Apache Solr. Solr má vysoký počet prispievate- ľov, jednotlivcov aj firmy, ktorí vyvíjajú nové funkcionality a opravujú chyby. Spomenuté rozhranie v krátkosti predstavím v rámci tejto ka- pitoly. Knihovňa Apache Lucene je veľmi rozsiahla a je na samostatnú prácu, jej možnostiam a schopnostiam sa už na Fakulte informatiky Masarykovej univerzity v niekoľkých prácach venovalo (napríklad [18][19][20]), preto zhrniem Apache Lucene len stručne, najprv sa však pozriem na históriu Apache Solr.
4.1 História Apache Solr
Koncom roku 2004 CNET Networks rozbiehajú projekt vyhľadáva- cej platformy s názvom „Solar“. V januári 2006 padlo rozhodnutie na verejnú publikáciu zdrojového kódu, a to takým spôsobom, že ho darovali firme Apache Software Foundation pod projekt Lucene s názvom „Solr“. 17. januára 2007 sa stal Solr plnohodnotným podpro- jektom projektu Lucene. V marci 2010 sa Solr a ostatné podprojekty Lucene spojili, za týmto účelom sa v roku 2011 upravilo aj číslovanie verzie Solr (Solr vtedy preskočil z verzie 1.4.1 na verziu 3.1, aby sa zhodovala s verziou Lucene). V októbri 2012 bola vydaná verzia Solr
16 4. Apache Solr
4.0 s významnou novinkou v podobe cloud služieb [21]. V máji 2017 je aktuálne dostupná najnovšia verzia 6.5.1. Ako ďalej dopĺňa článok na Wikipédii ([22]), „otcom“ Solr je Yonik Seeley, ktorý v spomínanom roku 2004 vytvoril základ systému Solr.
4.2 Apache Lucene
Lucene je používaná ako fulltextový vyhľadávací nástroj napísaný v jazyku Java. Je to technológia vhodná pre takmer akúkoľvek apli- káciu vyžadujúcu fulltextové vyhľadávanie. Veľkou výhodou je pod- pora multiplatformových riešení. Lucene má verejný zdrojový kód od roku 2000, keď ho jeho autor, Doug Cutting, zverejnil na serveri SourceForge1. Autor projekt pomenoval podľa druhého mena svojej manželky [20]. Lucene je jedným z najpopulárnejších vyhľadávacích nástrojov vôbec. Rovnako ako Solr, Lucene má širokú základňu prispievateľov do projektu a pre svoju popularitu bola knižnica prepísaná aj do iných jazykov ako je Java, napríklad Perl, Python, Ruby, PHP alebo C# [18]. Ako bolo spomenuté vyššie, Lucene je knižnica, žiaľ veľké množ- stvo ľudí ju považuje za samostatnú spustiteľnú aplikáciu, čo nie je pravdivé. Obľúbenosť Lucene spočíva vo flexibilite nasadenia. Keďže nie je samostatne spustiteľná a nedisponuje žiadnou užívateľskou nad- stavbou v podobe napríklad užívateľského rozhrania, možnosti jej konfigurácie sú veľmi široké a vývojára takpovediac v ničom neobme- dzujú. Solr zas ako spustiteľná aplikácia vystavuje vývojára istým ob- medzeniam, ktoré vyplývajú zo samostatnosti systému. Je všeobecne odporúčané, pokiaľ nemá účel vyhľadávania príliš špecifické požia- davky, alebo pokiaľ vývojár, respektíve vývojári daného systému ne- majú s Lucene veľké skúsenosti, nasadiť radšej systém ako Solr alebo podobný, napríklad Elasticsearch alebo Algolia [23], pre zjednodu- šenú konfiguráciu a zabalenie niektorých zložitých procesov „pod kapotu“. Lucene je vysoko výkonný a škálovateľný, nie je závislý na type dát, čo znamená, že dokáže indexovať a vyhľadávať nad dátami ľubovoľ- ného formátu takého, z ktorého ide extrahovať text. To zahŕňa súbory
1. https://sourceforge.net/
17 4. Apache Solr
formátov pdf, Microsoft Office Word, html dokumenty, xml dokumenty, rovnako ako dokumenty obsahujúce jednoduchý text [19].
4.3 Možnosti Solr
Ako som už niekoľko krát spomenul, Solr je rozsiahly a veľmi flexibilný systém. Čo by však mal splňovať vyhľadávací nástroj vo všeobecnosti? Podľa prednášky Xaviera Moreru [2] by to rozhodne malo byť in- dexovanie, analýza dopytu, anglicky query parsing, vyhľadávanie a prezeranie výsledkov, mal by poskytovať istú úroveň bezpečnosti, nejakým spôsobom poskytovať možnosť hodnotenia relevantnosti, a v neposlednom rade by mal byť užitočný. Schopnosti, možnosti a funkcie Solr sú:
∙ rozsiahle možnosti fulltextového vyhľadávania,
∙ optimalizácia pre vysokú návštevnosť webu integrujúceho Solr,
∙ podpora štandardných rozhraní na komunikáciu po sieti (xml, json, http),
∙ obsiahle administrátorské rozhranie,
∙ štatistiky serveru,
∙ indexovanie v takmer reálnom čase,
∙ flexibilný a prispôsobiteľný prostredníctvom konfigurácie za použitia xml,
∙ rozšíriteľná modulárna architektúra,
∙ schéma reálnych dát s numerickými typmi, dynamickými po- ľami a unikátnymi kľúčmi,
∙ fazetové vyhľadávanie a filtrovanie,
∙ konfigurovateľný a užívateľsky rozšíriteľný caching2,
2. Cache je malá a veľmi rýchla pamäť, ktorá slúži na dočasné uloženie dát pre rýchly prístup [24].
18 4. Apache Solr
∙ optimalizácia výkonu, ∙ viaceré indexy pre vyhľadávanie (viacero jadier), ∙ a mnoho iných.
4.4 Administrátorské rozhranie Solr
Administrátorské rozhranie systému Apache Solr je užívateľské roz- hranie dostupné priamo z webového prehliadača. Prostredníctvom neho je možné danú inštanciu Solr spravovať, používať ju na kontrolné účely, dá sa tiež v istých prípadoch využiť namiesto zdĺhavého čítania dokumentácie. Obsahuje logovací výpis, prístup k jednotlivým jadrám (indexom) systému, nástroj na vyhľadávanie a prezeranie výsledkov vyhľadávania. Vývojárovi sú ďalej prístupné priamo z rozhrania nástroje na správu indexov, na manuálne pridávanie dokumentov do indexu, prezeranie, správu a upravovanie zdrojových a konfiguračných súborov systému Solr. Systém podporuje možnosť replikácie indexov pre účely zálohy, pričom celý proces sa rovnako dá spravovať priamo z administrátor- ského rozhrania. Na obrázku 4.1 je možné vidieť, ako dané rozhranie vyzerá. V ľavej časti je hlavná ponuka, cez ktorú je možné sa presmerovať na spomí- nané stránky logovania, správy jadier, respektíve indexov, pomocou rolovateľného zoznamu výber indexu (na snímke obrazovky vybratý index SKBOffline), v rámci indexu prístup k analytickým nástrojom, spomínanému manuálnemu nahrávaniu dokumentov a teda rozširo- vaniu indexu, prehliadač zdrojových súborov, nástroj na vyhľadávanie a prezeranie výsledkov, ktorý je na snímke zvolený a v neposlednom rade nástroj na replikáciu.
4.5 Softvérové riešenia integrujúce Apache Solr
Apache Solr je vo veľkej miere využívaný aj v softvérových riešeniach, ktoré niektorí z nás bežne používame. Medzi ne patrí aj: ∙ Netflix3,
3. https://www.netflix.com/
19 4. Apache Solr
Obr. 4.1: Ukážka administrátorského rozhrania Apache Solr
∙ whitehouse.gov4,
∙ Instagram5,
∙ The Guardian6,
∙ AOL7,
∙ a mnohé iné webové aplikácie a stránky.
Solr je však integrovaný aj do veľkého množstva profesionálnych ná- strojov, s ktorými bežný užívateľ neprichádza do styku, ako sú naprí- klad Sharepoint, LucidWorks, Vivisimo, Content Analyst, Amazon Cloud Search a mnohé iné [2].
4. https://www.whitehouse.gov/ 5. https://www.instagram.com/ 6. https://www.theguardian.com/international 7. https://www.aol.com/
20 5 Analýza problému
Pre efektívne riešenie je potrebné rozoberaný problém dopodrobna rozanalyzovať. Zváženie dostupných možností a premyslenie rozhod- nutí s ohľadom na dopad v budúcnosti môže ušetriť pri vývoji veľké množstvo problémov a času. V prípade projektov v reálnom svete takto premyslené kroky navyše šetria aj nemalé peniaze. Nakoľko je aplikácia, o ktorej je reč, desktopová, a zároveň posky- tuje možnosti vyhľadávania nad setom dát, ktoré sú pokiaľ možno čo najaktuálnejšie, treba sa na začiatok zamyslieť nad tým, akým spôso- bom túto aktuálnosť docieliť. Produkt KB2GO je prepojením niekoľ- kých aplikácií, pričom koncový užívateľ priamo pracuje s klientskou aplikáciou – užívateľským rozhraním. Tá sama poskytuje možnosť prehľadávať dostupné dáta. Pre účely analýzy však v rýchlosti pri- blížim ideu za synchronizáciou dokumentov z databázy SKB Online, ktorá bola spomínaná v kapitole 1. Existujú dva typy synchronizácie, prvá je iniciálna, teda počia- točná, a druhá inkrementálna. Užívateľ má možnosť zvoliť si z čerstvo nainštalovanej aplikácie, ktorá neobsahuje žiadne dáta, produkty, ku ktorým si žiada stiahnuť súbory. Dôvod je prostý, a síce, celkový počet súborov dostupných z online systému je približne 1 milión. Užíva- teľ, ktorý pracuje s jedným či dvoma zariadeniami, teda produktami, nemá väčšinou záujem o dokumenty prislúchajúce k iným produktom a tým sa šetrí miesto na disku, ako aj skracuje dĺžka synchronizácie. Ďalšie obmedzenia pri synchronizácii sú práva užívateľa. Každý uží- vateľ ma istú úroveň práv, tzv. ACL1, ktoré určujú, na ktoré súbory užívateľ právo má a na ktoré nie. Prípadnú zmenu práv užívateľa, vymazanie niektorých súborov v online databáze, alebo aktualizácia niektorých súborov, je riešená inkrementálnou synchronizáciou. Tá okrem stiahnutia najnovších a najaktuálnejších súborov môže spôso- biť aj vymazanie niektorých súborov na lokálnom úložisku, všetko v závislosti od práv užívateľa a súborov na vzdialenom serveri.
1. Access Control Level
21 5. Analýza problému 5.1 Dáta dostupné z aplikácie
Ako bolo spomenuté vyššie, dáta sa do aplikácie sťahujú zo vzdia- leného serveru. Všetky súbory prislúchajú k istým produktom. Pri zvolení produktov na inštaláciu sa vytvárajú pomocou tzv. packa- ging application na vzdialenom serveri balíčky dát, ktoré sú následne prenesené po sieti do klientskeho počítača. Takýto balíček (ďalej package) je skomprimovaný, vo formáte zip. Pre účely analýzy sa pozriem, ako takýto package vyzerá, aké sú- bory, respektíve dáta obsahuje. Po dekompresii možno nájsť takúto stromovú štruktúru:
∙ koreňový adresár (unikátny názov daného balíčku).
– SkbAttachmentsBinaries, – SkbAttachmentsTexts, – SkbDocuments, – SkbInlineImages.
SkbAttachmentsBinaries: Adresár SkbAttachmentsBinaries obsa- huje súbory formátov pdf, doc, docx, docm a iné formáty prislúchajúce balíčku MS2 Office, txt, jpg, png, gif a iné obrázkové formáty, a v nepo- slednom rade súbory formátu zip. Vo všeobecnosti sa jedná o súbory, ktoré sú otvoriteľné a pohodlne čitateľné za pomoci softvéru tretích strán (Adobe Acrobat Reader, MS Office a podobne).
SkbAttachmentsTexts: Adresár SkbAttachmentsTexts naopak obsa- huje súbory formátu skbDoc. Tieto súbory sú čisto textového charak- teru.
SkbDocuments: SkbDocuments adresár, podobne ako SkbAttach- mentsTexts, obsahuje čisto textové súbory formátu skbDoc.
2. Microsoft
22 5. Analýza problému
SkbInlineImages: Adresár SkbInlineImages opäť pozostáva zo sú- borov s príponou skbDoc. Ďalšou úlohou bude identifikovať súbory, ktoré bude mať význam spájať so systémom Solr, indexovať ich a vyhľadávať nad nimi.
5.1.1 Súbory nevhodné na indexovanie Určiť súbory, ktoré nemá zmysel indexovať, by nemalo predstavovať veľký problém. Začal by som adresárom SkbAttachmentsBinaries. Tento adresár obsahuje rôzne typy súborov. Keďže sa jedná o vyhľadávanie v textoch, súbory ako obrázky alebo zip súbory nemajú byť ako nástrojom na fulltextové indexovanie a vyhľadávanie indexované. To poslúži ako indícia, že tieto súbory vhodné na indexovanie nie sú. V kapitole 4.2 som uviedol, že knižnica Apache Lucene je schopná extrahovať texty zo súborov ako pdf, doc a docx a tomu podobných, a takéto súbory indexovať a vyhľadávať nad nimi. Dôvod, prečo sa nepokúšať túto možnosť využiť je však prostý. Treba si uvedomiť, že dáta poskytnuté pre aplikáciu KB2GO pochádzajú zo vzdialeného servera, z databázy, ktorú používa systém SKB Online rovnako s možnosťami vyhľadá- vania, a teda môžeme predpokladať, že takto prispôsobené údaje sa budú vyskytovať v jednom zo zvyšných adresárov. Ostatné súbory, ako bolo spomenuté vyššie, sú formátu skbDoc, ktorý pozostáva z čistého textu, a dá sa predpokladať, že to sú súbory, ktoré budem indexovať.
5.1.2 Textové dáta vhodné pre indexovanie Ako bolo vysvetlené v predošlej kapitole, súbory z adresáru SkbAttach- mentsBinaries nebudú mať so systémom Solr nič spoločné. S predpo- kladom, že ostatné adresáre obsahujú súbory vhodné na indexovanie sa postupne dostanem k ich analýze, najprv však treba predpoklad potvrdiť, či vyvrátiť. Súbory v adresároch SkbAttachmentsTexts a SkbDocuments majú štruktúru súborov json, a dá sa jednoducho nájsť v týchto súboroch istý vzor a preto ich označujem ako vhodné na indexovanie. Aby som sa vrátil k prílohám, teda súborom v adresároch týkajúcich sa prí- loh, a síce SkbAttachmentsBinaries a SkbAttachmentsTexts, v druhom
23 5. Analýza problému
spomenutom je možné nájsť práve textovú reprezentáciu súborov z pr- vého adresáru, ktorá bola spomenutá v predošlej kapitole. Predpoklad bol teda správny. Súbory v adresári SkbInlineImages obsahujú text, ktorého štruk- túra je opäť totožná s json formátom. Ako názov adresáru napovedá, jedná sa o obrázky. Sú to obrázky, ktoré sú priamo súčasťou doku- mentov a sú zobrazené priamo v texte dokumentov. Súbory obsahujú informácie ako ID súboru („Id“), názov súboru („FileName“), samotné dáta („Data“), ID dokumentu, ktorému patria („DocumentId“) a infor- máciu o poradí v dokumente („IndexInDocument“). Položka „Data“ v týchto súboroch obsahuje obrázok kódovaný v Base64, čo sa neskôr bude dať použiť pre priame vloženie do html štruktúry zobrazova- ného dokumentu na úrovni užívateľského rozhrania. Nakoľko sa jedná o obrázky, a žiaden zmysluplný text nie je poskytnutý, tieto dáta ne- budú indexované a zaradené na spracovanie pre Solr, rovnako ako SkbAttachmentsBinaries.
5.2 Analýza dát pre fulltextové vyhľadávanie
V predošlých krokoch som identifikoval, aké súbory budú v systéme Solr indexované, teda nad akými súbormi bude prebiehať vyhľadá- vanie, aké súbory budú tvoriť databázu. Nasleduje analýza štruktúry týchto dokumentov, na základe ktorej začnem potom tvoriť schému databázy Solr.
5.2.1 Štruktúra dokumentov Ako som už spomínal, dokumenty sú súbory s príponou skbDoc. Obsa- hujú textovú reprezentáciu objektu vo formáte json. Zanalyzujem, aké typy údajov sa v týchto súboroch nachádzajú, aby som bol schopný mapovať tieto dokumenty na Solr. Pre pripomenutie, všetky dokumenty pochádzajú zo serveru SKB Online. Obsahujú pomerne veľké množstvo informácií, ako prvá je „doc_key“. Všetky dokumenty tu majú textový reťazec, ktorý predsta- vuje identifikátor dokumentu, ktorý je jedinečný pre každý dokument. Ďalej je prítomná verzia „_version_“, ktorá má pri sebe číselnú hod- notu. Táto verzia je prenesená z online databázy, a teda odzrkadľuje
24 5. Analýza problému v akej verzii sa nachádzala databáza indexu dokumentov pri poslednej zmene daného dokumentu online. Nasledujú položky „title“ a „title_phrase“, ktoré majú totožný obsah, a síce názov dokumentu. Ďalej to je „autocomplete_shingle“, ktorý obsahuje pole textových reťazcov, ktoré by malo, z názvu vyplý- vajúc, slúžiť na automatické dopĺňanie pri písaní dotazu v aplikácii alebo textovom výbere produktu na prehľadávanie. Položka „text_- all“ obsahuje informácie totožné s predošlým údajom. Obe spomí- nané v rámci poľa obsahujú aj názov dokumentu. Textový reťazec tiež obsahuje položka „applies_to“. Položky „description“, „resolution“, „creation_date“, „doc_id“, „doc_id_exact“, „doc_status“, „doc_type“, „first_publish_date“, „publish_date“, „synchronization_id“, „bulk_- synch_id“, „synchronization_date“, „classification“, „is_technical“ a „is_application“ všetky obsahujú textový reťazec s príslušnou infor- máciou patriacou k názvu položky. Údaje s názvom „body“ a „body_phrase“, respektíve „body_- internal_info“ a „body_internal_info_phrase“ obsahujú opäť pole tex- tov, pričom obe dvojice neobsahujú názov dokumentu v rámci poľa a obe dvojice sú totožné s tým rozdielom, že druhá spomínaná ma o informáciu navyše, ktorá by nemala byť prístupná všetkým užívate- ľom. „Body_hl“ predstavuje pole textov, z názvu určených pre Solr na podporu zvýrazňovania (hl je skratka pre highlighting). „Categories“ a „components“ nesú pole textov, ktoré predstavujú príslušnosť doku- mentu do kategórií, respektíve ku komponentom. Položka „doc_acl“ obsahuje číslo (od 1 do 5), ktoré predstavuje minimálne potrebné práva užívateľa, ktorý dokument môže zobraziť. Prítomné sú aj viaceré po- ložky „ecs_level_n“, pričom n predstavuje číslo. Všetky obsahujú pole textov, pričom platí čím vyššie číslo, tým viac položiek (informácií) je v danom poli obsiahnutých. „Hits“, „internal_information_acl“, „major_version“, „minor_ver- sion“, „rating“ a „rating_count“ obsahujú vždy číslo vypovedajúce o počte otvorení v online verzii, prístupových právach na interné informácie v dokumente, verzii, hodnotení a počte hodnotení. Po- ložky „products_catalogids“, „products_displaynames“ a „products_- catalogids_including_ancestors“ a obsahujú pole textov. Ďalej sú tu položky „attachments“, „attachments_phrase“ a „attachments_hl“,
25 5. Analýza problému
ktoré obsahujú pole (zoznam) názvov súborov príloh. „Modalities“ a „software_versions“ obsahujú pole textových reťazcov. V neposlednom rade sú tu položky „description_html“, „resoluti- on_html“, „applies_to_html“ a „internal_info_html“, ktoré obsahujú informácie identické s rovnomennými poľami bez prípony „_html“, akurát sú označkované HTML značkami s použitím priamych štýlov, anglicky inline style, tieto položky budú určite vhodné na zobrazenie koncovému užívateľovi.
5.2.2 Štruktúra príloh Prílohy, rovnako ako dokumenty, sú súbory s príponou skbDoc ne- súce textovú podobu objektu json. Oproti dokumentom však nesú podstatne menšie množstvo rôznych informácií. Rovnako ako dokumenty, prílohy obsahujú položky „doc_key“, ktorá obsahuje text v podobe ID dokumentu, ku ktorému príloha pri- slúcha, „_version_“, „synchronization_id“, „bulk_synch_id“ a „syn- chronization_date“. Ďalšími údajmi, ktorými takáto príloha dispo- nuje, sú „attachment_name“ s textom predstavujúcim názov súboru v zložke SkbAttachmentsBinaries, „file_id“ s textom predstavujúcim unikátne ID súboru, „page_nr“ s číslom popisujúcim o akú stranu v danom súbore prílohy sa jedná, „total_nr_pages“ s číslom, ktoré predstavuje celkový počet strán v súbore, „unique_id“ s textom v tvare „
26 6 Riešenie problému
Integrácia systému Solr do aplikácie je riešená zakomponovaním ce- lého systému stiahnuteľného zo stránok Apache Solr1 do adresárovej štruktúry projektu. Pre čo najvyššiu kompatibilitu s online systémom, ktorému sa tento podriaďuje, použijem pre implementáciu Solr verzie 4.6.0, ktorý je síce zastaralý (k 17. máju 2017 je najnovšia dostupná verzia 6.5.1), ale pre účely a základný cieľ priblíženia s možnosťami k online verzii je logicky najvyhovujúcejší. Budem musieť analyzo- vať a vyriešiť viaceré problémy vyplývajúce z požiadaviek, medzi hlavné patrí návrh a vytvorenie databázy v rámci Solr tak, aby som bol schopný pracovať s oboma typmi dát, teda dokumentami aj ich prí- lohami. Ďalším rozsiahlejším problémom je zabezpečenie bezpečnosti podľa požiadaviek, pre čo budem potrebovať preskúmať rôzne do- pady nastavení na možnosti systému. Bude treba na základe analýzy dát navrhnúť a implementovať schému databázy a nakonfigurovať celý nástroj, navrhnúť spôsob komunikácie z prostredia aplikácie so systémom Solr a zanalyzovať a spracovať všetky prípady užitia, po ktorých bude nutná aktualizácia indexu.
6.1 Indexy
Ako bolo povedané, treba sa rozhodnúť pre jednu z dvoch možností, ktoré mám pri probléme jadier, respektíve indexov. Prvou možnos- ťou je mať jeden index, jedno jadro (ďalej len index), v ktorom budú uložené oba typy dokumentov. Druhou z možností je, na prvý po- hľad možno aj logickejšia možnosť, vytvoriť dva indexy, jeden pre dokumenty a jeden pre prílohy. Z analýzy dát vyplýva, že oba typy dokumentov sú úplne odlišné, majú rozdielne jedinečné identifikátory a implementácia v rámci jediného indexu by bola zbytočne zložitá. Preto som sa rozhodol pre implementáciu dvoch rôznych indexov v rámci systému Solr.
1. http://lucene.apache.org/solr/
27 6. Riešenie problému
6.1.1 SKBOffline Index
SKBOffline je názov prvého z dvoch zahrnutých indexov, ktorý bude slúžiť na ukladanie, indexovanie a vyhľadávanie dokumentov. Názov som zámerne nezvolil SKBOfflineDocuments, aby bolo z názvu jasné, že sa jedná o hlavný index systému.
6.1.2 SKBOfflineAttachments Index
Druhý z indexov je pomenovaný SKBOfflineAttachments, bude slúžiť na ukladanie, indexovanie a vyhľadávanie príloh k dokumentom. Pre jednoznačné určenie príslušnosti danej prílohy k dokumentu bude potrebné nejakým spôsobom ukazovať z indexu príloh do hlavného indexu obsahujúceho dokumenty. K tomuto účelu pravdepodobne použijem informáciu ktorá je dostupná v každej prílohe pod označe- ním „doc_key“, ktorá sa zdá byť použiteľná ako cudzí kľúč, anglicky foreign key.
6.2 Konfigurácia jadier Solr
Voľbou pre dva indexy to nekončí, práve naopak, iba začína. Po urobení tohto rozhodnutia potrebujem ako prvé preskúmať dopady rôznych nastavení schémy, aby som následne pri jej zostavovaní mohol urobiť správne rozhodnutia. Schéma dát odráža to, aké dáta sú v indexe ukladané, a definuje, nad akými poľami hodnôt sa budú vykonávať aké operácie. Konfigurácia daného indexu zas definuje, aké operácie sa dajú vykonávať nad daným indexom, aké nástroje sú k tomu použité a podobne. Pre to, aby Solr vôbec niekde bežal po spustení, je treba mu pove- dať kde. Toto má nastavené už od základu a tak v zložke „solr“ len skontrolujem, na akom porte bude počúvať Solr, aký má nastavený časový limit na pripojenie a podobne. So základnými nastaveniami v zásade nemám žiaden problém, a tak len zhrniem, že server bude počúvať na porte 8983 a má nastavený klasický 30 sekundový timeout.
28 6. Riešenie problému
6.2.1 Dopady rôznych nastavení na možnosti Solr
Bezpečnosť prenosu dát z online databázy na počítač s klientskou aplikáciou musí byť zabezpečená, rovnako ako ukladanie týchto dát na pevné úložisko. Synchronizácia a aktualizácia súborov je závislá na stave klientskej aplikácie a užívateľských právach, s ktorými daná in- štalácia pracuje. Jediné dáta, ktoré by mali byť prístupné sú tie, na ktoré ma užívateľ právo, čo sa Solr týka, mala by to byť najmenšia možná množina informácií uložených v databáze pre správne fungovanie. Problém prenosu dát a problém šifrovania dát ukladaných na pevný disk, ako aj problém načítavania zašifrovaných dát z disku a ná- sledne rozšifrovanie je mimo záberu Solr. Administrátorské rozhranie je možné zabezpečiť základnou autentizáciou a istými pravidlami, nazývanými „permission rules“, a tak predísť neželaným zásahom a vyhľadávaniu v systéme. Skoršie verzie Solr, akou je aj mnou použitá 4.6.0, však potrebujú pre takéto zabezpečenie použiť nástroje tretích strán. Získavanie celého obsahu dokumentov v rámci Solr by malo byť pokiaľ možno čo najobtiažnejšie. Indexované výrazy a uložené dáta môžu byť použité na rekonštrukciu celých dokumentov, používanie indexovaných výrazov pre takúto rekonštrukciu je však veľmi obtiažne a zdĺhavé, ale nie nemožné. Nie sú jednoducho čitateľné pre človeka, pretože prešli celým reťazcom analýz a úprav (stemming, zámena za synonymá a iné transformácie). Uložené dáta sú ľahšie čitateľnejšie a dávajú väčší zmysel. Každé jedno pole, položka v schéme ozna- čená ako stored=“true“ je presná kópia vstupu, žiadne transformácie pri ukladaní nie sú aplikované a všetky dáta dokumentu sú uložené na jednom mieste. Šifrovanie takto uložených dát je možné previezť, ale viedlo by k nepresným a nezmyselným výsledkom vyhľadávania, napríklad vyhľadávanie za pomoci zástupných znakov alebo zora- ďovanie nie je funkčné. Index so zašifrovanými výrazmi by zas bol užitočný iba na presné zhody hľadaných výrazov voči indexovaným, čo vedie k chabej relevantnosti výsledkov. Ukladanie hodnoty jednotlivých polí je potrebné jedine pre zís- kavanie hodnoty daných položiek z dokumentu a pre vyhľadávanie „MoreOfThis“, ktoré sa v aplikácii SKBOffline nepoužíva. Používateľ- ské rozhranie je pripravené tak, že očakáva iba unikátny identifikátor dokumentu a jeho obsah načíta zo zašifrovanej kópie dokumentu
29 6. Riešenie problému
Obr. 6.1: Zhrnutie dostupných možností a ich dôsledkov na funkci- onalitu Solr podľa prípadov užitia [25] Hodnoty true a false indikujú, že daná možnosť musí byť nastavená na danú hodnotu pre daný prípad užitia.
z pevného disku. Z tohto dôvodu môžu byť všetky údaje z ukladania do Solr vynechané (všetky budú mať nastavené stored=“false“) okrem jedinečného identifikátoru dokumentu, respektíve prílohy. Boosting, zoraďovanie, vyhľadávanie aj fazety je možné aplikovať iba pri indexo- vaní hodnôt, ich ukladanie potrebné nie je. Treba však brať v úvahu, že čítanie zašifrovaných dát z disku a zvýrazňovanie hľadaných výrazov vo výsledkoch môže spomaliť aplikáciu, keďže bude riešené mimo Solr. Celkový dopad je znázornený v tabuľke 6.1.
6.2.2 SKBOffline Ako bolo povedané, SKBOffline index slúži na prácu s dokumentami. Pre to, aby indexovanie, vyhľadávanie a operácie ako napríklad zoraďo- vanie boli možné nad týmito dátami, je potrebné previezť mapovanie dát (dokumentov) na dané jadro, respektíve index. To je možné vytvo- rením schémy indexu. Jedná sa o súbor, ktorý je umiestnený v zložke „conf“ SKBOffline indexu a pomenovaný je „schema.xml“. Ďalším súborom potrebným na práceschopnosť indexu je samotná konfigurá-
30 6. Riešenie problému
cia Solr pre daný index. Súbor je umiestnený v rovnakej zložke ako schéma, s názvom „solrconfig.xml“.
Schéma
Schéma indexu pre dokumenty bude pomerne rozsiahla, na základe analýzy dokumentov. Z čoho sa taká schéma skladá? Ako už bolo spomenuté, jedná sa o súbor xml a teda xml notáciou zapísané všetky položky (polia, teda fields), a prípadné užívateľom definované typy dát (medzi základné patrí napríklad string alebo int). Ako bolo vidieť z analýzy dokumentov, tie obsahujú aj dáta, ktoré sú nepotrebné a zbytočné z pohľadu implementácie. Ako príklad mô- žem uviezť všetky položky ktoré obsahujú „_hl“, teda ich zmyslom je poskytnúť text na vykonanie zvýrazňovania. To, ako bolo spomínané, z dôvodu bezpečnosti nebude vykonávať Solr ale kód v klientskej aplikácii. Z analýzy dopadov rôznych nastavení tiež môžem vyvodiť, že z požiadavky bezpečnosti, a z toho, že požadovanú funkcionalitu nástroja na vyhľadávanie to nijako neobmedzí, nie je potrebné ukladať do databázy Solr celé kópie dokumentov, ale stačí ich položky len in- dexovať a uložiť jednoznačný identifikátor dokumentu, ktorý poslúži na načítanie dokumentu z pevného disku a nepredstavuje sám o sebe žiadnu hrozbu pre bezpečnosť. Zhrniem pravidlá, podľa ktorých budem schému tvoriť. Všetky položky, ktoré obsahovali pole informácií, budú mať v schéme nasta- vené „multiValued=“true““. Ako jednoznačný identifikátor som určil „doc_key“, takže ten bude ako jediný vyžadovaný (bude mať „requ- ired=“true““), a súčasne bude označený ako „uniqueKey“. Ukladané do databázy Solr budú iba kópie „doc_key“ a „_version_“, ktoré sú potrebné pre zobrazenie výsledkov hľadania, respektíve pre interné procesy systému Solr. Všetky ostatné položky budú mať nastavené stored=“false“. Keďže Solr nepoužijem zároveň ako databázu dát, ale iba ako nástroj na indexovanie a vyhľadávanie, všetky položky, ktoré v ňom budem držať budú indexované (indexed=“true“). Tiež sa dá využiť tzv. „copyField“ ktorý definuje a zabezpečuje skopírovanie hodnoty jedného poľa („field“) do poľa druhého ešte pred tým, ako sa vykoná akékoľvek spracovanie obsahu daného poľa. Bez použitia tejto možnosti by bolo potrebné takéto kopírovanie pre-
31 6. Riešenie problému vádzať manuálne pred tým, než by sme dáta poslali do Solr, čo by okrem iného viedlo k citeľnému nárastu indexu. Položky, ktoré ponechám na indexovanie v Solr, budú položky potrebné pre správne fungovanie vyhľadávania v texte, možnosti fil- trovania dokumentov podľa ich typov, možnosti používania filtra komponentov a možnosti triedenia (viď kapitolu 2.3). Ďalším potrebným krokom je definovať typy dát. Set základných dát ako napríklad „string“, „int“ a podobné však stačiť nebude. Z toho dôvodu v rámci sekcie „types“ definujem niekoľko typov, ktoré budú určovať, aké operácie a úpravy majú prebehnúť nad poskytnutými dátami daného typu. Ako príklad vlastného dátového typu spome- niem napríklad „ft_text_sort“. Tento typ budú mať všetky položky v Solr také, ktoré budú slúžiť na zoraďovanie kontextu. Pre takýto dátový typ, aby bolo zoraďovanie čo najpresnejšie, je vhodné použiť súhlasnú veľkosť textu (štandardne sa text prevádza na malé písmená), odstránenie rozdeľovacích znakov a rôznych znakov medzier a rozde- liť samotný text na jednotlivé slová. To platí rovnako pre analyzátor dotazu („query“) ako pre analyzátor indexovania („index“). Pri definovaní vlastných typov je okrem takýchto úprav dát možné definovať systému úpravy ako zámena konkrétnych znakov zainé v texte pomocou regulárnych výrazov, aplikovať odstránenie stop slov z textu, odstrániť duplikáty z textu a podobne.
Konfigurácia jadra Pri konfigurácii jadra som zvolím trocha odlišnú taktiku. Nakoľko nakonfigurovanie Indexu „na zelenej lúke“ je pomerne zdĺhavé, pomô- žem si konfiguračným súborom indexu z verzie Solr, ktorá je dostupná k stiahnutiu ako demo verzia, a upravím ho na potrebné požiadavky. V rámci konfiguračného súboru je možné nastaviť aj replikáciu indexu z hlavného indexu na index otroka („master“ a „slave“ indexy), táto konfigurácia však nebude prevedená pretože takáto replikácia nie je vyžadovaná. Okrem klasických konfiguračných záležitostí, ako je definovanie adresáru s dátami indexu pre Solr, verzia Lucene a východzia hodnota dotazu, slúži konfiguračný súbor najmä na definíciu manažérov (ďalej len handler). Handler nebudem potrebovať len jeden, ale rovno dva, a to „updateHandler“ a „requestHandler“.
32 6. Riešenie problému
Pod konfiguráciou updateHandleru sú definované dva typy navy- konanie zmien („commit“), a to „autoCommit“ a „autoSoftCommit“. AutoCommit definuje, ako často sa ukladá zmenený index napevný disk, takto ukladané zmeny však nie sú aplikovateľné pri aktívnom servery nahratom v operačnej pamäti a tak zmeny nie sú viditeľné pri vyhľadávaní. AutoSoftCommit, naopak, definuje, ako často sa ukladá zmenený, aktualizovaný index, do pamäte RAM2. Po takomto ulo- žení sú zmeny okamžite viditeľné pri vyhľadávaní a nie je potrebné reštartovať celý Solr server. RequestHandler má viacero podôb, ktoré bude potrebné nakonfi- gurovať. V princípe sa jedná o ovládače pre komunikáciu so systémom prostredníctvom URL. Potrebné režimy sú „/select“ pre definíciu, kde hľadať zadaný výraz, „/update“, „/update/json“ resp. „/update/csv“ pre pridávanie dát do Solr, „/admin“ a „/admin/ping“ pre možnosť kontroly dostupnosti serveru Solr z prostredia aplikácie. Rozumné tiež je nejakým spôsobom povedať Solr, v akej forme očakávame výsledky vyhľadávania, a tak definujem „queryResponse- Writer“, kde definujem očakávaný typ formát JSON ako čistý text.
6.2.3 SKBOfflineAttachments SKBOfflineAttachments index je, ako bolo spomínané, určený pre prácu s prílohami. Pre jeho funkčnosť je rovnako potrebné mapovať dáta (prílohy), pričom treba urobiť rovnaké úkony ako s indexom SKBOffline.
Schéma Tvorba schémy podlieha rovnakým pravidlám ako pri tvorbe doku- mentov, to platí pre všetky časti schémy. Znamená to, že bude vytvo- rená na základe dostupných údajov zo súborov príloh s príponou skbDoc, budú z indexovania vynechané všetky údaje, ktoré nie sú potrebné pre vyhľadávanie, spájanie príloh ku ich príslušným doku- mentom a podobne. Ako jedinečný identifikátor použijem položku „unique_id“ a pokiaľ možno v čo najväčšej miere sa pokúsim recyklo- vať definíciu vlastných dátových typov.
2. Random Access Memory
33 6. Riešenie problému
Jeden dátový typ by som však rád vyzdvihol, a to „ft_trunc_page“, ktorý bude spracovávať text spôsobom, že odstráni všetky znaky me- dzier a následne regulárnym výrazom rozdelí text podľa znaku zvislej čiary na 3 časti, a ponechá iba prvé dve. Týmto spôsobom budem pre účely združovania do skupín upravovať položku „unique_id“, teda konkrétne bude odstraňovaný údaj o strane dokumentu, ktorej sa daná príloha týka. Okrem tohto dátového typu budú už použité iba základné dátové typy a typ „ft_text_general“, ktorý je totožný s tým v schéme dokumentov.
Konfigurácia jadra
Konfigurácia, rovnako ako schéma, bude v čo najväčšej možnej miere recyklovaná. Vďaka všeobecnosti konfigurácie jadra a minimálnej zá- vislosti od schémy daného indexu, je táto konfigurácia plne totožná s konfiguráciou indexu dokumentov, jediná zmena je v requestHand- lery „/select“, kde ako základná položka na hľadanie výskytu hľada- ného výrazu nie je „description“, ale „att_text“.
6.3 Návrh komunikácie so systémom
V rámci práce so systémom Solr bolo potrebné preskúmať možnosti komunikácie s ním, spôsoby zasielania dotazov a následné obdržanie výsledkov, definovať, kedy sa má Solr ako samostatný server spúšťať, v akých prípadoch užitia bude potrebné indexovanie. Všetky pod- robnosti, či už miesta a okolnosti za akých bude Solr bežať, ako aj návrh a odôvodnenie spomínaných úkonov popíšem v nasledujúcich sekciách. Samotné spúšťanie serveru by malo prebiehať pri štarte aplikácie. Aplikácia by mala počkať na nabehnutie Solr a až keď ten je korektne zavedený, pokračovať v spúšťaní zvyšných modulov. Pre overenie, či je Solr zavedený a korektne funkčný, by bolo vhodné použiť zadefino- vaný handler „/admin/ping“ a po pozitívnej odpovedi sprístupniť aplikáciu. V prípade, že by sa do istého, predom definovaného času, pozitívnej odpovedi aplikácia nedočkala, bolo by vhodné ju ukončiť s chybovou hláškou a vyzvať užívateľa na reštart aplikácie.
34 6. Riešenie problému
Obr. 6.2: Dotaz na Solr s viditeľnou URL, na ktorej je prístupný samotný vrátený objekt
Celá komunikácia medzi aplikáciou by mohla prebiehať prostred- níctvom URL, teda by mala využívať zadefinované handlery. Príklad ako takýto dotaz prostredníctvom URL je možné postaviť, je priamo viditeľný v administrátorskom rozhraní Solr (obrázok 6.2). Samotná odpoveď serveru na konkrétnej adrese z prehliadača je viditeľná na obrázku 6.3.
6.3.1 Kedy indexovať Jedným z posledných úkonov je navrhnúť, kedy vykonávať indexo- vanie dát. Princíp synchronizácie, typy synchronizácie a aj rôzne dô- sledky synchronizácie som už opísal.
35 6. Riešenie problému
Obr. 6.3: Samostatná odpoveď serveru Solr na dotaz
36 6. Riešenie problému
Nahranie nového záznamu do Solr by malo prebehnúť vždy pri spracovávaní každého takéhoto záznamu. Akýkoľvek súbor nový, zmenený alebo vymazaný by mal mať za následok volanie handleru „/update“. Tento proces bude potrebné previezť tiež pri synchronizácii synonymického slovníka (synonyms.txt) z online servera, tu však treba mať na pamäti, že dáta samotné nie sú uložené v Solr a preto zrejme bude potrebné previezť načítanie všetkých dát z disku s následným rozšifrovaním a indexovanie nanovo. Dôvod, prečo je treba indexovať aj po zmene synoným je ten, že už v procese indexovania sa synonymá zapracovávajú do vytváraného indexu, a preto zmena synonymického slovníka by bez zmeny indexu nemala žiaden efekt. Pri nahrávaní dát do Solr platí rovnaký proces ako pri nahrávaní dát do databázy, a teda delí sa na update (nahranie dát) a commit (vykonanie zmien). V prípade, že by bol commit vykonávaný za kaž- dou jednou zmenou, výkon indexovania by mohol byť výrazne nižší ako je systém schopný dosiahnuť. Preto, pre optimalizáciu výkonu, navrhujem vykonávať commit vždy po nahraní niekoľkých súborov (napríklad vždy po spracovaní celého balíčku k produktu).
6.3.2 Kedy získavať potrebné informácie pre užívateľské rozhranie Počiatočné údaje, ako sú počet dokumentov v Solr, počet dokumentov jednotlivých typov a ostatné chcené informácie v užívateľskom roz- hraní si treba od Solr popýtať. Za týmto účelom už po naštartovaní aplikácie navrhujem previezť počiatočné dotazy na Solr za účelom získania zmienených informácií. Dotaz základného tvaru „*:*“3 vráti okrem samotných výsledkov počet všetkých dokumentov v systéme, pri použití možnosti „facet“ je možné sa spýtať napríklad na počty dokumentov jednotlivých typov.
3. Prehľadávané sú všetky indexované polia a hľadá všetko – tým dosahujeme záruku, že počet nájdených dokumentov bude zodpovedať počtu všetkých indexo- vaných dokumentov.
37 6. Riešenie problému
Obr. 6.4: Použitie fazetového vyhľadávania pre získanie počtov doku- mentov jednotlivých typov
38 7 Vyhodnotenie riešenia
Po vypracovaní riešenia pozrieť sa retrospektívne a sebakriticky na riešenie samotné nie je na škodu. Objektívne vyhodnotenie poskytnu- tého riešenia je v tomto prípade veľmi obtiažne a ťažko merateľné. Ako prostriedok vyhodnotenia bol zvolený dotazník kolegom, ktorí s po- skytnutým systémom Solr ako aj s návrhmi na jeho použitie pracovali, aby sme spoločne mohli doručiť produkt. Kľúčové je zostaviť dotazník a pokiaľ možno čo najlepšie porozumieť odpovediam v ňom a pokúsiť sa z toho vyťažiť návrhy na zlepšenie do budúcna. Kolegovia, ktorí dotazník budú vypĺňať sú vývojári na projekte a v jednom prípade líder tímu. Všetci sa aktívne podieľajú na tvorbe produktu v projekte a preto ich odpovede, posudky a postrehy by mali byť vzhľadom k poskytovanému produktu na vysokej úrovni.
7.1 Tvorba dotazníku
Čo presne v dotazníku riešiť, na čo sa pýtať a ako dosiahnuť čo najob- jektívnejšie hodnotenie, to je otázka, na ktorú sa pokúsim zodpovedať. Nakoľko riešenie pozostáva z mapovania dokumentov a príloh na Solr, konfiguráciu indexov a návrh na elementárne úkony používajúce Solr, ako je vyhľadávanie, získavanie metadát o indexovaných dokumen- toch, indexovanie v kontexte synchronizácie a podobne, zameriam sa na poskytované možnosti nakonfigurovaným Solr, a teda odpovede budú z časti pokrývať samotnú funkcionalitu pre koncového užíva- teľa, a z časti budú odzrkadľovať zložitosť, respektíve jednoduchosť, ako aj efektívnosť implementácie rozhrania na komunikáciu so Solr v klientskej aplikácii, teda API1. Forma dotazníka pozostáva z dvoch typov otázok, prvým sú otázky, na ktoré je možné odpovedať číslom od 1 do 5, pričom 5 je najlepšie hodnotenie a 1 najhoršie. Druhým typom sú otázky s otvoreným textom, od ktorých očakávam komplexnejšiu spätnú väzbu a teda širokospektrálnejšie hodnotenie. Samotné oblasti na hodnotenie číselnou hodnotou som zvolil na- sledovne:
1. Application Programming Interface
39 7. Vyhodnotenie riešenia
∙ rýchlosť hľadania,
∙ kvalita, respektíve relevantnosť výsledkov,
∙ zhodnosť s online verziou,
∙ splnenie požiadaviek (celkovo),
∙ triedenie výsledkov,
∙ vyhľadávanie s použitím synoným,
∙ používanie logických operátorov,
∙ filtrovanie podľa typov dokumentov,
∙ vyhľadávanie s použitím zástupných znakov,
∙ indexovanie,
∙ kvalita solr schémy,
∙ prehľadnosť solr schémy.
Tieto oblasti by mali pokryť všetky, alebo väčšinu, požiadaviek klade- ných na riešenie. Druhý typ otázok pozostáva z dvoch s voľným textom, prvá otázka je na opísanie hodnotenia vlastnými slovami, zatiaľ čo druhá sa snaží zachytiť postrehnuté nedostatky, a teda sa pýta na návrhy a nápady na úpravu a vylepšenie riešenia.
7.2 Výsledky dotazníku a ich vyhodnotenie
Vyhodnotenie voľného textu z dotazníku bude zložitejšie, tak sa pokú- sim zhrnúť postrehy, hodnotenie a nápady, respektíve návrhy. Čo sa týka otázok s číselným hodnotením, zozbieral som všetky dotazníky a vytvoril som graf s priemerným hodnotením od všetkých kolegov. V hodnoteniach sa spomínajú argumenty ako „Solr ako taký je veľmi silný nástroj a nie je náročný na použitie a správu, indexova- nie a vyhľadávanie je intuitívne.“, „Riešenie spĺňa alebo podporuje
40 7. Vyhodnotenie riešenia
spĺňanie všetkých požiadaviek.“ a v neposlednom rade „Nakoľko apli- kácia používa softvér tretej strany (Solr) na vyhľadávanie, poskytované výsledky a funkcionalita ja na vysokej úrovni.“ O návrhy na vylepšenie rovnako nie je núdza, týkajú sa vylepše- nia efektivity API pre komunikáciu so Solr aj zváženia poskytovania odporúčaných vyhľadávaní (na základe histórie vyhľadávania použí- vateľa) či podobných vyhľadávaní, ktoré sú dostupné v online verzii, hoci takáto požiadavka na offline systém kladená nebola. Ako prob- lém bol vypichnutý štart serveru Solr, ktorý zlyhá približne raz z 10 pokusov a vedie k nutnosti reštartovať klientsku aplikáciu. Pôvodca problému nie je do teraz známy a jeho prípadné vyriešenie by určite pridalo na hodnote KB2GO. V neposlednom rade padol návrh na vy- lepšenie komplexného vyhľadávania pomocou zástupných znakov, keďže to nie je jednoduché na prevedenie a má to svoje nedostatky. Vyhľadávanie so zohľadnením synoným tiež nie je vždy úplne pred- pokladateľné, alebo počet výsledkov býva príliš vysoký a môže sa strácať pocit relevantnosti niektorých výsledkov. Vyhodnotenie otázok s hodnotením od 1 do 5 je viditeľné na ob- rázku 7.1.
41 7. Vyhodnotenie riešenia
Obr. 7.1: Spracované výsledky dotazníku v tabuľkovej aj grafickej podobe
42 8 Záver
V práci som zhrnul problematiku implementovaného problému, pred- stavil požiadavky zákazníka, pozrel som sa na problém fulltextového vyhľadávania, význam a možnosti indexovania, uviedol som dôvody pre a proti indexovaniu textových dokumentov pre potreby fulltexto- vého vyhľadávania. Preskúmal som, ako funguje tzv. invertovaný in- dex, zanalyzoval som najčastejšie problémy pri získavaní relevantných výsledkov pomocou fulltextového vyhľadávania. Ďalej som zhrnul históriu, možnosti a výhody systému Apache Solr, ako aj knižnice Apache Lucene, ktorú Solr využíva, predstavil administrátorské roz- hranie Apache Solr a uviedol niektoré známe riešenia, ktoré integrujú Apache Solr ako jasnú voľbu pre možnosti vyhľadávania. V rámci praktickej časti som zanalyzoval problém, zanalyzoval štruktúru a typ súborov synchronizovaných na klientsky počítač, navrhol, ktoré sú- bory indexovať v systéme Solr a vyhľadávať nad nimi, následne som vykonal konfiguráciu indexov pre dokumenty aj ich prílohy, namapo- val spomínané typy súborov na Solr a navrhol spôsoby komunikácie so systémom ako aj princíp indexovania v kontexte synchronizácie. Výsledky svojej práce som nechal posúdiť kolegov, ktorý s mojou im- plementáciou ďalej pracovali. Do budúcnosti odporúčam pokúsiť sa implementovať nedostatky, na ktoré bolo poukázané v dotazníku, in- tegrovať najnovšiu verziu Apache Solr ako do offline, tak aj do online riešenia a využiť možnosti Solr na vyššej úrovni, v rámci synchorni- zácie prenášať iba minimálnu množinu dát potrebných na funkčnosť systému, čím sa docieli rýchlejšia synchronizácia dát a je možnosť dosiahnuť ako nižší čas indexovania súboru, tak aj menší celkový index.
43 Bibliografia
1. DARNTON, Robert. What Is the History of Books? Daedalus. 1982 [cit. 2017-05-24], roč. 111, č. 3, s. 65–83. ISSN 00115266. Dostupné tiež z: http://www.jstor.org/stable/20024803. 2. MORERA, Xavier. Getting Started with Enterprise Search Using Apache Solr | Pluralsight [online]. 2014 [cit. 2016-12-14]. Dostupné tiež z: https://www.pluralsight.com/courses/enterprise- search-using-apache-solr. 3. Apache Solr 4.6.0 Documentation [online]. 2013 [cit. 2017-04-13]. Do- stupné tiež z: http://lucene.apache.org/solr/4_6_0/index. html. 4. Apache Lucene - Apache Lucene Core [online]. [cit. 2017-04-13]. Do- stupné tiež z: https://lucene.apache.org/core/. 5. What is Indexing? - Definition from Techopedia [online]. [cit. 2017- 04-13]. Dostupné tiež z: https : / / www . techopedia . com / definition/7705/indexing. 6. KRELLENSTEIN, Marc. Full Text Search Engines vs. DBMS | Lucid Works [online]. 2009 [cit. 2017-04-21]. Dostupné tiež z: https:// lucidworks.com/2009/09/02/full-text-search-engines-vs- dbms/. 7. SIKORA, Radek. Vyhledávání v českých dokumentech pomocí Apa- che Solr [online]. 2012 [cit. 2017-04-25]. Dostupné tiež z: http : //is.muni.cz/th/256499/fi_m/. Diplomová práca. Masary- kova univerzita, Fakulta informatiky, Brno. Vedúci práce Radek OŠLEJŠEK. 8. KASPRZAK, Jan. Distributed Systems for Discovering Similar Do- cuments [online]. 2015 [cit. 2017-04-25]. Dostupné tiež z: http: //is.muni.cz/th/1885/fi_d_b1/. Dizertačná práca. Masary- kova univerzita, Fakulta informatiky, Brno. Vedúci práce Michal BRANDEJS. 9. Full Text Search | Lucid Imagination [online]. [cit. 2017-04-25]. Do- stupné tiež z: https://web.archive.org/web/20101223192214/ http://www.lucidimagination.com/full-text-search.
44 BIBLIOGRAFIA
10. HURLEY, David. The Importance of Indexing [online]. 2014 [cit. 2017-04-25]. Dostupné tiež z: http : / / dbhurley . com / importance-of-indexing/. 11. BLACK, Paul E. Dictionary of Algorithms and Data Structures [on- line]. 2016 [cit. 2017-04-28]. Dostupné tiež z: https://www.nist. gov/dads/HTML/invertedIndex.html. 12. TING, Kai Ming. Precision and Recall - Springer [online]. 2010 [cit. 2017-05-01]. Dostupné tiež z: https://link.springer.com/ referenceworkentry/10.1007/978-0-387-30164-8_652. 13. BUCKLAND, Michael; GEY, Fredric. The relationship between recall and precision. Journal of the American society for information science. 1994 [cit. 2017-05-01], roč. 45, č. 1, s. 12. 14. ROUSE, Margaret. What is false-positive? - Definition from Wha- tIs.com [online]. 2014 [cit. 2017-05-01]. Dostupné tiež z: http:// whatis.techtarget.com/definition/false-positive. 15. Precision and recall [online]. 2014 [cit. 2017-05-01]. Dostupné tiež z: https : / / commons . wikimedia . org / wiki / File : Precisionrecall.svg. 16. KRAMER, Aaron. Introduction to Bayesian Inference [online]. 2016 [cit. 2017-05-01]. Dostupné tiež z: https://www.datascience. com / blog / introduction - to - bayesian - inference - learn - data-science-tutorials. 17. Fulltext search engines - MediaWiki [online]. 2017 [cit. 2017-04-22]. Dostupné tiež z: https://www.mediawiki.org/wiki/Fulltext_ search_engines. 18. KRÁTKÝ, Petr. Vyhledávání v českých dokumentech nad nativním XML úložištěm [online]. 2007 [cit. 2017-05-04]. Dostupné tiež z: http://is.muni.cz/th/60355/fi_m/. Diplomová práca. Ma- sarykova univerzita, Fakulta informatiky, Brno. Vedúci práce Tomáš PITNER. 19. MOLKOVÁ, Lucie. Indexing very large text data [online]. 2011 [cit. 2017-05-04]. Dostupné tiež z: http://is.muni.cz/th/208197/ fi_m/. Diplomová práca. Masarykova univerzita, Fakulta infor- matiky, Brno. Vedúci práce Michal BATKO.
45 BIBLIOGRAFIA
20. HOLUŠA, Jiří. Implementace fulltextového vyhledávání v systému správy požadavků [online]. 2014 [cit. 2017-05-04]. Dostupné tiež z: http://is.muni.cz/th/395871/fi_b/. 21. CHAUHAN, Ankur. Technical Knowledge Sharing Stuff - Origin of Apache Solr [online]. 2014 [cit. 2017-05-02]. Dostupné tiež z: http: //versatileankur.blogspot.sk/2014/04/history- behind- origin-of-apache-solr.html. 22. Apache Solr - Wikipedia [online]. 2017 [cit. 2017-05-02]. Dostupné tiež z: https://en.wikipedia.org/wiki/Apache_Solr. 23. Apache Solr Alternatives and Similar Software - Alternati- veTo.net [online]. 2017 [cit. 2017-05-05]. Dostupné tiež z: http://alternativeto.net/software/apache-solr/. 24. ROUSE, Margaret. What is cache (computing)? - Definition from WhatIs.com [online]. 2015 [cit. 2017-05-05]. Dostupné tiež z: http: //searchstorage.techtarget.com/definition/cache. 25. ERICKSON, Erick. FieldOptionsByUseCase - Solr Wiki [online]. 2010 [cit. 2017-05-19]. Dostupné tiež z: https://wiki.apache. org/solr/FieldOptionsByUseCase.
46