ProHoster > BLOG > știri pe internet > Ce se întâmplă acum cu depozitele RDF?

Ce se întâmplă acum cu depozitele RDF?

Web-ul semantic și datele legate sunt ca spațiul cosmic: acolo nu există viață. Să merg acolo pentru un termen mai mult sau mai puțin lung... Nu știu ce ți-au spus când erai copil ca răspuns la „Vreau să devin astronaut”. Dar poți urmări ce se întâmplă pe Pământ; a deveni un astronom amator sau chiar un profesionist este mult mai ușor.

Articolul se va concentra pe tendințe proaspete, nu mai vechi de câteva luni, din lumea stocării RDF. Metafora din primul paragraf este inspirată de o imagine promoțională epică sub tăietură.


tablou epic

Ce se întâmplă acum cu depozitele RDF?

I. GraphQL pentru acces RDF

Ei spuncă GraphQL pretinde a fi limbajul universal de acces la baza de date. Și cum rămâne cu capacitatea de a accesa folosind GraphQL la RDF?

Din cutie, această oportunitate este oferită de:

Dacă depozitul nu oferă o astfel de oportunitate, acesta este implementat independent prin scrierea „resolverului” (resolver) corespunzător. Acest lucru s-a făcut, de exemplu, în proiectul francez DataTurism. Sau puteți deja să scrieți nimic, ci doar să luați HyperGraphQL.

Din punctul de vedere al unui adept ortodox al Web-ului Semantic și al Datelor Linked, toate acestea sunt, desigur, triste, din moment ce par destinate integrărilor construite în jurul următorului siloz de date, și platformelor nu potrivite (desigur, stocări RDF) .

Impresiile din compararea GraphQL cu SPARQL sunt duble.

  • Pe de o parte, GraphQL arată ca o rudă îndepărtată a lui SPARQL: rezolvă problemele de reselecție și de interogări multiple care sunt tipice pentru REST - fără de care, probabil, nu ar fi posibil să se ia în considerare limbajul de interogare, cel putin pentru web;
  • Pe de altă parte, schema rigidă a GraphQL supără. În consecință, „introspectivitatea” sa pare a fi foarte limitată în comparație cu reflexivitatea deplină a RDF. Și nu există un analog al căilor de proprietate, așa că nici măcar nu este foarte clar de ce este „Graph-”.

II. Adaptoare pentru MongoDB

Un trend complementar celui precedent.

  • La Stardog acum este posibil - în special, toate pe același GraphQL - configurați afișarea datelor MongoDB în grafice RDF virtuale;
  • Ontotext GraphDB recent Acesta permite inserați în fragmente SPARQL pe MongoDB Query.

Vorbind mai pe larg, despre adaptoarele la surse JSON care permit mai mult sau mai puțin „din mers” să reprezinte JSON stocat în aceste surse ca RDF, atunci îl putem aminti și pe cel existent de ceva timp SPARQL Generarecare poate fi reglat de exemplu, lui Apache Jena.

Rezumând primele două tendințe, putem spune că depozitele RDF demonstrează o pregătire totală pentru integrare și funcționare în condiții de „stocare multiplă” (persistență poliglotă). Se știe, totuși, că acesta din urmă a fost demult demodat, și să-l înlocuiască venire multi-modelare. Și cum rămâne cu multi-modelingul în lumea stocării RDF?

Pe scurt, în niciun caz. Aș dori să dedic un articol separat subiectului DBMS cu mai multe modele, dar deocamdată puteți vedea că nu există DBMS cu mai multe modele „bazate” pe modelul grafic (RDF poate fi considerat o variație a acestuia). Despre câteva mici modelări multiple - suportul de către depozitele RDF a unui model alternativ de grafic GPL - vor fi discutate în Secțiunea V.

III. OLTP vs. OLAP

Totuși, același Gartner el scriecă multi-modeling este o condiție sine qua non în primul rând pentru săli de operație SGBD. Acest lucru este de înțeles: într-o situație de „stocare multiplă”, principalele probleme apar cu tranzacționalitatea.

Dar unde sunt depozitele RDF pe scara OLTP-OLAP? Aș răspunde așa: nici acolo, nici aici. Pentru a indica pentru ce sunt destinate, este nevoie de o a treia abreviere. Ca opțiune aș sugera OLIP — Procesare intelectuală online.

Cu toate acestea, încă:

  • mecanismele de integrare implementate în GraphDB cu MongoDB nu sunt cele mai puțin importante destinat pentru a rezolva problemele de performanță de scriere;
  • Stardog merge chiar mai departe și complet rescrie motor, din nou cu scopul de a îmbunătăți performanța de scriere.

Și acum permiteți-mi să vă prezint un nou jucător pe piață. De la creatorii IBM Netezza și Amazon Redshift - AnzoGraph™. O poză dintr-o reclamă pentru un produs bazat pe acesta a fost plasată la începutul articolului. AnzoGraph se poziționează ca o soluție GOLAP. Cum vă place SPARQL cu funcții de fereastră? —

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

IV. RocksDB

Deja mai sus era un link la anunțul Stardog 7 Beta, care spunea că Stardog va folosi RocksDB ca sistem de stocare de bază - stocare cheie-valoare, bifurcația Facebook a LevelDB de la Google. De ce merită să vorbim despre o anumită tendință?

În primul rând, judecând după articol Wikipedia, nu numai depozitele RDF sunt „transplantate” în RocksDB. Există proiecte de utilizare a RocksDB ca motor de stocare în ArangoDB, MongoDB, MySQL și MariaDB, Cassandra.

În al doilea rând, proiectele (adică nu produsele) subiectului corespunzător sunt realizate pe RocksDB.

De exemplu, eBay folosește RocksDB în platformă pentru „graficul dumneavoastră de cunoștințe”. Apropo, e amuzant să citești: limbajul de interogare a început ca un format de acasă, dar mai recent a trecut în tranziție pentru a fi mult mai asemănător SPARQL. Ca într-o glumă: indiferent cât de mult grafic de cunoaștere am face, tot obținem RDF.

Un alt exemplu - apărut acum câteva luni Serviciul de interogare a istoricului Wikidata. Înainte de introducerea sa, informațiile istorice ale Wikidata trebuiau accesate prin intermediul MWAPI la API-ul Mediawiki standard. Multe sunt acum posibile în SPARQL pur. „Sub capotă” există și RocksDB. Apropo, WDHQS a făcut-o, se pare că persoana implicată în importul Freebase în Google Knowledge Graph.

V. Suport GPL

Permiteți-mi să vă reamintesc principala diferență dintre graficele GPL și graficele RDF.

În LPG, proprietățile scalare pot fi atașate instanțelor de margine, în timp ce în RDF pot fi atașate doar „tipurilor” de margine (dar nu numai proprietăți scalare, ci și legături obișnuite). Această limitare a RDF în comparație cu GPL a depasi un fel de tehnică de modelare. Limitările GPL în comparație cu RDF sunt mai greu de depășit, dar graficele GPL sunt mai mult ca imagini din manualul lui Harari decât grafice RDF, așa că oamenii le doresc.

Evident, sarcina de „sprijinire a GPL” se împarte în două părți:

  1. efectuarea de modificări la modelul RDF care să facă posibilă simularea construcțiilor GPL în acesta;
  2. efectuarea de modificări la limbajul de interogare RDF care fac posibilă accesarea datelor în acest model modificat sau implementarea capacității de a interoga acest model în limbaje de interogare LPG populare.

V.1. Model de date

Există mai multe abordări posibile aici.

V.1.1. proprietate singleton

Cea mai literală abordare a armonizării RDF și GPL este probabil proprietate singleton:

  • În loc, de exemplu, de predicat :isMarriedTo sunt folosite predicate :isMarriedTo1, :isMarriedTo2 etc
  • Aceste predicate devin apoi subiecte ale unor noi triplete: :isMarriedTo1 :since "2013-09-13"^^xsd:date etc
  • Legătura acestor instanțe de predicate cu un predicat comun se stabilește prin tripleți de formă :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
  • Este evident că rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, dar gândiți-vă de ce nu ar trebui să scrieți :isMarriedTo1 rdf:type :isMarriedTo.

Sarcina de „suport GPL” este rezolvată aici la nivel RDFS. O astfel de decizie necesită includerea în documentul relevant стандарт. Unele modificări pot fi necesare din depozitele RDF care acceptă atașarea consecințelor, dar pentru moment, proprietatea Singleton poate fi considerată doar o altă tehnică de modelare.

V.1.2. Reificarea făcută corect

Abordările mai puțin naive provin din conștientizarea faptului că instanțele de proprietate sunt perfect instanțiate de tripleți. Putem vorbi despre tripleți, putem vorbi și despre instanțe de proprietate.

Cea mai solidă dintre aceste abordări este RDF*alias RDR, născut în măruntaiele lui Blazegraph. Este de la început ales pentru mine și AnzoGraph. Soliditatea demersului este determinată de faptul că în cadrul acesteia a oferit modificările corespunzătoare în Semantică RDF. Ideea, însă, este extrem de simplă. În serializarea RDF Turtle, acum puteți scrie ceva de genul acesta:

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

V.1.3. Alte abordări

Nu vă puteți deranja cu semantica formală, ci pur și simplu luați în considerare că tripleții au niște identificatori, care, desigur, sunt URI-uri și compun noi tripleți cu aceste URI-uri. Tot ce rămâne este să acordați acces la aceste URI-uri în SPARQL. Asa de ajunge câine stelat.

În Allegrograph a mers într-un mod intermediar. Se știe că identificatorii tripleților din Allegrograph există, dar când sunt implementate atribute triple, acestea nu ies în evidență. Cu toate acestea, chiar și semantica formală este foarte departe. În special, atributele triplet nu sunt URI-uri, iar valorile acestor atribute pot fi, de asemenea, doar literale. Adepții GPL obțin exact ceea ce și-au dorit. În formatul NQX special inventat, un exemplu similar cu cel de mai sus pentru RDF* arată astfel:

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

V.2. Limbi de interogare

Având suportat GPL într-un fel sau altul la nivel de model, trebuie să faceți posibilă interogarea datelor într-un astfel de model.

  • Blazegraph pentru interogări RDF* acceptă SPARQL* и Gremlin. O interogare SPARQL* arată astfel:

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

  • Anzograph suportă și el SPARQL* și urmează să sprijine Cypher, limbajul de interogare în Neo4j.
  • Stardog își menține propriul extensie SPARQL și din nou Gremlin. Puteți obține URI-ul unui triplet și „meta-informații” în SPARQL folosind ceva de genul acesta:

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

  • Allegrograph își susține, de asemenea, propriile sale extensie SPARQL:

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

De altfel, GraphDB a suportat Tinkerpop/Gremlin la un moment dat, fără a suporta LPG, dar asta s-a oprit în versiunea 8.0 sau 8.1.

VI. Înăsprirea licențelor

Nu au existat adăugări recente la intersecția dintre seturile „triplestore la alegere” și „triplestore open source”. Noile magazine RDF open source sunt departe de a fi o alegere bună pentru utilizarea de zi cu zi, iar codul sursă pentru noile magazine triple pe care aș dori să le folosesc (de exemplu, AnzoGraph) este închis. Mai degrabă, putem vorbi despre reduceri...

Desigur, anterior open source nu este închisă, dar unele depozite open source nu mai sunt treptat considerate demne de alegere. Virtuoso, care are o ediție open source, după părerea mea, se îneacă în bug-uri. Blazegraph cumpărat de AWS și a stat la baza Amazon Neptune; acum nu este clar dacă va mai exista cel puțin o lansare. Doar Jenna rămâne...

Dacă open source nu este foarte important, dar vrei doar să încerci, atunci totul este și mai puțin roz decât înainte. De exemplu:

  • Stardog se termină distribuiți versiunea gratuită (cu toate acestea, perioada de probă a celei obișnuite s-a dublat);
  • в GraphDB Cloud, unde ai putea alege anterior planul de bază gratuit, înregistrarea noilor utilizatori este suspendată.

În general, spațiul devine din ce în ce mai inaccesibil pentru un informator obișnuit, dezvoltarea lui devine lotul corporațiilor.

Sursa: www.habr.com

Adauga un comentariu