Wat bart der no mei RDF-opslach?

It semantysk web en keppele gegevens binne as de bûtenromte: d'r is gjin libben dêr. Om dêr foar in min of mear lange tiid hinne te gean ... Ik wit net wat se jo as bern sein hawwe yn antwurd op "Ik wol astronaut wurde." Mar jo kinne observearje wat der bart wylst op ierde; It is folle makliker om in amateur astronoom te wurden of sels in profesjonele.

It artikel sil rjochtsje op resinte, net âlder dan ferskate moannen, trends út 'e wrâld fan RDF-opslach. De metafoar yn 'e earste paragraaf is ynspirearre troch it epyske grutte reklameôfbylding ûnder de besuniging.


Epyske foto

Wat bart der no mei RDF-opslach?

I. GraphQL foar RDF tagong

Se sizzedat GraphQL fan doel is in universele databanktagongstaal te wurden. Hoe sit it mei de mooglikheid om tagong te krijen ta RDF mei GraphQL?

Ut it fak wurdt dizze kâns fersoarge troch:

As it repository sa'n kâns net biedt, kin it selsstannich ymplementearre wurde troch it skriuwen fan in passende "resolver". Dat diene se bygelyks yn it Frânske projekt DataToerisme. Of jo kinne neat mear skriuwe, mar gewoan nimme HyperGraphQL.

Ut it eachpunt fan in ortodokse oanhinger fan it semantysk web en keppele gegevens, dit alles is fansels spitich, om't it liket ûntworpen foar yntegraasjes boud om 'e folgjende gegevenssilo, en net geskikte platfoarms (RDF-winkels, fansels) .

De yndrukken fan it fergelykjen fan GraphQL mei SPARQL binne twafoldich.

  • Oan 'e iene kant sjocht GraphQL as in fiere relative fan SPARQL: it lost de problemen op fan resampling en mearfâldichheid fan fragen dy't typysk binne foar REST - sûnder dat it wierskynlik net mooglik wêze soe om te beskôgjen query taal, alteast foar it web;
  • Oan 'e oare kant is it rigide skema fan GraphQL teloarstellend. Dêrtroch liket syn "yntrospektyfens" heul beheind yn ferliking mei de folsleine reflexiviteit fan RDF. En der is gjin analoog fan eigendom paden, dus it is net iens hiel dúdlik wêrom't it is "Graph-".

II. Adapters foar MongoDB

In trend oanfolling op de foarige.

  • No yn Stardog mooglik - benammen allegear op deselde GraphQL - konfigurearje de mapping fan MongoDB-gegevens yn firtuele RDF-grafiken;
  • Ontotext GraphDB hat koartlyn stiet ta fragminten ynfoegje yn SPARQL op MongoDB Query.

As wy breder prate oer adapters nei JSON-boarnen, dy't mear of minder "on the fly" tastean om de JSON opslein yn dizze boarnen as RDF te fertsjintwurdigjen, kinne wy ​​​​de nochal langsteande SPARQL generearje, dy't oanpast wurde kin, bygelyks, oan Apache Jena.

De earste twa trends gearfetsje, kinne wy ​​​​sizze dat RDF-opslach folsleine reewilligens foar yntegraasje en eksploitaasje yn betingsten fan "polyglot-persistinsje" bewize. It is bekend, lykwols, dat dit lêste is al lang út 'e moade, en wurdt ferfongen troch komt multi-model. Hoe sit it mei multi-modellering yn 'e wrâld fan RDF-opslach?

Koartsein, gjin manier. Ik wol graach in apart artikel wije oan it ûnderwerp fan multi-model DBMS's, mar foar no kin opmurken wurde dat d'r op it stuit gjin multi-model DBMS's binne "basearre" op in grafykmodel (RDF kin wurde beskôge as in soarte fan it) . Guon lytse multi-modellering - RDF-opslachstipe foar in alternatyf LPG-grafykmodel - sil wurde besprutsen yn seksje V.

III. OLTP vs. OLAP

Lykwols, deselde Gartner hy skriuwtdat multimodel is in sine qua non betingst foaral foar operaasje keamers DBMS. Dit is begryplik: yn in situaasje fan "multivariate opslach" ûntsteane de wichtichste problemen mei transaksjonaliteit.

Mar wêr lizze RDF-opslach op 'e OLTP-OLAP-skaal? Ik soe sa antwurdzje: noch dêr noch hjir. Om oan te jaan wêr't se foar bedoeld binne, is in tredde ôfkoarting nedich. As opsje soe ik foarstelle OLIP - Online yntellektuele ferwurking.

Dochs noch:

  • de yntegraasjemeganismen mei MongoDB ymplementearre yn GraphDB binne net it minste bedoeld om te wurkjen om problemen mei skriuwen fan prestaasjes;
  • Stardog giet noch fierder en folslein herskriuwt motor, wer mei it doel fan ferbetterjen opname prestaasjes.

Lit my no in nije spiler oan 'e merk yntrodusearje. Fan 'e makkers fan IBM Netezza en Amazon Redshift - AnzoGraph™. In foto fan in advertinsje foar in produkt basearre op it waard pleatst oan it begjin fan it artikel. AnzoGraph positionearret himsels as in GOLAP-oplossing. Hoe hâlde jo fan SPARQL mei finsterfunksjes? -

SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE {  …  }

IV. RocksDB

Al heger der wie in keppeling oan 'e oankundiging fan Stardog 7 Beta, dy't sei dat Stardog RocksDB soe brûke as in ûnderlizzende opslachsysteem - in winkel foar kaaiwearden, in Facebook-gabel fan Google's LevelDB. Wêrom is it wurdich te praten oer in bepaalde trend?

As earste, beoardielje troch Wikipedia artikel, Net allinich RDF-opslach wurde "transplantearre" nei RocksDB. D'r binne projekten om RocksDB te brûken as opslachmotor yn ArangoDB, MongoDB, MySQL en MariaDB, Cassandra.

Twads wurde projekten (dat is gjin produkten) oer relevante ûnderwerpen makke op RocksDB.

Bygelyks, eBay brûkt RocksDB yn platfoarm foar jo "kennisgrafyk". Trouwens, it is grappich om te lêzen: de query-taal begon as in eigen groeid formaat, mar koartlyn is it oergien om folle mear te wêzen as SPARQL. Lykas yn 'e grap: hoefolle kennisgrafyk wy ek meitsje, wy einigje noch mei RDF.

In oar foarbyld - ien dy't in pear moannen lyn ferskynde Wikidata Skiednis Query Service. Foar de yntroduksje moast Wikidata histoaryske ynformaasje fia tagong wurde MWAPI nei de standert Mediawiki API. No is in protte mooglik mei suver SPARQL. "Under de motorkap" is d'r ek RocksDB. Trouwens, WDHQS waard makke, liket it, troch de persoan dy't Freebase ymportearre yn 'e Google Knowledge Graph.

V. LPG stipe

Lit my jo herinnerje oan it wichtichste ferskil tusken LPG-grafiken en RDF-grafiken.

Yn LPG kinne skalêre eigenskippen wurde tawiisd oan râneeksimplaren, wylst se yn RDF allinich kinne wurde tawiisd oan râne "typen" (mar net allinich skalêre eigenskippen, mar ek gewoane ferbiningen). Dizze beheining fan RDF yn ferliking mei LPG oerwinne ien of oare modeling technyk. De beheiningen fan LPG yn ferliking mei RDF binne dreger te oerwinnen, mar LPG-grafiken binne mear as foto's út in Harari-learboek dan RDF-grafiken, en dêrom wolle minsken se.

Fansels falt de taak fan "LPG-stipe" yn twa dielen:

  1. feroarings oanmeitsje oan it RDF-model dy't it mooglik meitsje om LPG-struktueren dêryn te simulearjen;
  2. feroarings oanmeitsje oan de RDF-fraachtaal dy't it mooglik meitsje om tagong te krijen ta gegevens yn dit wizige model, of it útfieren fan de mooglikheid om fragen te meitsjen nei dit model yn populêre LPG-fraachtalen.

V.1. Data Model

D'r binne hjir ferskate mooglike oanpak.

V.1.1. Singleton Property

De meast letterlike oanpak foar it harmonisearjen fan RDF en LPG is wierskynlik singleton eigendom:

  • Yn stee fan bygelyks it predikaat :isMarriedTo predikaten wurde brûkt :isMarriedTo1, :isMarriedTo2 en sa fierder.
  • Dizze predikaten wurde dan de ûnderwerpen fan nije trijelingen: :isMarriedTo1 :since "2013-09-13"^^xsd:date en oaren.
  • De ferbining fan dizze eksimplaren fan predikaten mei in mienskiplik predikaat wurdt fêststeld troch trijelingen fan 'e foarm :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
  • Fansels, rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, mar tink oer wêrom't jo net gewoan skriuwe moatte :isMarriedTo1 rdf:type :isMarriedTo.

It probleem fan "LPG-stipe" wurdt hjir op it RDFS-nivo oplost. Sa'n beslút fereasket opname yn it passend standert. Guon wizigingen kinne ferplicht wurde foar RDF-winkels dy't taheakjen fan gefolgen stypje, mar foar no kin Singleton Property wurde tocht as gewoan in oare modeltechnyk.

V.1.2. Reifikaasje dien rjochts

Minder naïve oanpakken komme út it besef dat eigendomseksimplaren folslein ynstantibel binne troch trijelingen. Troch wat te sizzen oer trijelingen, sille wy prate kinne oer eigendomseksimplaren.

De meast robúste fan dizze oanpak is RDF*, aka RDR, berne yn 'e djipten fan Blazegraph. It is fan it begjin ôf keazen foar dysels en AnzoGraph. De soliditeit fan 'e oanpak wurdt bepaald troch it feit dat binnen har ramt oanbean korrespondearjende feroarings yn RDF Semantyk. It punt is lykwols ekstreem ienfâldich. Yn Turtle serialisaasje fan RDF kinne jo no soksawat skriuwe:

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

V.1.3. Oare oanpak

Jo kinne net lestich falle mei formele semantyk, mar gewoan oannimme dat triplets hawwe bepaalde identifiers, dy't, fansels, URIs, en meitsje nije triplets mei dizze URI. Alles wat oerbliuwt is tagong te jaan ta dizze URI's yn SPARQL. Sa komt Stardog.

In Allegrograph gie op in tuskenlizzende wize. It is bekend dat triplet identifiers yn Allegrograph is, mar by it útfieren fan triple attributen stekke se net út. It is lykwols noch heul fier fan formele semantyk. It is opmerklik dat triplet-attributen gjin URI's binne, en de wearden fan dizze attributen kinne ek allinich letterlik wêze. LPG-oanhingers krije krekt wat se woenen. Yn it spesjaal útfûne NQX-formaat sjocht in foarbyld gelyk oan dat hjirboppe foar RDF* der sa út:

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

V.2. Query talen

Nei't jo LPG op ien of oare manier op modelnivo stipe hawwe, moatte jo it mooglik meitsje om fragen te meitsjen oer gegevens yn sa'n model.

  • Blazegraph foar RDF * queries stipet SPARQL* и Gremlin. In SPARQL*-query sjocht der sa út:

 SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }

  • Anzograph stipet ek SPARQL* en sil stypje Cypher, in fraachtaal yn Neo4j.
  • Stardog stipet har eigen fergrutting SPARQL en wer Gremlin. Jo kinne de triplet URI en "meta-ynformaasje" krije yn SPARQL mei soksawat as dit:

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

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

Trouwens, GraphDB op ien kear stipe Tinkerpop / Gremlin sûnder stipe LPG, mar dit stoppe yn ferzje 8.0 of 8.1.

VI. Oanskerping fan lisinsjes

D'r binne gjin resinte tafoegings west oan 'e krusing fan' e "triplestore of choice" en "open source triplestore" sets. De nije iepen boarne RDF-winkels binne in lange wei fan in goede kar foar deistich gebrûk, en de nije triple winkels dy't ik graach wolle brûke (lykas AnzoGraph) binne sletten boarne. Earder kinne wy ​​​​prate oer ferminderingen ...

Fansels is iepen boarne yn it ferline net ôfsletten, mar guon iepen boarne repositories wurde stadichoan net mear sjoen as it wurdich te kiezen. Virtuoso, dy't in iepenboarne-edysje hat, fersûpt neffens my yn bugs. Blazegraph waard kocht troch AWS en foarme de basis fan Amazon Neptunus; no is it ûndúdlik oft der op syn minst noch ien frijlitting komt. Allinnich Jena bliuwt ...

As iepen boarne net heul wichtich is, mar jo wolle it gewoan besykje, dan is alles ek minder rooskleurich as earder. Bygelyks:

  • Stardog stoppet distribuearje de fergese ferzje (de proefperioade fan 'e reguliere ferzje is lykwols ferdûbele);
  • в GraphDB Cloud, wêr't jo earder in fergees basisplan koene kieze, binne nije brûkersregistraasjes ophâlden.

Yn 't algemien, foar de gemiddelde IT-persoan, wurdt romte mear en mear ûnberikber; syn ûntwikkeling wurdt it lot fan bedriuwen.

Boarne: www.habr.com

Add a comment