search

LIBCAS / DL4DH

DL4DH – development of tools for effective utilization and mining of data from digital libraries to reinforce digital humanities research
GNU General Public License v3.0
8 stars 2 forks source link

KRAMERIUS + : Volba vhodne technologie baze, indexu a endpointu #14

Closed JanMeritus closed 2 years ago

JanMeritus commented 3 years ago

Princip navrhu

Obecne bude treba stanovit vhodne technologie reseni a pohybovat se idealne v jejich hranicich. Proto si myslim ze v tyto fazy je dulezite si ujasnit technologie, ktere by ale po dosazeni pouzitych reseni a jejich vztahu (Baze, Index, Scheduler, Endpointy) mali vytvorit provozuschopny system, nepohybujici se vo vyjimkach a solidni prostor a skalovatelne zazemi pro uzivatelske dotazy, exporty a prip. dalsi integrace.

1. Baze myslim ze tento bod si vyzaduje (protoze jde obecne o volbu nosne technologie na pristi leta) hlubsi analyzu ze strany dodavatele a idealne nejake easy POC, protoze jedna vec je

  1. teoreticke rozhodnuti o vhodnosti objektovejsiho vs semantickejsiho modelu (oba vsak dokazu byt nastavitelny jednou nebo druhou technologii: NoSQL / TripleStore - a v obou pripadech jde v podstate o grafove baze)
  2. komplikovanost instalace technologii a jejich sprava na konkretnich ruzne velkych instancich DK vcetne prubeznych migraci v nich uskladnenych (vyhledove nemalych) dat a jejich remodelaci dle prubezne rozvijenych datovych modelu
  3. komplexita a vhodnost zvoleneho reseni, vyvoj do budoucna, podpora a adopce zvolene technologie

Navrh:

2. Indexy

3. Scheduler Zde je nutno se zamyslet nad dotazmi z interfacu a rizenim odpovedi na ne - a schedulovanim a pridelovanim priorit jednotlivych dotazu a pridelovanim systemovych prostredku. Rata se ze ne vsechny dotazy muzu byt zodpovedeny on the fly, bude je treba stackovat a ridit

4. Endpointy

bodnarIQ commented 3 years ago

Po konzultácií s pánom Klímkom nie sme za to implementovať K+ použitím TripleStore. Pán Klímek, jakožto expert na problematiku LOD, poukázal na možné problémy do budúcna pri snahe vystaviť dáta ako LOD, a nemuselo by to mať v konečnom dôsledku požadovaný výsledok. Museli by sme riešiť Entity Linking, prepojenie s externými databázami, odhadovanie zložitosti SPARQL dotazu, vystavenie minimálne troch endpointov pre dotazovanie nad TripleStorom(jeden pre RDF dump, jeden pre zobrazenie konkrétnej entity a jeden pre pokročilé SPARQL dotazy). SPARQL dotazy môžu byť veľmi zložité z výpočetného hľadiska a muselo by to bežať na pomerne výkonných strojoch(finančne náročné riešenie). Museli by sme vytvoriť vlastné slovníky, ktoré definujú triedy a vlastnosti použité v grafoch. Navrhovali by sme preto systém pripraviť pre možnosť implementácie triplestoru v budúcnosti popri primárnej DB, na ktorej K+ bude postavený.

1. Baze

  1. teoreticke rozhodnuti o vhodnosti objektovejsiho vs semantickejsiho modelu (oba vsak dokazu byt nastavitelny jednou nebo druhou technologii: NoSQL / TripleStore - a v obou pripadech jde v podstate o grafove baze)

Rád by som upresnil typy databázových technológií, aby sme tomu rozumeli jednotne. NoSQL databázy sa (okrem iného) vyznačujú najmä tým, že nemajú preddefinovanú štruktúru, ktorej sa ukladané dáta musia striktne držať. Pod tento typ patria napríklad aj grafové databázy(pod ktoré patria TripleStore databázy), nejde ale o rozdelenie NoSQL / TripleStore. Nie je pravda, že ide v oboch prípadoch v podstate o grafové databázy. Pod NoSQL databázy môžu patriť aj iné typy databáz, napríklad dokumentové db(MongoDB), wide column db(Apache HBase) alebo Key-Value db.

Ešte trochu viac do detailu by som rozvinul grafové databázy. Tie sa delia v podstate na dva typy: RDF store (==TripleStore) a LPG(Labeled Property Graph). Ak sa teda bavíme o TripleStore, bavíme sa v podstate o RDF store, čo je podmnožina grafových databáz. Pripravil som si diagram popisujúci stručný prehľad databázových technológií, ktorí si prípadne môžeme prejsť aj na najbližšom meetingu, ak bude potreba.

V skratke, hlavný rozdiel medzi RDF a LPG grafovými databázami je ten, že RDF ukladá trojice primitívnych hodnôt, zatiaľ čo v LPG môžu mať trojice (uzly aj hrany grafu) internú štruktúru. SPARQL jazyk je určený pre prácu s RDF, tým pádom je primárne určený pre používanie najmä pri RDF(TripleStore) databázach.

  1. komplikovanost instalace technologii a jejich sprava na konkretnich ruzne velkych instancich DK vcetne prubeznych migraci v nich uskladnenych (vyhledove nemalych) dat a jejich remodelaci dle prubezne rozvijenych datovych modelu

NoSQL databázové technológie sú vo všeobecnosti horizontálne škálovateľné. Keďže nemajú pevne danú štruktúru, v rozvíjaní datvých modelov a remodelaci nevidím problém. Tento bod by som označil za implicitne splnený pri použití ľubovoľnej NoSQL databázy. Až teda na komplikovanosť inštalácie, k čomu sa ale momentálne nedokážem vyjadriť, ale považujem to za nie až tak zásadný problém, ktorý by sme riešili až po splnení ostatných kritérií na voľbu DB technológie.

  1. komplexita a vhodnost zvoleneho reseni, vyvoj do budoucna, podpora a adopce zvolene technologie

Osobne vidím použitie grafových databáz ako komplexnejšie na vývoj a používanie, samozrejme s prínosom širšej funkcionality. Celkovo sú NoSQL databázy(v porovnaní s SQL) flexibilnejšie, menej obmedzujúce a za mňa ideálne pre ponechanie priestoru pre rozvoj v budúcnosti.

pred roky se rozhodlo o smerovani na triplestore, ale doted se s tim knihovny borili

  • sprava teto technologie na denni bazi pro male DK neni vubec jednoducha
  • ne vzdy je k dostani dostatocna dokumentace k potrebnym issues vyplyvajicim z pouzite technologie zmeny ve vyvoji konkretni TS implementace ze strany vydavatele technologie vedli k jeji opusteni a zahozeni nove verze Krameria a obecne ted uz min. 2 rocnimu setbacku na hlavni vetvy vyvoje
  • bez POC, prip. kapacitniho testu nebo vyjadreni skuseneho databazoveho architekta nevidim schopnost kvalifikovane rozhodnout o vhodnom reseni, ktere je ale zasadni pro uspech projektu

Reprezentovanie kompletného obsahu K+ cez TripleStore si neviem predstaviť, pretože vidím veľký problém s prepájaním metadáta s konkrétnymi slovami. Spomínali sme, že by každý uzol v grafe vyjadroval jedno slovo, tým pádom graf by bol síce veľký, ale obmedzený(existuje iba obmedzené množstvo slov, ktoré narastá pomaly). V takomto riešení vidím hlavný problem ten, že by sme nedokázali spätne vyčítať relevantné údaje. Uvediem príklad: Text stránky by sa obohatil o metadáta z UdPipu. Token stromu by sa obohtail o lemmu strom a pádom GENITÍV. Toto by sme v grafe vyjadrili trojicou stromu-lemma-strom a stromu-pád-GENITÍV. Slov stromu by sa ale v texte, alebo kľudne aj v inej publikácií, vyskytoval aj v páde inom - DATÍV, a už by nastal problém. Nemôžeme prepojiť už existujúci uzol strom v grafe s novým uzlom GENITÍV, pretože by sme po vyťahovaní metadát stratili kontext - nevedeli by sme spätne zistiť, o aký pád sa jedná v stránke, s ktorou aktuálne pracujeme. Riešením by bolo vytvárať samostatné uzly pre každé slovo, toto by už ale neznamenalo konečnú veľkosť grafu a graf by dosahoval extrémne veľkosti.

Potencionálnym riešením vidím vytvorenie uzlov iba pre výstupy z NameTagu, kde by nezáležalo na kontexte, a uzly reprezentujúce obsah by neboli na úrovni slov, ale na úrovni stránky. Na toto by sme mohli použiť grafové databázy typu LPG, kde by uzli reprezentovali stránky, mali by internú štruktúru, ďalšie uzly by reprezentovali lemmu alebo rozpoznané entity, a hrany medzi týmito uzlami by mohli mať takisto internú štruktúru, kde by bol konkretizovaný vzťah medzi uzlami, príklad: pidStranky123{obsah:...., metadata:....} - lemma{startOffset=0, endOffset=10} - STROM. Takouto databázou je napríklad Neo4J. Tu by ale už nebolo možné použiť SPARQL, pretože LPG databázy majú väčšinou svoje vlastné jazyky(napr. u Neo4J je to jazyk CYPHER, ktorý je podobný SPARQL, ale trochu jednoduchší a intuitívnejší na použitie). Samozrejme by uz nešlo o vystavenie dat ako LOD, ale skôr o akési nasimulovanie LOD. Toto by ale tiež malo svoje obmedzenia a potencionálne problémy.

Navrhoval by som preto použiť spôsob, ktorý nebude brániť budúcemu rozvoju systému o vystavenie dát ako LOD. V podstate by sme postavili K+ na NoSQL DB(napr. MongoDB, keďže pracuje s dokumentami, ktoré sa jednoducho reprezentujú v aplikačnej vrstve) a v budúcnosti by bola možnosť vystaviť popri primárnej DB ešte grafovú DB, ktorá by slúžila pre SPARQL dotazovanie a vystavenie dát ako LOD. Pokročilé dotazovanie by bolo primárne využitím SOLR endpointu.

V pripade ze by melo jit o naozaj skalovatelny reseni s vizi do budoucna, premyslel by som nad shardovatelnymi bazemi schopnymi mohutnych operaci, ktere muzu, ale nemusi nutne vzdy byt semanticke, to uz zalezi jak by sme si nastavili pro konkretni data nebo casti dat. To je zasadni vyhoda oproti jinym technologiim, ktere jsou se svym modelem dat ovela silnejsie provazany.

Všetky NoSQL DB(aspoň s ktorými som sa doposiaľ stretol) sú horizontálne škálovateľné, t.j. podporujú shardovanie.

Trochu sem premyslel a zde mi vylozene nejlepe vychazi napr. Apache HBase, prip. jeho interpretace Jena-HBase nebo jeji rychlejsi braska Hive-HBase (obidva vic out-of-box RDF oriented). Obecny HBase se da pouzit k mnoha ucelum a je kompatibilni napr. se SPARQL a celym polem dalsich technologii, navyse je to solidni SW schopni pracovat s PB dat, metadat a cehokoliv co vyvstane. Druhym dalsim podobnym kandidatem je Apache Cassandra. Cassandra i nativni HBase jsou shardovatelny, rozumi si s distribuovanymi a cloudovymi systemami. Nevyhodou teto technologie, pokud by se nedodavala napr. pro male instance v ready made dockru s virtualizacnim overheadem, je relativne zlozite nasazeni a sprava, vyhodou ze jde o siroke nasazeni a industrialni a dlouhodobe skalovatelny standard.

Pozeral som sa na HBase, a HBase je wide column store, čo je niečo medzi document store a relačnou databázou. Pracuje so stĺpcami a skupinami stĺpcov, t.j. v podstate je to tabuľka, v ktorej nemusí každý riadok využívať rovnaké stĺpce. To má prevažne využitie v systémoch, kde sa evidujú údaje o osobách, kde rôzne osoby môžu mať rôzne skupiny atribútov. Nevidím prínos takejto databázy v systéme K+, použitie document store mi príde vhodnejšie.

-- to be continued --

JanMeritus commented 3 years ago

@bodnarIQ @bukovskyIQ za mne zduvodneni od experta OK, reseni nastinene v jinem issue ok. Ohladom TS vs NoSQL urcite su vic za NoSQL, mame s nima pozitivni zkusenosti ve vyvoji a dle meho jsou i pro jine spravce o neco jednodussi nez sprava TS, pokud samozrejme vsechny CRUD operace jsou radne osetreny a nedochazi k nekonzistencnemu vnaseni.

Ad wide column db, je velice variabilni a neni to jen tabulkova baze. Jde o hybridni bazi spojujici ruzne typy ruzne strukturovanych dat do sloupcovych rodin a muze fungovat jako NoSQL. Prosim este o prohloubeni teto odpovedi.

Poprosim rovnez o naznaceni reseni 2-4.

bodnarIQ commented 3 years ago

Aktuálne pracujem na analýze wide column store vs document store, a narazil som na potencionálny problém v modele metadátového stromu - môže nastať situácia, že NameTag rozozná zanorené entity takým štýlom, že sa to nebude dať zapísať v stromovej štruktúre? T.j., zanorené entity by sa viazali k viacerým nadradeným rodičom zároveň, alebo opačný príklad, rozoznaný podtyp by sa neviazal na niektorý nadradený nadtyp? Nenapadá ma žiadny príklad, tak to skúsim nasimulovať na ukážke: (tagy ne type="ic" a ne type="gu") image

Pri snahe znázorniť problém som si uvedomil, že keďže NameTag ponúka výstup vo formáte XML, tak takáto situácia nemôže nastať, keďže XML formát má stále valídnu stromovú štruktúru, no aj napriek tomu by som bol rád za potvrdenie.

zabak commented 3 years ago

V Krameriu 7 budou virtuální sbírky, kde každá sbírka může obsahovat jakékoli jiné objekty, nebo i jiné sbírky, teoreticky i sama sebe.

bodnarIQ commented 3 years ago

Hlavným dôvodom, kvôli ktorému sme boli proti použitiu wide column store databázy je to, že nemôžeme ukladať objekty so zanorenou dátovou štrukturou (návrh nášho riešenia je metadatovy strom), keďže wide column DB ukladá data do tabuliek zložených zo stĺpcov a riadkov.

Prakticky by sme mali tri možnosti:

Tento tretí bod sme vylúčili kvôli priestorovej neefektívnosti - ukladali by sme informáciu, že sa jedná o rozpoznanú entitu typu X pri každom tokene. Po opätovnom zvážení by toto nemusel byť až taký problém, pretože informáciu o tom, že sa jedná o rozpoznanú entitu vieme vyjadriť jednoduchými flagmi/pár bytov. Zároveň to vidím ako jediné zmysluplné riešenie, ktoré by sme pri využití wide column store mohli použiť, preto som sa zameral podrobnejšie na tento spôsob ukladania a pokúsil som sa navrhnúť, ako by to pri použití wide column store mohlo vyzerať.

Takéto riešenie by znamenalo, že každý token by musel existovať v DB ako entita(riadok v tabuľke), aby sme na ňu mohli naviazať jednotlivé atribúty(stĺpce), a tým pádom by každý token musel byť jednoznačne identifikovaný nejakým ID. Každý token je jednoznačne identifikovaný UUID stránky + offsetom. Tokeny by museli byť uložené v samostatnej tabuľke a tým pádom by sme mali min. 3 tabuľky:

Pri každom dotazovaní na celý obsah konkrétnej strany publikácie by sa musel robiť JOIN všetkých tokenov, ktoré sa viažu k danej stránke, čo mi príde ako neefektívne riešenie. Takéto riešenie by bolo vhodné, ak by sme mali use casy, kedy by sme potrebovali vyťahovať jednotlivé tokeny samostatne, nezávisle od toho, k akej stránke patria, no my ich stále budeme vyťahovať iba v kontexte celej stránky, nebudeme mať usecasy, kedy by sme sa potrebovali dotazovať na množinu tokenov, ktoré nepatria pod rovnakú stránku (vyhľadávanie, filtrácia a pod. pôjde cez SOLR, nebudeme riešiť na úrovni DB).

Výhodou wide column store je ich rýchlosť dotazovania pri veľkom počte riadkov nad jednotlivými stĺpcami, pretože interne sa ukladajú všetky stĺpce do samostatného súboru, a pri sekvenčnom prehľadávaní nad konkrétnymi stĺpcami sa nemusí prechádzať celý obsah tabuliek, ale iba celý obsah konkrétneho stĺpca. Toto ale vo všeobecnosti nebude náš usecase, pretože stále budeme pracovať s tokenmi v kontexte stránky a vyhľadávanie, filtrácie, agregácie pôjdu opäť cez SOLR(až na jeden konkrétny prípad, a to dotazovanie na všetky tokeny pre danú stránku - vyhľadávanie tokenov v stĺpci pageId)

Toto vidím ako jeden z hlavných dôvodov, prečo wide column store nebude efektívne riešenie. Pri každom dotaze na stránku publikácie/celú publikáciu bude DB musieť vyťiahnuť stovky(pre stránku) až desattisícky(pre publikácie) riadkov z tabuľky tokenov, a keďže sa bude vyťahovať celý obsah, nie iba konkrétne stĺpce, nevyužijeme výhodu efektívneho dotazovania nad stĺpcami - nevyužijeme výhody wide column store.

Ďalší problém by bolo ukladanie metadát z nástroja NameTag. NameTag môže pre jeden token vrátiť viac typov NE. Toto by sme vo wide column riešení mohli riešiť dvomi spôsobmi:

V oboch prípadoch by sme ale stratili informáciu o hierarchii rozpoznaných entít, a museli by sme ju spätne zistiť podľa typov NE na za sebou idúcich tokenoch (mohlo by byť náročné).

Tabuľka pre jednotlivé tokeny by mohla vyzerať nejak takto(Rozdelená na column families - stĺpce pre metadáta o tokene, metadáta z ALTO, metadáta z UdPipe, metadáta z NameTag, ...)

image

Pri použití document store DB by ukladaná entita bola objekt reprezentujúci jednu stranu, kde by boli všetky metadáta po kope pod jedným atribútom. Toto je za mňa lepšie riešenie, pretože ako som už spomínal, nebudeme vykonávať RETRIEVE samostatných tokenov z DB - stále budeme vyťahovať minimálne celý obsah strany (a prípadne filtrovať odpoveď na aplikačnej vrstve).

Hlavnými implementačnými rozdieľmi by tým pádom boli:

JanMeritus commented 3 years ago

Za mna asi v obecnosti je asi v poriadku pre pouzitie hierarchickeho stromu a document storu (trochu mi ale planovany sposob implementacie pripomina logiku sucasnej implementacii vo Fedore/ vs SOLR). Mam len par pripomienok k reflexii. Po poslednych skusenostiach, proste len chcem aby vybrane riesenie bolo dobre zdovodnene a nasledne sa neukazalo, ze sa s nim viazu koncepcne problemy co sa tyka jeho provozu a rozvoja.

Pripomienky:

bodnarIQ commented 3 years ago

V prvom rade by som chcel ujasniť, že pri "metadatovom strome" myslím spôsob ukladania textového obsahu(jednotlivých tokenov) a ich metadát pre danú stránku v stromovej štruktúre, kde listy stromu reprezentujú jednotlivé tokeny, a všetky ostatné uzly nesú nejaký typ metadátovej informácie, ktorá je spoločná pre všetkých potomkov daného uzlu(napr. výstup z nástroja UdPipe vytvorí rodičovský uzol pre každý listový uzol v strome, nástroj NameTag potom môže vytvoriť rodičovské uzly pre tie uzly, ktoré sú na ceste k tokenu, ktorý bol rozoznaný ako NE), nemyslím tým žiadnu hierarchiu ukladania objektov(stránky, publikácie, ročníky periodik a pod.).

vychadza sa z predpokladu ze Kramerius je prisne hierarchicky a diela su tiez v prisne hierarchickom modeli. Toto ponatie ma svoje pozitiva i negativa, je nutne mat absolutnu istotu ze neexistuje nic mimo A. hierarchie, B. pripadne moznosti to tam nejak rozumne dotlacit (uz B je designovy a logicky kompromis)

môže existovať nejaké iné rozdelenie diel, než hierarchické?

prosim o dosledne rozdelenie uvazovania o reprezentacii v indexe a v DB a ucele oboch zdrojov dat: "Pri každom dotazovaní na celý obsah konkrétnej strany publikácie by sa musel robiť JOIN všetkých tokenov, ktoré sa viažu k danej stránke, čo mi príde ako neefektívne riešenie" Nie nutne. DB by sa nikto nemal z uzivatelov dotazovat priamo, mala by sluzit pre obsluhu backendu, pripadne povolene specifickeho dotazovania a ultimativny zdroj masterdat, napr pre ich remodelaciu v navazujucich reprezentaciach. V indexe kludne moze byt hierarchicka reprezentacia a naproti tomu v db moze byt cokolvek co vyhovuje poziadavkam na masivny store mnohych miliard kombinacii (viz nizsie) - pokial sa to vie nasledne rozumne zaindexovat. Aj ak by DB bola poriadana hierarchicky (napr. kvoli jednoduchsiemu prenasaniu do indexu, ci obecnemu zjednoduseniu operativy), nemala by sluzit ako primarny provozny zdroj. K tomu sa vracia napr. v momente zmeny logickeho modelu. Samozrejme je to otazka zdovodneneho designu, ale znova mi to zavana, ze pokial by sa tak vyuzivala, budeme sa dostavat do paralely Fedora / SOLR, Opakujem, v tomto bode ide o dve veci - technologia storu, a sposob jeho zaclenenia do ekosystemu aplikacie (kludne napr 1. hierarchicka DB, 2. ale mimo beznu user oriented operativu, user reprezentacia inde, rsp oddelene)..

Výhodou ukladania metadát vo forme metadatoveho stromu je hlavne pomerne snadný prevod do TEI formátu a možnosť určovať metadáta pre viaceré tokeny na jednom mieste, založením nového uzlu(napr. pre označenie, že sa jedná o prvý odstavec od prvého do 115-teho tokenu v texte by vznikol jeden uzol, ktorý by všetky tieto poduzly uložil ako svoje child uzly). Nevýhodou bude zložitejší update a práca so stromom - nutnosť implementovať algoritmy pre vkladanie uzlov do stromu, a obmedzenie hierarchického usporiadania - ak by sa napr. prekrývali child uzly viacerých parent uzlov, bol by to problém. Možno by preto stálo za zváženie vyhnúť sa tejto zložitosti a predsa len využiť wide column store pre ukladanie master dat. "Pri každom dotazovaní na celý obsah konkrétnej strany publikácie by sa musel robiť JOIN všetkých tokenov..." Dotazovanie do master DB bude hlavne pri indexovani obsahu do SOLRu a pripadne pri prevode do TEI(ktory by asi mohol byt tiez iba z dat zo SOLRu, no dava mi zmysel posielat do TEI Convertora master data priamo z DB). Je preto pravda, že to nebude veľmi často vykonávaný úkon, takže vyššie spomínaná nevýhoda nebude až taká závažná. V indexe nebude hierarchia typu metadatovy strom - pri vyhladavani by sa to nedalo pouzit, pri SOLRu dáva zmysel indexovať iba dvojúrovňovú hierarchiu - každý objekt(strana) bude mať pole tokenov s metadátami(flat štruktúra, odpovedajúca ukladaniu tokenov vo wide column store), ktoé budú zaindexované a bude sa dať nad nimi vyhľadávať.

virtualne zbierky su gamechanger a model by s nimi mal pocitat, @zabak . (nech uz bude DB akakolvek) Uroven stranok a tokenov nie su jedine s ktorymi treba pocitat. Medzi nimi treba v ramci realneho vyuzitia kolekcii pocitat plan vyuzitia vystrizkov zo stran (podobne to maju v Polsku). Do do zbierky sa budu moct kombinovat rozne vystrizky z jednej alebo viacerych stranok z jedneho alebo viacerych IEntit (UC, napr len clanky urcitych autorov z novin a serialov, ci ich elementy). Hierarchia si s nimi moze poradit ale proste treba pocitat s vedenim a operativou zdruzenia v roznych medziuzloch.

Sú virtuálne zbierky to isté, ako užívateľské kolekcie? Sú výstrižky v K reprezentované podla standardu samostatnými objektmi - InternalPart ? Ak tomu správne rozumiem, pri periodikách sa používa hierarchia Periodikum - Ročník vydania - Strana - Interná podčasť(reprezentujú výstrižky?). Každopádne, v screenshote tabuľky vyššie by sa pre umožnenie pracovať s rôznymi hierarchiami zmenil stĺpec pageId pri tokenoch na parentId, aby sme neobmedzovali, že token musí byť hierarchicky na úrovni hneď pod stránkou.

bodnarIQ commented 3 years ago

Po prečítaní dokumentácie pre HBase som opäť toho názoru, že by sme mali ako primárne úložisko master dát použiť MongoDB. Hlavnými dôvodmi sú:

Rozdelenie ukladaných dát

Pri využití HBase by sme museli ukladať dáta do riadkov, čo by malo za následok ukladanie každého tokenu ako samostatný riadok v tabuľke. Tokeny, ktoré patria spolu (rovnaká strana/rovnaká publikácia) by boli uložené na jednom mieste na disku vďaka tomu, že HBase ukladá riadky zoradené v abecednom poradí podľa row key . Pri dobrom návrhu row key by sme zaručili, že tokeny, ktoré idú za sebou, budú uložené v DB za sebou(row key by sa skladal napr. z uuid_publikacie:uuid_stranky:startOffset_endOffset, pri viacúrovňových hierarchiach by sa pridalo viac prefixov, tým pádom by boli uložené tokeny v tom poradí, v akom sa vyskytujú v publikácií). Boli by sme ale obmedzení na max 2/3 column families - skupiny stĺpcov.

Z dokumentácie:

HBase currently does not do well with anything above two or three column families so keep the number of column families in your schema low.

Názvy stĺpcov by mali prefix nástroja, ktorý dáta v danom stĺpci generuje. Pri nameTagu by boli mnohé stĺpce prázdne, čo nevadí, pretože prázdne stĺpce HBase reálne neukladá. Tým pádom by tabuľka pre ukladané tokeny vyzerala nejak takto: image (s rozdielom v názve Row Key, ktorý som spomínal vyššie)

Presnejšia vizualizácia ukladania by bola vyjadrením nie v tabuľkovej forme, ale v JSONe: image (V JSONe som pre jednoduchosť vynechal verzovanie, ktoré HBase tiež podporuje, viacmenej ide iba o pridanie zanorenia v každom atribute, kde sa navyše ukladá aj timestamp, kedy bola hodnota vložená)

Každá hodnota buňky je jednoznačne identifikovaná row key - columnFamily:column. V JSON vyjadrení vidíme, že sa hodnoty prázdnych stĺpcov vôbec neukladajú, takže nezaberajú miesto. Na druhej strane ale vidíme, že sa názov stĺpca ukladá pri každom tokene, takže pre minimalizovanie miesta sa odporúča držať názvy stĺpcov čo najmenšie - ideálne 1-2 znaky.

Pri takomto ukladaní je výhodou HBase rýchle vyhľadávanie v konkrétnych stĺpcoch, čo my nebudeme pri práci s master DB potrebovať. Všetko naše vyhľadávanie by malo íst cez SOLR indexy. Zároveň najmenšou jednotkou, s ktorou budeme v systéme pracovať, je stránka(nejaké vyjadrenie stránky - tým myslím výstup skenu OCR obohatený o metadáta získané z nástrojov UdPipe a NameTag) a menšie delenie ukladaných dát na jednotlivé tokeny je zbytočné, keďže budeme stále pristupovať k množine tokenov, ktoré spolu súvisia = ležia na rovnakej stránke, v presne definovanom poradí.

"Pri každom dotazovaní na celý obsah konkrétnej strany publikácie by sa musel robiť JOIN všetkých tokenov, ktoré sa viažu k danej stránke, čo mi príde ako neefektívne riešenie" Nie nutne. DB by sa nikto nemal z uzivatelov dotazovat priamo, mala by sluzit pre obsluhu backendu, pripadne povolene specifickeho dotazovania a ultimativny zdroj masterdat, napr pre ich remodelaciu v navazujucich reprezentaciach.

Súhlasím, no pri každej remodelácií/indexácií/práci s dátami na backende budeme pracovať s nejakým objektom na úrovni stránky, nie? Nevidím usecase, kedy by sme chceli vytiahnút z DB tokeny, ktoré nepatria na spoločnú stránku, prípadne ktoré nie sú v poradí, v akom sa vyskytujú na stránke.

Preto si myslím, že by sme sa mali zamerať na taký typ ukladania, kde získame jedným prístupom do DB všetky tokeny + metadata minimálne pre jednu stránku.

Flexibilita

Pri HBase môžeme pre každý riadok(rowKey) pridať iba novú dvojicu stĺpec:hodnota. Pri MongoDB môžeme pridať pre každý uložený dokument atribút ľubovoľného typu, kludne aj vnorený JSON objekt s internou štruktúrou. Toto považujem za lepšie riešenie s prihliadnutím na možný budúci rozvoj, keďže nie sme limitovaný na jednoduché key/primitive value hodnoty(HBase), a môžeme ľubovoľne meniť už uložené dokumenty - napr. pri zmene štruktúry alebo remodelovaní. Pri HBase by sme pri zmene štruktúry ukladania museli znovu spracovať dáta a vytvoriť novú schému tabuľky.

Objem dát

Myslím si, že MongoDB ponúka väčšiu funkcionalitu, robustnosť a flexibilitu oproti HBase. Preto otázkou zostáva iba performance pri extrémnych objemoch dát. MongoDB je (ako všetky NoSQL db) horizontálne škálovateľný - pri veľkých objemoch sa kolekcie shardujú a rozdeľujú medzi viaceré clustery. To znamená, že teoreticky neexistuje limit ukladaného objemu(stále sa dá pridať nový cluster). Väčšina záťaže pri dotazovaní by mala byť aj tak na SOLR, ktorý nejakým spôsobom vráti pole UUID vyhovujúcich pre daný dotaz, ktoré by sa následne fetchli z MongoDB. Tým pádom ide hlavne o to, či MongoDB zvládne uložiť náš objem master dat a či dokáže z daného množstva dát v rozumnom čase vrátiť dokumenty podľa primárneho kľúča. Prikladám pár referencií:

Kto používa MongoDB ? EA Sports - databáza rozdelená cez viac ako 250 serverov image

Baidu - ukladá viac než 200 miliárd dokumentov (u nás by išlo cca o 100 miliónov dokumentov(reprezentujúce OCR stránky) + nejaké ďalšie reprezentujúce objekty vyššie v hierarchii, užívateľské zbierky, viacero verzií OCR stránok, a pod...) image

National Archives - https://www.archives.gov/ - Jedna z najvätších svetových archívov uchovávajúcich záznamy viac než 1000 rokov staré, až po moderné vládne dokumenty image

Ďalšie veľké spoločnosti, ktoré využívajú MongoDB, sú napr. Toyota, SEGA, ThermoFisher, Royal Bank of Scotland, eBay, Google, Adobe, AstraZeneca, cisco, ...

Metadátový strom možno nebude najlepšie riešenie, no aj napriek tomu by som preferoval využitie MongoDB, kde by sme do jedného dokumentu(stránky) mohli na jedno miesto uložiť všetky metadáta vzťahujúce sa k tokenom tohto dokumentu, pri dotazovaní by sme dostali všetky tokeny a metadáta, ktoré spolu patria, s väčšou flexibilitou do budúcna, keďže dokumenty v MongoDB sú schemaless. Mám za to, že nevyužijeme výhody, ktoré ponúka HBase, a skôr by sme sa zbytočne limitovali v budúcom rozvoji. Objem dát by pre MongoDB nemal byť problém. Iteratívne doplňovanie dát a metadát tiež nerobí problém,

bodnarIQ commented 3 years ago
  1. Indexy

Myslím, že tu sme už dosť jednoznačne rozhodnutí ísť cestou SOLRu. Čo sa týka schémy indexu, máme dve možnosti:

  1. Indexovať pomocou custom PreAnalyzedFieldu - každé metadata by malo vlastný field, do ktorého by sa posielal pôvodný textový field z OCR a zaindexovala by sa vždu hodnota daného metadátového atribútu. Výhodou by bola jednoduchosť a rýchlosť, interne by to vyzeralo nejak takto: image (Hodnota v store je iba pre znázornenie vstupu do SOLRu, fieldy by mali atribút stored=false aby sme zbytočne neukladali x-krát ten istý string) Nevýhodou by bolo, že by sa nedali vyhľadávať zadaním viacerých podmienok pre rovnaký token(napr. nájsť všetky dokumenty, kde lemma=šachovnice && feats contains Gender=Fem). Toto je za mňa dosť veľké obmedzenie, preto odporúčam druhú možnosť
  2. Indexovať každý token ako vnorený dokument - každý token by bol indexovaný samostatne ako vnorený dokument v dokumente reprezentujúcom OCR sken. Počet indexovaných dokumentov by síce rapídne stúpol, ale podporovali by sme komplexnejšie dotazovanie. Rýchlosť by pri dostatočnom rozložení shardov nemala by neuspokojivá. Indexované dokumenty by vyzerali takto: image

Dotazy môžeme samozrejme cacheovat. Pri vracaní výsledku dotazu máme dve možnosti

  1. Scheduler

Nenašiel som, že by SOLR mal nejaký spôsob predpovede časovej náročnosti dotazu, takže by sme to asi museli implementovať sami. Mohli by sme začať niečím jednoduchým, ako napr. vyvodzovať query execution time z počtu premenných v dotaze a veľkosti indexu, a postupne prejsť na zložitejšie, ale presnejšie riešenie, napr. nejaký štatistický model z predchádzajúcich dotazov, ktorý by vedel presnejšie predpovedať dĺžku vyhodnotenia dotazu. Podľa toho by sa potom rozhodovalo, či sa daný dotaz spustí hneď, dá do fronty dotazov alebo odmietne úplne.

Navrh: Vyuzit pri implementaci schedulera taky moznosti RDF pozitivniho Apache Thrift frameworku

Scheduler bude interný modul v K+ komunikujúci iba s ostatnými modulmi K+ pri príchodzích dotazoch, kde by bolo využitie Apache Thrift frameworku?

  1. Endpointy

Keďže báza nebude grafová, nie som si istý, či bude SPARQL možné implementovať. Existujú nástroje, ktoré umožňujú vykonávať SPARQL dotazy nad MongoDB, no pre takéto riešenie bude nutná hlbšia analýza(aké výhody by nám to prinieslo vs pracnosť). Apache Spark - 👍 obecnejsi REST API s nadefinovanymi CRUD operacemi - 👍

bukovskyIQ commented 3 years ago

Zdravíme @JanMeritus, prosíme o vyjádření k výše zmíněným poznatkům, abychom si mohli schválit doporučené rozhodnutí databáze.

stranak commented 3 years ago

Nevýhodou by bolo, že by sa nedali vyhľadávať zadaním viacerých podmienok pre rovnaký token(napr. nájsť všetky dokumenty, kde lemma=šachovnice && feats contains Gender=Fem). Toto je za mňa dosť veľké obmedzenie, preto odporúčam druhú možnosť

Už na samém začátku projektu jsme mluvili o tom, že by asi nemělo být cílem vytvořit (kromě mnoha jiných věcí) náhradu korpusového manažeru. Viz např. https://www.korpus.cz/kontext/view?maincorp=syn2020&viewmode=kwic&pagesize=400&attrs=word&attr_vmode=visible-kwic&base_viewattr=word&refs=%3Ddoc.title&q=~DMcksyWIk2mC

https://lindat.mff.cuni.cz/services//teitok/pdtc//index.php?action=cqp&cql=%5Blemma+%3D+%22šachovnice%22%5D++within+text

Spíš než zkoušet vymyslet obdobný nástroj by mi přišlo výhodné promyslet, jak data efektivně do existujícího nástroje exportovat a složitější hledání v textu takto delegovat. Ať už by se korpusový manažer provozoval v knihovně, nebo někde, kde jej již provozují (FI MU Brno, UČNK FF UK, UFAL MFF UK, ...)

Tedy podle mě je třeba dobře promyslet, co stojí za to implementovat.

JanMeritus commented 3 years ago

@bukovskyIQ nie som si isty ci sa v skratke da k vsetkemu tu prezentovanemu vyjadrit

Segmenty:

bodnarIQ commented 3 years ago

K pripomienkam, že sa nemáme snažiť implementovať korpusový manžér - pod týmto pojmom som si predstavoval systém, ktorý slúži najmä pre nejaké zobrazovanie obsahu, z wiki:

A corpus manager (corpus browser or corpus query system) is a tool for multilingual corpus analysis, which allows effective searching in corpora. A corpus manager usually represents a complex tool that allows one to perform searches for language forms or sequences. It may provide information about the context or allow the user to search by positional attributes, such as lemma, tag, etc. These are called concordances. Other features include the ability to search for Collocations, frequency statistics as well as metadata information about the processed text.

Zo zadávačky K+:

Rozšiřující modul Kramerius+ bude sloužit pro uchování obohacených textových dat a metadat, které jsou uloženy v systému Kramerius, jedná se na např. o lemmatizaci a automaticky rozpoznané entity v plných textech, záznamy z knihovních systémů, odkazy na autority a bibliografické záznamy, apod.). Tyto údaje se využijí pro kvalitnější vyhledávání digitálních dokumentů, k filtraci jejich obsahu a umožní obsah Krameria vědecky zpracovávat, případně exportovat pro další použití.

V Krameriu+ budou uložena metadata rozšiřující dosavadní popis dokumentů (v Krameriu) o informace podstatné pro pokročilé dotazy a obsahové vyhledávání v dokumentech. Zvolená technologie musí umožnit efektivní prohledávání těchto obohacených dat

Korpusové manažéry ponúkajú efektívne vyhľadávanie v korpusoch, od K+ ale tiež chceme, aby ponúkal efektivní prohledávání těchto obohacených dat. Z tohto mi prišla filtrácia stránok podľa obsahu (podľa výstupov z nástrojov UdPipe a NameTag) ako výhodná možnosť, no je to zároveň funkcionalita, ktorú ponúkajú práve spomínané korpusové manažéry. Čo teda máme/nemáme indexovať? Stále sa bavíme iba o indexovaných hodnotách, ktoré nemajú dopad na to, ako budeme obohatené dáta ukladať. Možnosť filtrovať na základe fieldov získaných z výstupov UdPipe a NameTag môže byť za mňa užitočné pre získanie užšej sady dát, nad ktorým potom badateľ môže robiť ďalšie manipulácie u seba, v nejakom vlastnom korpusovom manažéri. Máme teda obmedziť indexáciu dát, ktoré sa dajú vyhľadať importovaním do korpusového manažéra?

treba pocitat ze bude dochadzat k zvysovaniu kvality OCR textov, pripadne priebeznemu doplnovaniu zbierok, pripadne zmenam modelu - zakladna baza by s tym nemala mat nikdy problem - a mala by byt relativne blizko zdrojovym datam a zaroven umoznovat ich rychlou transformaci pro datastruktury ktore projekt umoznuje poskytovat na vystupe

Toto budeme riešiť verzovaním dokumentov uložených v K+. V K+ bude ukladaný dokument reprezentovať konkrétny OCR sken pre danú stránku:

... Zároveň najmenšou jednotkou, s ktorou budeme v systéme pracovať, je stránka(nejaké vyjadrenie stránky - tým myslím výstup skenu OCR obohatený o metadáta získané z nástrojov UdPipe a NameTag) ...

To znamená, že v prípade že dôjde k novému OCR skenu s vyššou kvalitou, vznikne v DB nový dokument, ktorý bude treba opäť obohatiť o metadáta. Zároveň sa nastaví nejaký flag pre starú verziu OCR v DB, ktorý bude vyjadrovať, či ide o najnovšiu verziu OCR skenu. Čo sa myslí pod zmenou modelu? Pri zmene modelu bude pravdepodobne nutná programátorská práca na backende, aby sa nový obsah DB v starom modeli transformoval na nový model, a aby backend dokázal s novým modelom pracovať, no zo strany DB to nebude problém, pretože MongoDB nezaujíma, v akom modele sa ukladá obsah.

stranak commented 3 years ago

K tomu jak silné vyhledávání a srovnání s korpusovými manažery bych řekl zcela svůj subjektivní názor (podle mě jsme to společně neřešili): Korpusové manažery jsou hlavně o tom vyhledávání a pak filtrování výsledků. Akorát v nich tradičně nejde o dokumenty, ale jen ty výskyty. (Tím se mezi nimi liší TEITOK, kde o ty dokumenty jde.) Typický korpusový manažer tradičně ani dokument neumí zobrazit, ukáže jen řádek s výskytem. Pokud si myslíte, že není problém implementovat hledání nad tokeny a jejich atributy asi tak v síle, rychlosti a relativně efektivní syntaxi typického dotazovacího jazyka korpusového manažeru, já vlastně nic nenamítám. Jen jsem si myslel, že je to zbytečná práce ve srovnání s tím, takový hotový systém raději integrovat. Hlavně kdyby měla být síla obdobná, ale syntax výrazně jiná než de-facto standard v oboru, měl bych to za trošku kontraproduktivní.

Když tak se na některý systém podívejte. Třeba zde je tutorial k nástroji Kontext v ČNK. Klíčových je těch prvních 7 lekcí, ty další popisují funkcionalitu pro nás irrelevantní. Podle mě stojí za zvážení, co z toho implementovat, nebo zda by naopak šlo hotový nástroj využít, pokud opravdu chceme sofistikované vyhledávání přes všemožné atributy dokumentů a zároveň i tokenů. Pak asi nutně budeme chtít i říci, že slova jsou nějak daleko od sebe, nebo ve stejné větě, atd., matchují nějaké regexy, no a máme to, co dělá ten jazyk CQL.

Nějak mi celkově přijde, že takto sofistikovaný vyhledávač v textu je už vymyšlený a zároveň není snadné udělat a udržovat obdobný. Doporučuji zkonzultovat v UČNK nabo v Lexical Computing Ltd. Na obou pracovištích na to mají vice než 1 FTE. Ale možná jsem prostě jen moc skeptický.

bukovskyIQ commented 3 years ago

Část tohoto issue byla již rozhodnuta - Báze dat bude - MongoDB Na zbylé části se kolega @bodnarIQ vyjádří, neboť to souvisí s novým issue LIBCAS/DL4DH#15