Mis toimub praegu RDF-lao projektidega?

Semantiline veeb ja lingitud andmed on nagu lähikosmos: seal elamiseks ei ole. Et sinna minna pikemaks ajaks... noh, ma ei tea, mida teile lapsepõlves öeldi vastuseks «tahan astronautiks saada». Kuid toimuva jälgimine on võimalik ka Maalt; astronoomiks saamine on palju lihtsam, olgu siis harrastajatena või isegi professionaalidena.

Käesolevas artiklis käsitletakse värskeid, mitte vanemaid kui paar kuud, trende RDF-andmebaasidest. Esimese lõigu metafoor tuli ideaalsest suurusest reklaampildist allpool.

Epic pilt

I. GraphQL RDF-i juurde pääsemiseks

Räägitakse, et GraphQL pürgib olema universaalne andmebaaside juurdepääsu keel. Kuidas on aga lood GraphQL-i juurdepääsuga RDF-ile?

«Kastist väljaspool» pakuvad seda võimalust:

• Stardog (blogi, dokumentatsioon);
• TopQuadranti tooted (veebinar, dokumentatsioon).

Kui andmebaas ei paku sellist võimalust, siis rakendatakse seda iseseisvalt, kirjutades vastava «tuvastaja» (resolver). Nii tehti näiteks Prantsuse projektis DataTourisme. Või võib-olla ei ole midagi kirjutada, vaid lihtsalt kasutada HyperGraphQL.

Ortodoxse semantilise veeb ja lingitud andmete pooldaja seisukohalt on see muidugi kurb, kuna see tundub olevat mõeldud integratsioonide jaoks, mis on üles ehitatud veel ühe andme silosse, mitte plaatvormide jaoks (loomulikult RDF-andmebaaside jaoks).

Kokkuvõttes jääb GraphQL-i ja SPARQL-i võrdlemise mulje kahetiseks.

• Ühelt poolt näeb GraphQL välja nagu kauge sugulane SPARQL-ile: see lahendab REST-is esinevad toimetamisprobleemid ja mitmekesised päringud — ilma milleta ei saaks ilmselt rääkida päringute keelest, olgu see kasvõi veebis;
• Teiselt poolt muretses GraphQL-i range skeemilisus. Seega tundub selle «introspektiivsus» olevat võrreldes RDF-i täieliku reflektiivsusega väga piiratud. Ja puudub mingi analoog property paths, mistõttu ei ole isegi selge, miks seda nimetatakse «Graph-».

II. Adapterid MongoDB-le

Trend, mis täiendab eelmist.

• Stardogis on nüüd võib-olla — eelkõige kõik samal GraphQL-il — seadistada MongoDB andmete kuvamine virtuaalsetes RDF-graafikutes;
• GraphDB on hiljuti kaugelt sulgeda vahekaarte, mis on avatud teistel seadmetel. kohanenud SPARQL-i fragmentidega MongoDB Query-sse.

Rääkides laiemalt, adapteritest JSON-allikatele, mis võimaldavad enam-vähem «live» esitada nendes allikates hoitavat JSON-i kui RDF-i, võib mainida ka üsna pikka aega olemas olnud SPARQL Generate, mida saab liita, näiteks, Apache Jena.

Kokkuvõttes võib öelda, et RDF-andmehoidlad näitavad täielikku valmisolekut integreerimiseks ja toimimiseks „mitme variandi salvestamise” (polyglot persistence) tingimustes. On teada, et see viimane pole enam moes ja selle asemele tuleb multimudel. Aga kuidas on lood multimudeliga RDF-andmehoidlate maailmas?

Lühidalt öeldes, mitte kuigi hästi. Multimudelite andmebaaside teema väärib eraldi artiklit, kuid praegu võib märkida, et multimudeelset andmebaasi, mis põhineks graafimudelil (mida võib pidada ka RDF-ks), hetkel ei ole. Väikesest multimudelsusest – alternatiivsete graafimudelite LPG toetamisest RDF-andmehoidlate poolt – räägitakse peatükis V.

III. OLTP vs. OLAP

Siiski, sama Gartner kirjutab, et multimudelisus on tingimus sine qua non eelkõige operatiivsete andmebaaside jaoks. See on arusaadav: „mitme variandi salvestamise” olukorras on peamised probleemid seotud transaktsioonilisusega.

Aga kus asuvad RDF-andmehoidlad OLTP—OLAP skaalal? Vastaksin nii: ei seal, ega siin. Nende kavandatule viitamiseks on vajalik mingi kolmas akronüüm. Alternatiivina pakuksin OLIP — Online Intellektuaalne Protsessimine.

Kuid siiski:

• GraphDB-s rakendatud MongoDB integreerimismehhanismid on suunatud peamiselt kirjutamisjõudluse probleemide ringi kõrvaldamiseks; Stardog läheb veelgi kaugemale ja kirjutab
• mootori täielikult ümber, taaskord eesmärgiga parandada kirjutamisjõudlust. Nüüd lubage mul tutvustada uut mängijat turul. IBM Netezza ja Amazon Redshift looja poolt — AnzoGraph

. Toote reklaamis olev pilt saadi artikli alguses. AnzoGraph positsioneerib end kui GOLAP lahendusena. Kuidas kõlab SPARQL aknafunktsioonidega? — SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }IV. RocksDB

Ülalpool on juba

mainitud viidet

Stardog 7 Beta teadetele, kus räägiti, et Stardog plaanib kasutada RocksDB-d alumise salvestussüsteemina — võtme-väärtuse salvestus, Facebooki hargne LevelDB-st. Miks võiks rääkida mingist trendist? Esiteks, Wikipedias ütleb, et RocksDB-le „istuvad” mitte ainult RDF-andmehoidlad. On projekte, mis kasutavad RocksDB-d salvestusajamiks ArangoDB, MongoDB, MySQL ja MariaDB, Cassandra.

Teiseks, RocksDB-l tehakse teemasid (st mitte tooteid) vastava temaatika projekti. Wikipedia artikkel, RocksDB-le «istutatakse» mitte ainult RDF-ladu. On projekte, kus kasutatakse RocksDB-d salvestusmootorina ArangoDB-s, MongoDB-s, MySQL-is ja MariaDB-s, Cassandra-s.

Teiseks, RocksDB-l tehakse vastava temaatikaga projekte (st mitte tooteid).

Näiteks kasutab eBay RocksDB-d platvormis oma "teadmiste graafiku" jaoks. Muide, on naljakas lugeda: the query language started as a home grown format, but more recently it has been transitioning to be much more like SPARQL. Nagu anekdoodis: kui palju tahes teadmiste graafikust teha, tuleb ikka välja RDF.

Teine näide on mõned kuud tagasi ilmunud Wikidata History Query Service. Enne selle tulekut tuli ajalooliste Vikidata andmete saamiseks pöörduda MWAPI kaudu tavalise Mediawiki API poole. Nüüd on palju võimalik puhtal SPARQL-il. "Kapoti all" on seal samuti RocksDB. Ütlesin, et WDHQS-i lõi inimene, kes tegeles Freebase'i importimisega Google Knowledge Graph'i.

V. LPG toe

Tuletan meelde peamist erinevust LPG-graafikute ja RDF-graafikute vahel.

LPG-s võivad servade eksemplaridele olla lisatud skalaarsed omadused, samas kui RDF-s saavad neid lisada ainult servade "tüübid" (aga mitte ainult skalaarsed omadused, vaid ka tavalised seosed). See piiramine RDF-s võrreldes LPG-ga ületatakse erinevate modelleerimistehnikate abil. LPG-d piiravad omadused võrreldes RDF-ga on aga keerulisemad ületada, kuid LPG-graafikud on rohkem nagu Harari õpikust pildid, seetõttu soovivad inimesed neid.

On ilmne, et "LPG toe" ülesanne jaguneb kaheks osaks:

1. muudatuste sisseviimine RDF mudelisse, mis võimaldab simuleerida LPG-struktuure;
2. muudatuste tegemine RDF päringute keeles, et võimaldada andmete pärimist selles muudetud mudelis, — või rakendamine võimaluse osas teha päringuid sellele mudelile tuntud LPG päringute keeltes.

V.1. Andmemudel

Siin on mitu võimalikku lähenemist.

V.1.1. Singleton Property

Kõige sõnasõnaline lähenemine RDF ja LPG harmoneerimisele on tõenäoliselt singleton property:

• Näiteks kui kasutatakse predikaati :isMarriedTo kasutatakse predikaate :isMarriedTo1, :isMarriedTo2 jne.
• Seejärel saavad need predikaadid uute tripletide subjektideks: :isMarriedTo1 :since "2013-09-13"^^xsd:date ja nii edasi.
• Nende predikaatide eksemplaride seos üldise predikaadiga luuakse tripletidega, mis on kujul :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
• Ilmselgelt, et rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, kuid mõelge, miks ei tasu kirjutada lihtsalt :isMarriedTo1 rdf:type :isMarriedTo.

LPG toe ülesanne lahendatakse siin RDFS tasemel. Selline lahendus nõuab vastava standard. Mõned muudatused võivad olla vajalikud RDF-ladu jaoks, mis toetavad järjepidevuste liitmist, ja seni võib Singleton Propertyt vaadata lihtsalt kui veel ühte modelleerimise tehnikat.

V.1.2. Reifikatsioon õiges vormis

Vähem naiivsemate lähenemiste juured on arusaam, et omaduste eksemplarid on täiesti instantsitud triplettidega. Olles suuteline rääkima millestki tripletitest, saame rääkida ka omaduste eksemplaridest.

Kõige tõsisem lähenemine on RDF*, tuntud ka kui RDR, sündinud Blazegraphi sisemuses. Seda on algusest peale kasutanud ka AnzoGraph. Lähenemise tõsidust määrab see, et selle raames pakuvad on vastavad muudatused RDF semantikas.Kuid olemus on äärmiselt lihtne. RDF-i Turtle-sarjal on nüüd võimalik kirjutada umbes nii:

<> :since "2013-09-13"^^xsd:date .

V.1.3. Muud lähenemised

Ei ole mõtet vaeva näha formaalse semantikaga, vaid lihtsalt eeldada, et tripletitel on teatud identifikaatorid, mis on loomulikult URI-d, ja luua uusi triplette nende URI-dega. Peab vaid tagama nende URI-de juurdepääsu SPARQL-is. Nii tulnud Stardog.

Allegrograph läks vahepealse tee. On teada, et Allegrographi tripletite identifikaatorid on, kuid triple attributes'i rakendamisel nad välja ei paista. Siiski on enne formaalse semantika juurde jõudmine veel pikk tee. Sealjuures on huvitav, et tripletite attribuudid ei ole URI-d ja nende väärtused võivad olla vaid literatuurid. LPG propageerijad saavad täpselt seda, mida nad soovisid. Eraldi leiutatud formaadis NQX näeb näide, mis sarnaneb ülaltoodud näitele RDF* jaoks, välja järgmiselt:

:bob :marriedTo :alice {"since" : "2013-09-13"}

V.2. Küsimuste keeled

Toetades LPG-d mingil viisil mudeli tasandil, tuleb võimaldada andmestiku päringut sellises mudelis.

• Blazegraph toetab RDF* päringutes SPARQL* ja Gremlin.SPARQL* päring näeb välja nii:

 SELECT * { <> :since ?since }

• Anzograph toetab samuti SPARQL* ja plaanib toetada Cypher,päringukeelt Neo4j-s.
• Stardog toetab oma laiendamine SPARQL-i ja jällegi Gremlini. SPARQL-is URI tripleti ja "metaandmete" saamiseks saab kasutada järgmist konstruktsiooni:

SELECT * {
    BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
    ?id :since ?since
}

• Allegrograph toetab samuti oma laiendamine SPARQL-i:

 SELECT * { ("since" ?since)  franz:attributesNameValue  ( :bob :marriedTo ?wife ) }

Muide, GraphDB toetas mõnda aega Tinkerpop/Gremlini, toetamata seejuures LPG-d, kuid versioonis 8.0 või 8.1 lõpetati see.

VI. Tõhustatud litsentsid

Viimastel aegadel ei ole „valikuvõimaluste triplestore“ ja „avatud lähtekoodiga triplestore“ vahel mingeid juurdekasve toimunud. Uutel avatud lähtekoodiga RDF-hoidlatele ei ole tegelikult mingit võimalust igapäevaseks kasutamiseks, ja nende uute RDF-hoidlate lähtekood (nt AnzoGraph) on suletud. Pigem võib rääkida hoopis vähenemisest...

Muidugi, avatud lähtekood ei muutu kunagi suletuks, kuid mõned avatud lähtekoodiga hoidlad lakkuvad järk-järgult olema tõsised valikud. Virtuoso, mis pakub avatud lähtekoodiga versiooni, näib minu arvates olevat kahedesuguste probleemide all. Blazegraph on ostnud AWS ja see moodustab Amazon Neptune'i aluse; hetkel on raske öelda, kas veel üks väljaanne ilmub. Jäänud on vaid Jena...

Kui avatud lähtekood ei ole just väga oluline ja lihtsalt tahaks proovida, siis on olukord samuti vähem roosiline kui varem. Näiteks:

• Stardog lõpetab tasuta versiooni levitamise (üllatuseks on tavapärase katseperioodi aeg kahekordistunud);
• ja GraphDB Cloud, kus varem oli võimalik valida tasuta põhiplaan, on uute kasutajate registreerimine peatatud.

Üldiselt muutub tavalisele IT-kasutajale kosmos üha kätte saamatu, selle omandamine jääb vaid korporatsioonide pärusmaaks.

Allikas: habr.com