Úvod

Na https://wiki.duraspace.org/display/FEDORA35/Resource+Index je popsáno, co je to Fedora resource index (dále RI). Tento článek popisuje průzkum a zkoušení jiných možností implementací RI než jsou existující standardní implementace Mulgara nebo MPTStore s Postgresem, které jsou v současné době jako jediné dvě podporované a udržované vývojáři Fedory. Tento průzkum probíhá v rámci projektu Kramerius, a to přibližně od poloviny roku 2012.

Na http://code.google.com/p/kramerius/wiki/fedora jsou popsány zátěžové testy Fedory, které byly prováděny v rámci projektu Kramerius; v závěrech jsou uvedeny kromě jiného následující body:

• Výchozí implementace resource indexu Mulgara je pro uložení více než 100 000 objektů nepoužitelná.
• Alternativní implementace resource indexu MPTstore je funkční, ale podporuje pouze omezenou podmnožinu dotazovacího jazyka iTQL, neumožňuje například složené dotazy, které jsou použity v jedné ze záložek adminstrátorského rozhraní pro indexaci dokumentů K4.
• Index MPT store je při daném objemu dat vysoce náročný na optimalizaci použité databáze PostreSQL (500M uložených RDF tripletů zabírá cca 1.3TB diskového prostoru), pro dosažení potřebné výkonnosti indexu je třeba průběžná údržba databáze kvalifikovaným administrátorem (aktualizace indexů, statistik, čištění nepoužívaných segmentů atd.).

Z těchto testů a i z jiných informací jinde na internetu v rámci jiných projektů, z nichž některé budou zmíněny dále, vyplývají důvody pro průzkum a zkoušení jiných možností implementací RI než jsou dvě výše uvedené standardní implementace. Cílem tedy je používat v projektu Kramerius vhodnější implementaci RI než jsou dvě výše zmíněné možnosti, pokud se ukáže, že je to možné.

Trippi

Nejdříve bylo potřeba zjistit a vyzkoušet, zda lze Fedoru přesměrovat na jinou implementaci RI, než jsou dvě výše zmíněné implementace s Mulgarou nebo MPTStore s Postgresem. To se ukázalo dle dokumentace Fedory a informací na internetu, že to lze. Základem pro napojení Fedory na RI je implementace Trippi (http://trippi.sourceforge.net). Trippi je Java knihovna, která se používá ve Fedoře jako rozhraní pro komunikaci s úložištěm použitým pro implementaci RI.

Trippi poskytuje abstraktní třídy a rozhraní, jejichž naimplementováním pro konkrétní úložiště je možno použít dané úložiště pro implementaci RI. Základní abstraktní třídou je zde třída TriplestoreConnector, jejíž konkrétní implementace (plný název příslušné implementující třídy) se uvádí v konfiguraci Fedory, pokud chceme nějakým vlastním způsobem implementovat RI Fedory.

Trippi obsahuje také konkrétní implementace těchto abstraktních tříd a rozhraní – v současnosti právě pro výše zmiňované Mulgaru a MPTStore. Co se týká ostatních implementací Trippi (pro Sesame, Kowari a Oracle Spatial) vyjmenovaných v dokumentaci k Trippi na výše uvedeném odkazu, tak po bližším prozkoumání dalších informací různě na internetu se ukázalo, že dokumentace k Trippi se již delší dobu neudržuje a že z implementace pro Kowari se stala současná implementace pro Mulgaru; implementace pro Sesame a Oracle Spatial byly vývojáři Trippi již před delší dobou opuštěny a v současných verzích Trippi se již delší dobu nevyskytují.

Po dalším hledání a zkoumání se ukázalo, že lidé různě na internetu sice hledají možnosti jiných implementací RI, ale nic dostupného, co by bylo možno v tomto směru použít, se nepodařilo nalézt. Přistoupilo se tedy k hledání vhodného úložiště pro implementaci RI, pro které by se následně naprogramovala příslušná Trippi implementace po vzoru zdrojových kódů existujících současných implementací pro Mulgaru a MPTStore a případně také podle zdrojových kódů dřívějších již neudržovaných implementací pro Sesame a Oracle Spatial.

Úložiště pro resource index

Bylo tedy potřeba najít vhodné dostatečně výkonné úložiště, pro které by bylo možno naprogramovat vlastní implementaci Trippi pro komunikaci s tímto úložištěm. Prvním vhodným kandidátem bylo úložiště 4store, pro které kromě obecných parametrů a informací z internetu hovořilo hlavně to, že jsou na internetu informace (http://journals.tdl.org/jodi/article/view/5396/5885), že je úspěšně používají v Alexandrijské knihovně v Egyptě, kde obdobně hledali vhodné RI úložiště pro použití s Fedorou. Ale při dalším hledání a porovnávání se přece jen došlo k závěru pokusit se použít pro implementaci RI jako úložiště systém Virtuoso (jeho volně dostupnou variantu „Virtuoso Open-Source Edition“ (http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/) – viz první bod níže), pro nějž hovoří řada skutečností – kromě jiného následující:

• Existuje jednak jeho volně dostupná varianta i jeho komerční placená varianta, kde také volně dostupná varianta se zdá být v porovnání s jinými systémy velmi dobrá a dostatečně výkonná a existence komerční varianty je určitou zárukou jistoty.
• I v úvodním přehledu, co se kde používá, sepsaném v dokumentu k systému v Alexandrijské knihovně (viz internetový odkaz výše) je uvedeno, že někde považují použití Virtuoso jako úložiště pro RDF data za nejméně riskantní přístup: „The SPAR project (SPAR Project, 2011) at the BNF considers storing the Metadata using RDF in the Virtuoso triple store (Virtuoso Universal Server software, 2011) the least risky approach (Fauduet and Peyrard, 2010) while still accepting a SIP with a METS manifest.“
• Na http://www.biomedcentral.com/1471-2105/13/S1/S3 porovnávali pět nekomerčních úložišť („Virtuoso Open-Source Edition“, Jena SDB, Jena TDB, SwiftOWLIM a 4store) a kromě jiného se zde píše: „We identified three groups of queries displaying similar behaviour across the different stores: 1) relatively short response time queries, 2) moderate response time queries and 3) relatively long response time queries. SwiftOWLIM proved to be a winner in the first group, 4Store in the second one and Virtuoso in the third one.“ … „Our analysis showed that some queries behaved idiosyncratically, in a triple store specific manner, mainly with SwiftOWLIM and 4Store. Virtuoso, as expected, displayed a very balanced performance – its load time and its response time for all the tested queries were better than average among the selected stores; it showed a very good scalability and a reasonable run-to-run reproducibility. Jena SDB and Jena TDB were consistently slower than the other three implementations. Our analysis demonstrated that most queries developed for Virtuoso could be successfully used for other implementations.“
• Virtuoso je možno provozovat na operačních systémech Linux i Windows. Například 4store zatím ve variantě pro Windows není.
• I tento asi už poněkud starší přehled ohledně ukládání RDF dat dokládá velmi dobrou pozici Virtuosa: http://www.w3.org/wiki/LargeTripleStores