La web semàntica i les dades enllaçades són com l'espai exterior: no hi ha vida. Per anar-hi durant un període de temps més o menys llarg... bé, no sé què et deien de petit com a resposta a "Vull ser astronauta". Però podeu observar què està passant mentre esteu a la Terra; És molt més fàcil convertir-se en un astrònom aficionat o fins i tot un professional.
L'article se centrarà en les tendències recents, no superiors a uns quants mesos, del món de l'emmagatzematge RDF. La metàfora del primer paràgraf es va inspirar en la imatge publicitària de mida èpica sota el tall.
Imatge èpica
I. GraphQL per a l'accés RDF
que GraphQL pretén convertir-se en un llenguatge d'accés universal a la base de dades. Què passa amb la possibilitat d'accedir a RDF mitjançant GraphQL?
Fora de la caixa, aquesta oportunitat la proporciona:
- Stardog (, );
- Productes TopQuadrant (, ).
Si el repositori no ofereix aquesta oportunitat, es pot implementar de manera independent escrivint un "resoludor" adequat. Això és el que van fer, per exemple, en el projecte francès . O ja no pots escriure res, sinó prendre .
Des del punt de vista d'un ortodox adepte de la web semàntica i les dades enllaçades, tot això, és clar, és trist, ja que sembla pensat per a integracions construïdes al voltant de la següent sitja de dades, i plataformes no adequades (botigues RDF, és clar) .
Les impressions de comparar GraphQL amb SPARQL són dobles.
- D'una banda, GraphQL sembla un parent llunyà de SPARQL: resol els problemes de remuestreig i multiplicitat de consultes típics de REST -sense els quals, probablement, no seria possible considerar. llenguatge de consulta, almenys per a la web;
- D'altra banda, l'esquema rígid de GraphQL és decebedor. En conseqüència, la seva "introspectivitat" sembla molt limitada en comparació amb la reflexivitat completa de RDF. I no hi ha cap anàleg de camins de propietat, així que ni tan sols està molt clar per què és "Graph-".
II. Adaptadors per a MongoDB
Una tendència complementària a l'anterior.
- a Stardog ara - en particular, tot al mateix GraphQL - configureu el mapeig de dades de MongoDB en gràfics RDF virtuals;
- GraphDB ha fet recentment inseriu fragments a SPARQL a MongoDB Query.
Si parlem de manera més àmplia dels adaptadors a fonts JSON, que permeten representar més o menys "sobre la marxa" el JSON emmagatzemat en aquestes fonts com a RDF, podem recordar l'antiga , que es pot ajustar, , a Apache Jena.
Resumint les dues primeres tendències, podem dir que els emmagatzematges RDF demostren una preparació total per a la integració i el funcionament en condicions de "persistència políglota". Se sap, però, que aquest últim fa temps que està passat de moda i està sent substituït per multimodel. Què passa amb el modelatge múltiple al món de l'emmagatzematge RDF?
En resum, de cap manera. M'agradaria dedicar un article a part al tema dels SGBD multimodel, però de moment es pot assenyalar que actualment no hi ha SGBD multimodel "basats" en un model de gràfics (el RDF es pot considerar un tipus d'aquest). . A continuació es parlarà d'alguns petits modelatges múltiples: suport d'emmagatzematge RDF per a un model de gràfic GLP alternatiu .
III. OLTP vs. OLAP
No obstant això, el mateix Gartner aquest multimodel és una condició sine qua non principalment per quiròfans DBMS. Això és comprensible: en una situació d'"emmagatzematge multivariat", els principals problemes sorgeixen amb la transaccionalitat.
Però, on es troben els emmagatzematges RDF a l'escala OLTP-OLAP? Jo respondria així: ni allà ni aquí. Per indicar a què estan pensats, cal una tercera abreviatura. Com a opció recomanaria OLIP — Tractament intel·lectual en línia.
Tanmateix, encara:
- els mecanismes d'integració amb MongoDB implementats a GraphDB no són menys importants per solucionar problemes de rendiment d'escriptura;
- Stardog va encara més enllà i completament motor, de nou amb l'objectiu de millorar el rendiment de la gravació.
Ara permeteu-me presentar un nou jugador al mercat. dels creadors d'IBM Netezza i Amazon Redshift - . Al principi de l'article es va publicar una imatge d'un anunci d'un producte basat en ell. AnzoGraph es posiciona com una solució GOLAP. Com us agrada SPARQL amb funcions de finestra? —
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }IV. RocksDB
Ja més alt a l'anunci de Stardog 7 Beta, que deia que Stardog utilitzaria RocksDB com a sistema d'emmagatzematge subjacent: una botiga de valor-clau, una bifurcació de Facebook de LevelDB de Google. Per què val la pena parlar d'una tendència determinada?
En primer lloc, a jutjar per , no només els emmagatzematges RDF es "trasplanten" a RocksDB. Hi ha projectes per utilitzar RocksDB com a motor d'emmagatzematge a ArangoDB, MongoDB, MySQL i MariaDB, Cassandra.
En segon lloc, es creen projectes (és a dir, no productes) sobre temes rellevants a RocksDB.
Per exemple, eBay utilitza RocksDB a per al vostre "gràfic de coneixement". Per cert, fa gràcia llegir: el llenguatge de consulta va començar com un format casolà, però més recentment ha estat la transició per ser molt més semblant a SPARQL. Com a la broma: per molt gràfic de coneixement que fem, encara acabem amb RDF.
Un altre exemple, un que va aparèixer fa uns mesos . Abans de la seva introducció, s'havia d'accedir a la informació històrica de Wikidata a l'API estàndard de Mediawiki. Ara molt és possible amb SPARQL pur. "Sota el capó" també hi ha RocksDB. Per cert, WDHQS el va fer, sembla, la persona que va importar Freebase al Google Knowledge Graph.
V. Suport de GLP
Permeteu-me que us recordi la diferència principal entre els gràfics GLP i els gràfics RDF.
A LPG, les propietats escalars es poden assignar a instàncies de vora, mentre que a RDF només es poden assignar a "tipus" de vora (però no només propietats escalars, sinó també connexions ordinàries). Aquesta limitació de RDF en comparació amb el GLP una o altra tècnica de modelatge. Les limitacions del GLP en comparació amb el RDF són més difícils de superar, però els gràfics de GLP s'assemblen més a imatges d'un llibre de text Harari que no pas a gràfics RDF, per això la gent els vol.
Òbviament, la tasca de "suport al GLP" es divideix en dues parts:
- fer canvis al model RDF que permetin simular-hi estructures de GLP;
- fer canvis al llenguatge de consulta RDF que permetin accedir a les dades en aquest model modificat, o implementar la possibilitat de fer consultes a aquest model en llenguatges de consulta populars de LPG.
V.1. Model de dades
Aquí hi ha diversos enfocaments possibles.
V.1.1. Propietat Singleton
L'enfocament més literal per harmonitzar RDF i GLP és probablement :
- En lloc, per exemple, del predicat
:isMarriedTos'utilitzen predicats:isMarriedTo1,:isMarriedTo2i així successivament. - Aquests predicats esdevenen llavors els subjectes de nous triplets:
:isMarriedTo1 :since "2013-09-13"^^xsd:dateetcètera - La connexió d'aquestes instàncies de predicats amb un predicat comú s'estableix mitjançant triplets de la forma
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo. - És obvi que
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, però pensa per què no has d'escriure:isMarriedTo1 rdf:type :isMarriedTo.
El problema del "suport de GLP" es resol aquí a nivell RDFS. Aquesta decisió requereix la inclusió en el corresponent . És possible que es requereixin alguns canvis per a les botigues RDF que admeten conseqüències adjuntes, però de moment, Singleton Property es pot considerar com una altra tècnica de modelatge.
V.1.2. Coificació feta correctament
Els enfocaments menys ingenus es deriven de la consciència que les instàncies de propietat són totalment instanciables per triplets. Si podem dir alguna cosa sobre els triplets, podrem parlar de casos de propietat.
El més robust d'aquests enfocaments és , també conegut com RDR, a les profunditats de Blazegraph. És des del principi per a tu i AnzoGraph. La solidesa de l'enfocament ve determinada pel fet que en el seu marc canvis corresponents en . El punt, però, és extremadament senzill. A la serialització de Turtle de RDF ara podeu escriure alguna cosa com això:
<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .V.1.3. Altres enfocaments
No us podeu molestar amb la semàntica formal, sinó simplement suposar que els triplets tenen determinats identificadors, que són, per descomptat, URIs, i creeu nous triplets amb aquests URI. Només queda donar accés a aquests URI a SPARQL. Tan Stardog.
En al·legrògraf d'una manera intermèdia. Se sap que els identificadors de triplets en Allegrograph , però en implementar atributs triples no sobresurten. Tanmateix, encara està molt lluny de la semàntica formal. Cal destacar que els atributs triplets no són URI, i els valors d'aquests atributs també només poden ser literals. Els adherents a GLP aconsegueixen exactament el que volien. En el format NQX especialment inventat, un exemple semblant a l'anterior per a RDF* té aquest aspecte:
:bob :marriedTo :alice {"since" : "2013-09-13"}V.2. Idiomes de consulta
Després d'haver donat suport al GLP d'una manera o altra a nivell de model, cal que permeti fer consultes sobre dades en aquest model.
- Admet Blazegraph per a consultes RDF* и . Una consulta SPARQL* té aquest aspecte:
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }- Anzograph també dóna suport i donarà suport , un llenguatge de consulta a Neo4j.
- Stardog admet el seu SPARQL i Gremlin. Podeu obtenir l'URI triplet i la "metainformació" a SPARQL fent servir alguna cosa com això:
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}- Allegrograph també admet el seu SPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }Per cert, GraphDB en un moment va donar suport a Tinkerpop/Gremlin sense donar suport a LPG, però això es va aturar a la versió 8.0 o 8.1.
VI. Enduriment de llicències
No hi ha hagut cap addició recent a la intersecció dels conjunts "triplestore d'elecció" i "triplestore de codi obert". Les noves botigues RDF de codi obert estan molt lluny de ser una bona opció per a l'ús diari, i les noves botigues RDF que m'agradaria utilitzar (com AnzoGraph) són de codi tancat. Més aviat, fins i tot podem parlar de disminucions...
Per descomptat, el codi obert no s'ha tancat en el passat, però alguns dipòsits de codi obert ja no es veuen que val la pena triar. Virtuoso, que té una edició de codi obert, s'està ofegant, al meu entendre, en errors. Blazegraph va ser comprat per AWS i va formar la base d'Amazon Neptune; ara no està clar si hi haurà almenys un llançament més. Només queda Jena...
Si el codi obert no és molt important, però només voleu provar-ho, aleshores tot és també menys bo que abans. Per exemple:
- Stardog distribuir la versió gratuïta (no obstant això, el període de prova de la versió normal s'ha duplicat);
- в , on abans es podia triar un pla bàsic gratuït, ha suspès els registres de nous usuaris.
En general, per a la persona informàtica mitjana, l'espai és cada cop més inaccessible; el seu desenvolupament s'està convertint en el lot de les corporacions.
Font: www.habr.com
