La Semantika Reto kaj Ligitaj Datumoj estas kiel proksima kosmo: tie ne estas vivo. Iri tien por pli-malpli longa tempodaŭro… nu, mi ne scias, kion oni diris al vi kiel infano responde al “Mi volas esti astronaŭto.” Sed vi povas observi kio okazas sur la Tero; estas multe pli facile fariĝi amatoro aŭ eĉ profesia astronomo.
La artikolo diskutos freŝajn, ne pli malnovajn ol kelkajn monatojn, tendencojn el la mondo de RDF-stokado. La metaforo en la unua alineo estis inspirita de eposa reklama bildo sub la eltondaĵo.
Epopea bildo
I. GraphQL por RDF-aliro
ke GraphQL celas fariĝi universala datumbaza alirlingvo. Kio pri la kapablo aliri RDF per GraphQL?
El la skatolo ĉi tiu ŝanco estas provizita de:
- Starhundo (, );
- TopQuadrant-produktoj (, ).
Se la deponejo ne disponigas tian ŝancon, ĝi povas esti efektivigita sendepende skribante taŭgan "solvilon". Jen kion ili faris, ekzemple, en la franca projekto . Aŭ vi ne plu povas skribi ion, sed nur preni .
El la vidpunkto de ortodoksa adepto de la Semantika Reto kaj Ligitaj Datumoj, ĉio ĉi, kompreneble, estas malĝoja, ĉar ĝi ŝajnas desegnita por integriĝoj konstruitaj ĉirkaŭ la sekva datumsilo, kaj ne taŭgaj platformoj (RDF-butikoj, kompreneble) .
La impresoj de komparo de GraphQL kun SPARQL estas duoblaj.
- Unuflanke, GraphQL aspektas kiel malproksima parenco de SPARQL: ĝi solvas la problemojn de resampling kaj multeco de demandoj, kiuj estas tipaj por REST - sen kiuj, verŝajne, ne eblus konsideri. demanda lingvo, almenaŭ por la reto;
- Aliflanke, la rigida skemo de GraphQL estas seniluziiga. Sekve, ĝia "introspektiveco" ŝajnas tre limigita kompare kun la plena refleksiveco de RDF. Kaj ne ekzistas analogo de posedaĵvojoj, do eĉ ne estas tre klare kial ĝi estas "Grafo-".
II. Adaptiloj por MongoDB
Tendenco komplementa al la antaŭa.
- nun en Stardog - precipe, ĉio sur la sama GraphQL - agordu la mapadon de MongoDB-datumoj en virtualajn RDF-grafikojn;
- GraphDB ĵus enigu fragmentojn en SPARQL ĉe MongoDB Query.
Se ni parolas pli vaste pri adaptiloj al JSON-fontoj, kiuj permesas pli-malpli "sur la flugo" reprezenti la JSON konservitan en ĉi tiuj fontoj kiel RDF, ni povas rememori la sufiĉe longdaŭran , kiu povas esti ĝustigita, , al Apache Jena.
Resumante la unuajn du tendencojn, ni povas diri, ke RDF-stokado montras plenan pretecon por integriĝo kaj funkciado en kondiĉoj de "poliglota persisto". Oni tamen scias, ke ĉi tiu lasta longe malmodiĝis, kaj estas anstataŭata de multmodelo. Kio pri multmodelado en la mondo de RDF-stokado?
Resume, neniel. Mi ŝatus dediĉi apartan artikolon al la temo de plurmodelaj DBMS-oj, sed nuntempe oni povas rimarki, ke nuntempe ne ekzistas plurmodelaj DBMS-oj "bazitaj" sur grafika modelo (RDF povas esti konsiderata kiel speco de ĝi) . Iu malgranda plurmodelado - RDF-stoka subteno por alternativa LPG-grafa modelo - estos diskutita en .
III. OLTP vs. OLAP
Tamen, la sama Gartner tiu multmodelo estas sine qua non kondiĉo ĉefe por operaciejoj DBMS. Ĉi tio estas komprenebla: en situacio de "multvaria stokado", la ĉefaj problemoj ŝprucas kun transakcio.
Sed kie troviĝas RDF-stokoj sur la OLTP-OLAP-skalo? Mi respondus jene: nek tie nek ĉi tie. Por indiki al kio ili celas, necesas ia tria mallongigo. Kiel eblon mi sugestus OLIP — Enreta Intelekta Prilaborado.
Tamen, ankoraŭ:
- la integriĝmekanismoj kun MongoDB efektivigitaj en GraphDB estas ne malplej labori ĉirkaŭ verki agado-temojn;
- Starhundo iras eĉ pli for kaj tute motoro, denove kun la celo plibonigi registran efikecon.
Nun permesu al mi prezenti novan ludanton en la merkato. De la kreintoj de IBM Netezza kaj Amazon Redshift — . Bildo de reklamo por produkto bazita sur ĝi estis afiŝita komence de la artikolo. AnzoGraph poziciigas sin kiel GOLAP-solvo. Kiel vi ŝatas SPARQL kun fenestrofunkcioj? —
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }IV. RocksDB
Jam pli alta al la anonco de Stardog 7 Beta, kiu diris ke Stardog uzos RocksDB kiel subesta stokadsistemo - ŝlosil-valora vendejo, Facebook-forko de LevelDB de Guglo. Kial valoras paroli pri certa tendenco?
Unue, juĝante laŭ , ne nur RDF-stokoj estas "transplantitaj" al RocksDB. Estas projektoj por uzi RocksDB kiel stokan motoron en ArangoDB, MongoDB, MySQL kaj MariaDB, Cassandra.
Due, projektoj (tio estas, ne produktoj) pri koncernaj temoj estas kreitaj sur RocksDB.
Ekzemple, eBay uzas RocksDB en por via "scio-grafiko". Cetere, estas amuze legi: la demandlingvo komenciĝis kiel hejma formato, sed pli lastatempe ĝi transiris por esti multe pli kiel SPARQL. Kiel en la ŝerco: kiom ajn da scigrafio ni faras, ni ankoraŭ finiĝas kun RDF.
Alia ekzemplo - kiu aperis antaŭ kelkaj monatoj . Antaŭ ĝia enkonduko, Vikidatumaj historiaj informoj devis esti aliritaj trae al la norma Mediawiki API. Nun multe eblas per pura SPARQL. "Sub la kapuĉo" estas ankaŭ RocksDB. Cetere, WDHQS estis farita, ŝajnas, de la persono kiu importis Freebase en la Google Knowledge Graph.
V. LPG-subteno
Mi memorigu vin pri la ĉefa diferenco inter LPG-grafikoj kaj RDF-grafikoj.
En LPG, skalaraj trajtoj povas esti asignitaj al randkazoj, dum en RDF ili povas esti asignitaj nur al randaj "specoj" (sed ne nur skalaraj trajtoj, sed ankaŭ ordinaraj ligoj). Ĉi tiu limigo de RDF kompare kun LPG unu aŭ alia modela tekniko. La limigoj de LPG kompare kun RDF estas pli malfacile supereblaj, sed LPG-grafoj pli similas bildojn el Harari-lernolibro ol RDF-grafikaĵoj, tial homoj volas ilin.
Evidente, la tasko de "LPG-subteno" falas en du partojn:
- farante ŝanĝojn al la RDF-modelo, kiuj ebligas simuli LPG-strukturojn en ĝi;
- farante ŝanĝojn al la RDF demandlingvo kiuj ebligas aliri datumojn en ĉi tiu modifita modelo, aŭ efektivigante la kapablon fari demandojn al ĉi tiu modelo en popularaj LPG demandlingvoj.
V.1. Datuma modelo
Estas pluraj eblaj aliroj ĉi tie.
V.1.1. Singleton-posedaĵo
La plej laŭvorta aliro al harmoniigado de RDF kaj LPG verŝajne estas :
- Anstataŭ, ekzemple, la predikativo
:isMarriedTopredikatoj estas uzataj:isMarriedTo1,:isMarriedTo2mi t. d. - Tiuj predikatoj tiam iĝas la subjektoj de novaj trinasktioj:
:isMarriedTo1 :since "2013-09-13"^^xsd:datekaj aliaj. - La ligo de ĉi tiuj okazoj de predikatoj kun komuna predikato estas establita per triopoj de la formo
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo. - Estas evidente ke
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, sed pensu pri kial vi ne simple skribu:isMarriedTo1 rdf:type :isMarriedTo.
La problemo de "LPG-subteno" estas solvita ĉi tie ĉe la RDFS-nivelo. Tia decido postulas inkludon en la taŭga . Kelkaj ŝanĝoj povas esti postulataj por RDF-butikoj kiuj subtenas alligi konsekvencojn, sed nuntempe, Singleton Property povas esti opiniita kiel nur alia modeliga tekniko.
V.1.2. Reigo Farita Ĝuste
Malpli naivaj aliroj devenas de la ekkompreno ke posedaĵkazoj estas plene instantiigeblaj per trinasktioj. Povante ion diri pri trinasktioj, ni povos paroli pri posedaĵoj.
La plej fortika el ĉi tiuj aliroj estas , alinome RDR, en la profundo de Blazegraph. Ĝi estas de la komenco mem por vi mem kaj AnzoGraph. La solideco de la aliro estas determinita de la fakto, ke en sia kadro respondaj ŝanĝoj en . La punkto, tamen, estas ege simpla. En Testuda seriigo de RDF vi nun povas skribi ion tian:
<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .V.1.3. Aliaj aliroj
Vi ne povas ĝeni kun formala semantiko, sed simple supozi, ke trinasktioj havas certajn identigilojn, kiuj estas, kompreneble, URI-oj, kaj kreas novajn trinasktiojn kun ĉi tiuj URI-oj. Restas nur doni aliron al ĉi tiuj URI-oj en SPARQL. Do Starhundo.
En Alegrografo en meza maniero. Estas konata ke triopaj identigiloj en Allegrograph , sed dum efektivigado de trioblaj atributoj ili ne elstaras. Tamen, ĝi estas ankoraŭ tre malproksime de formala semantiko. Estas rimarkinde, ke triopaj atributoj ne estas URIoj, kaj la valoroj de ĉi tiuj atributoj ankaŭ povas esti nur laŭvortaj. LPG-anoj ricevas ĝuste tion, kion ili volis. En la speciale elpensita NQX-formato, ekzemplo simila al tiu ĉi supre por RDF* aspektas jene:
:bob :marriedTo :alice {"since" : "2013-09-13"}V.2. Demandlingvoj
Subteninte LPG iel aŭ alian sur la modelnivelo, vi devas ebligi fari demandojn pri datumoj en tia modelo.
- Blazegraph por RDF*-demandoj subtenas и . Demando SPARQL* aspektas jene:
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }- Anzografo ankaŭ subtenas kaj tuj subtenos , demandolingvo en Neo4j.
- Stardog subtenas sian propran SPARQL kaj Gremlino. Vi povas akiri la triopan URI kaj "meta-informojn" en SPARQL uzante ion tian:
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}- Allegrograph ankaŭ subtenas sian propran SPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }Cetere, GraphDB siatempe subtenis Tinkerpop/Gremlin sen subteni LPG, sed ĉi tio ĉesis en versio 8.0 aŭ 8.1.
VI. Streĉigo de licencoj
Lastatempe ne okazis aldonoj al la intersekciĝo de la aroj "triobla vendejo laŭ elekto" kaj "malfermfonta triobla vendejo". Novaj malfermfontaj RDF-vendejoj estas malproksimaj de esti bona elekto por ĉiutaga uzo, kaj la fontkodo de novaj RDF-vendejoj, kiujn ni ŝatus uzi (la sama AnzoGraph), estas fermita. Prefere, ni eĉ povas paroli pri subtrahoj...
Kompreneble, malfermfonteco ne estis fermita en la pasinteco, sed iuj malfermfontaj deponejoj iom post iom ne plu estas konsiderataj elekteblaj. Virtuoso, kiu havas malfermfontan eldonon, miaopinie dronas en cimoj. Blazegraph estis aĉetita fare de AWS kaj formis la bazon de Amazon Neptune; nun estas neklare ĉu estos almenaŭ unu plia eldono. Nur Jena restas...
Se malferma fonto ne estas tre grava, sed vi volas nur provi ĝin, tiam ĉio ankaŭ estas malpli rozkolora ol antaŭe. Ekzemple:
- Starhundo distribui la senpagan version (tamen la provperiodo de la regula versio duobliĝis);
- в , kie antaŭe oni povis elekti senpagan bazan planon, suspendis la registriĝon de novaj uzantoj.
Ĝenerale, por la averaĝa IT-ulo, spaco fariĝas pli kaj pli nealirebla; ĝia evoluo fariĝas la amaso de korporacioj.
fonto: www.habr.com
