Indexovanie v dokumentoch pomocou platformy Apache Solr

Transcription

1 Masarykova univerzita Fakulta informatiky Indexovanie v dokumentoch pomocou platformy Apache Solr Bakalárska práca Martin Kuchár Brno, jar 2017

2 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

3 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

4 Zhrnutie Práca sa zaoberá možnosťou vyhľadávania dokumentov z medicínskeho prostredia pomocou nástroja Apache Solr. V teoretickej časti práce sa zaoberám problematikou fulltextového vyhľadávania, významom 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 aplikácie, pre ktorú je riešenie poskytnuté. Riešenie je vypracované pre spoločnosť Siemens Healtcare s.r.o. iii

5 Kľúčové slová Apache Solr, Apache Lucene, fulltextové vyhľadávanie, indexovanie, invertovaný index, Service Knowledge Base iv

6 Obsah 1 Úvod 1 2 Fulltextové vyhľadávanie v Apache Solr Základné pojmy Klientska aplikácia Požiadavky riešenia Triedenie výsledkov Zdroje prehľadávaného textu Rôzne váhy informácií v dokumente Používanie synoným Filtrovanie Používanie logických operátorov Používanie zástupných znakov Počty dokumentov v jednotlivých kategóriách Budovanie indexu Ostatné požiadavky Problematika fulltextového vyhľadávania Indexovanie Význam indexovania Príklad záznamu v invertovanom indexe Problém relevantnosti výsledkov Precision a recall False-positive a false-negative problém Softvér poskytujúci fulltextové vyhľadávanie Apache Solr História Apache Solr Apache Lucene Možnosti Solr Administrátorské rozhranie Solr Softvérové riešenia integrujúce Apache Solr Analýza problému Dáta dostupné z aplikácie Súbory nevhodné na indexovanie v

7 5.1.2 Textové dáta vhodné pre indexovanie Analýza dát pre fulltextové vyhľadávanie Štruktúra dokumentov Štruktúra príloh Riešenie problému Indexy SKBOffline Index SKBOfflineAttachments Index Konfigurácia jadier Solr Dopady rôznych nastavení na možnosti Solr SKBOffline SKBOfflineAttachments Návrh komunikácie so systémom Kedy indexovať Kedy získavať potrebné informácie pre užívateľské rozhranie Vyhodnotenie riešenia Tvorba dotazníku Výsledky dotazníku a ich vyhodnotenie Záver 43 Bibliografia 44 vi

8 Zoznam obrázkov 3.1 Grafické znázornenie false-positives a false-negatives a grafická reprezentácia vzorcov pre precision aj recall [15] Ukážka administrátorského rozhrania Apache Solr Zhrnutie dostupných možností a ich dôsledkov na funkcionalitu Solr podľa prípadov užitia [25] Dotaz na Solr s viditeľnou URL, na ktorej je prístupný samotný vrátený objekt Samostatná odpoveď serveru Solr na dotaz Použitie fazetového vyhľadávania pre získanie počtov dokumentov jednotlivých typov Spracované výsledky dotazníku v tabuľkovej aj grafickej podobe 42 vii

9 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 poznatkoch 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 orientovať. 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, nepotrebné 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 loká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 vektorový 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ávaní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 zapracovaní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 Knowledge Base aplikáciu, ktorej ideou je možnosť vyhľadávania v dokumentoch a prílohách off-line. Interný používatelia systému, respektíve 1

10 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šenie 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, uvediem základné pojmy s ktorými sa budem v texte zaoberať, ďalej predstaví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 Apache 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 potom 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 synchronizácie, a akým spôsobom komunikovať so Solr z aplikácie. Nakoniec riešenie nechám otestovať a vyhodnotím. 2

11 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 platforma 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á serverová apliká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 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é vyhľ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 samotný 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 uchovaný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úrovaných údajov z relačnej databázy, ako napríklad nadpisy, abstrakty, alebo bibliografické referencie [6]. 3

12 2.2 Klientska aplikácia 2. Fulltextové vyhľadávanie v Apache Solr Aplikácia, do ktorej bude riešenie fulltextového vyhľadávania pomocou nástroja Apache Solr integrované, sa nazýva KB2GO 1. Jedná sa o internú offline, respektíve desktopovú aplikáciu pre koncern Siemens. 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íctvom 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 SKB 2 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 informovať 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 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

13 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 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 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, boosting 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 zhodou v názve bude vrátený ako relevantnejší oproti druhému 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 špecifikácie formátu pre Solr. 5

14 2. Fulltextové vyhľadávanie v Apache Solr 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 vyhľadávať, produkty, ku ktorým patriace dokumenty chce prehľadávať, verzie softvéru, ak sú dostupné a podobne 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 obsahujúce výraz1 a neobsahujúce výraz 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 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 Budovanie indexu Po každej synchronizácii dát musí byť vybudovaný nový index obsahujúci najnovšie zmeny, teda všetky pridané dokumenty, zmeny všetkých menených dokumentov, a naopak, už nesmie obsahovať dokumenty synchronizáciou vymazané. 6

15 Ostatné požiadavky 2. Fulltextové vyhľadávanie v Apache Solr 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

16 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 dokonca 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čkovanie (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 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 problé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 prehľ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 O(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

17 3. Problematika fulltextového vyhľadávania dosiahnuť až logaritmickú zložitosť O(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 akceptovateľ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 sekundá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 O(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 operač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ňovanie 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ánenie 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

18 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 neindexujú, 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 synonymické 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 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

19 3. Problematika fulltextového vyhľadávania zoznam výskytov v tvare: (<identifikátor dokumentu>, <koľký znak v poradí je prvým znakom slova v dokumente>) Nech máme 3 dokumenty, prvý označený ako 1 a ďalšie analogicky. Nech obsahy týchto dokumentov sú (pre jednoduchosť sú všetky písmená malé): 1: babka varí nedeľný obed, 2: obed je hlavné jedlo dňa, 3: brat je obed. Potom index vytvorený z týchto dokumentov bude vyzerať takto: babka (1, 0), varí (1, 6), nedeľný (1, 11), obed (1, 19); (2, 0); (3, 8), je (2, 5); (3, 5), hlavné (2, 8), jedlo (2, 15), dňa (2, 21), brat (3, 0). Pre príklad vyhľadávania, pre dotaz kto je obed, by sa systém najprv pozrel do takéhoto indexu a hľadal by zvlášť slová z dotazu (techniky lemmatizácie, stemmingu a použitie synoným pre jednoduchosť a prehľadnosť ukážky zanedbáme). Slovo kto sa v indexe nenachádza, prejde sa na slovo je, to našlo v dokumentoch 2 a 3 vždy na piatej pozícii, slovo obed našlo vo všetkých 3 dokumentoch, keďže sa však je v dokumente 1 nevyskytuje, systém vráti iba dokumenty 2 a 3 ako výsledky vyhľadávania. Index môže namiesto pozície znaku daného slova uchovávať poradie slova, tiež môžu mať záznamy rôzne váhy a podobné parametre [11]. 11

20 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 bojovať. Načrtnem tri najčastejšie vyskytujúce sa a riešené problémy s relevantnosťou súvisiace, jeden z nich je v anglickej terminológii označovaný ako precision and recall, druhý false-positive a tretí falsenegative problém 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ávanej databáze. Dá sa povedať, že precision (tiež označovaný ako pozitívna prediktívna hodnota, anglicky positive predictive value) je zlomok vrátených dokumentov, ktoré sú relevantné, a recall (tiež označovaný ako citlivosť, anglicky sensitivity) je zlomok relevantných dokumentov, ktoré sú vrátené (obrázok 3.1). Obe sú teda založené na porozumení a schopnosti 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 tendenciu 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

21 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), nasledované 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] False-positive a false-negative problém False-positive a false-negative problémy sú chybové stavy pri vyhľadá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 kontexte 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 algoritmu. 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 komuniká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] Softvér poskytujúci fulltextové vyhľadávanie Nasleduje zoznam niekoľkých riešení ponúkajúcich možnosti fulltextového vyhľadávania a indexovania. Všetky uvedené produkty sú bezplatné a majú verejný zdrojový kód. 13

22 3. Problematika fulltextového vyhľadávania Obr. 3.1: Grafické znázornenie false-positives a false-negatives a grafická reprezentácia vzorcov pre precision aj recall [15] 14

23 3. Problematika fulltextového vyhľadávania Clusterpoint server 1, Ioda 2, DBSight 3, Domino 4, KinoSearch 5, Sphinx 6, Lucene-search 7, Pylucene 8, Plucene 9, Apache Solr 10 [17] pod

24 4 Apache Solr Solr je rýchla a populárna podniková vyhľadávacia platforma 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á serverová apliká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 programovacieho jazyku. Apache Solr je dodávaný ako samostatná aplikácia, anglicky standalone application, s užívateľským administrátorským rozhraním, ktoré umožňuje správu systému, dokumentov, samotné vyhľadávanie 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 kapitoly. 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ávacej 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 podprojektom 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 na verziu 3.1, aby sa zhodovala s verziou Lucene). V októbri 2012 bola vydaná verzia Solr 16

25 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 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 aplikáciu vyžadujúcu fulltextové vyhľadávanie. Veľkou výhodou je podpora multiplatformových riešení. Lucene má verejný zdrojový kód od roku 2000, keď ho jeho autor, Doug Cutting, zverejnil na serveri SourceForge 1. 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 nadstavbou 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 neobmedzujú. Solr zas ako spustiteľná aplikácia vystavuje vývojára istým obmedzeniam, ktoré vyplývajú zo samostatnosti systému. Je všeobecne odporúčané, pokiaľ nemá účel vyhľadávania príliš špecifické požiadavky, alebo pokiaľ vývojár, respektíve vývojári daného systému nemajú 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

26 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ť indexovanie, 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ý caching 2, 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

27 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é rozhranie 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átorské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širovaniu 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: Netflix 3,

28 4. Apache Solr Obr. 4.1: Ukážka administrátorského rozhrania Apache Solr whitehouse.gov 4, Instagram 5, The Guardian 6, AOL 7, 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]

29 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 rozhodnutí 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ň poskytuje 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ôsobom 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 priblíž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čiatoč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žívateľ, 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. ACL 1, 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ôsobiť 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

30 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 vzdialeného serveru. Všetky súbory prislúchajú k istým produktom. Pri zvolení produktov na inštaláciu sa vytvárajú pomocou tzv. packaging 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 obsahuje súbory formátov pdf, doc, docx, docm a iné formáty prislúchajúce balíčku MS 2 Office, txt, jpg, png, gif a iné obrázkové formáty, a v neposlednom 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 obsahuje súbory formátu skbdoc. Tieto súbory sú čisto textového charakteru. SkbDocuments: SkbDocuments adresár, podobne ako SkbAttachmentsTexts, obsahuje čisto textové súbory formátu skbdoc. 2. Microsoft 22

31 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 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ť Textové dáta vhodné pre indexovanie Ako bolo vysvetlené v predošlej kapitole, súbory z adresáru SkbAttachmentsBinaries nebudú mať so systémom Solr nič spoločné. S predpokladom, ž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

32 5. Analýza problému spomenutom je možné nájsť práve textovú reprezentáciu súborov z prvé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 štruktú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 dokumentov 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 informá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 zobrazované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 nebudú 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 Štruktúra dokumentov Ako som už spomínal, dokumenty sú súbory s príponou skbdoc. Obsahujú 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ý predstavuje identifikátor dokumentu, ktorý je jedinečný pre každý dokument. Ďalej je prítomná verzia _version_, ktorá má pri sebe číselnú hodnotu. Táto verzia je prenesená z online databázy, a teda odzrkadľuje 24

33 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 informá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 textov, 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ť dokumentu 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é polož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_version, 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í. Polož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

34 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, resolution_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 Štruktúra príloh Prílohy, rovnako ako dokumenty, sú súbory s príponou skbdoc nesú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 prislúcha, _version_, synchronization_id, bulk_synch_id a synchronization_date. Ďalšími údajmi, ktorými takáto príloha disponuje, 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 <doc_key> <file_id> <page_nr>, ktoré je unikátne pre každú prílohu typu skbdoc. Ďalej to je mime_- type s informáciou o type súboru, napríklad pri type pdf to je text application/pdf, file_size s číselným údajom o veľkosti súboru v bytoch a nakoniec položky att_text, att_text_phrase a att_text_- hl, ktoré obsahujú identický text. 26

35 6 Riešenie problému Integrácia systému Solr do aplikácie je riešená zakomponovaním celého systému stiahnuteľného zo stránok Apache Solr 1 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ť analyzovať 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 dopady 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ý pohľ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

36 6. Riešenie problému 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 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čení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 povedať 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

37 6.2.1 Dopady rôznych nastavení na možnosti Solr 6. Riešenie problému 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ískavanie 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

38 6. Riešenie problému Obr. 6.1: Zhrnutie dostupných možností a ich dôsledkov na funkcionalitu 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 indexovaní 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 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ďovanie 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é vytvorení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

39 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 indexovať 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 nastavené multivalued= true. Ako jednoznačný identifikátor som určil doc_key, takže ten bude ako jediný vyžadovaný (bude mať required= 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

40 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 filtrovania 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 spomeniem 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 rozdeliť 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 za iné 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

41 6. Riešenie problému Pod konfiguráciou updatehandleru sú definované dva typy na vykonanie zmien ( commit ), a to autocommit a autosoftcommit. AutoCommit definuje, ako často sa ukladá zmenený index na pevný 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 RAM 2. 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é nakonfigurovať. 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 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 dokumentov, to platí pre všetky časti schémy. Znamená to, že bude vytvorená 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 dokumentom 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 recyklovať definíciu vlastných dátových typov. 2. Random Access Memory 33

42 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 medzier 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 requesthandlery /select, kde ako základná položka na hľadanie výskytu hľadané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 podrobnosti, č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ť zadefinovaný 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

43 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ť prostrední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 Kedy indexovať Jedným z posledných úkonov je navrhnúť, kedy vykonávať indexovanie dát. Princíp synchronizácie, typy synchronizácie a aj rôzne dôsledky synchronizácie som už opísal. 35

44 6. Riešenie problému Obr. 6.3: Samostatná odpoveď serveru Solr na dotaz 36

45 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) 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 rozhraní 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 indexovaných dokumentov. 37

46 6. Riešenie problému Obr. 6.4: Použitie fazetového vyhľadávania pre získanie počtov dokumentov jednotlivých typov 38

47 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 poskytnuté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 poskytnutý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 najobjektí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 dokumentoch, 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žívateľ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 API 1. 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 nasledovne: 1. Application Programming Interface 39

48 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 kladený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, indexovanie a vyhľadávanie je intuitívne., Riešenie spĺňa alebo podporuje 40

49 7. Vyhodnotenie riešenia spĺňanie všetkých požiadaviek. a v neposlednom rade Nakoľko apliká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šenia 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 problé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 vylepš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 predpokladateľ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 obrázku

50 7. Vyhodnotenie riešenia Obr. 7.1: Spracované výsledky dotazníku v tabuľkovej aj grafickej podobe 42