ProHoster > Blog > lajme në internet > Çfarë po ndodh me depot RDF tani?

Çfarë po ndodh me depot RDF tani?

Uebi semantik dhe të dhënat e lidhura janë si hapësira e jashtme: atje nuk ka jetë. Për të shkuar atje për një afat pak a shumë të gjatë… Nuk e di se çfarë ju thanë si fëmijë në përgjigje të “dua të bëhem astronaut”. Por ju mund të shikoni se çfarë po ndodh ndërsa jeni në Tokë; të bëhesh astronom amator apo edhe profesionist është shumë më e lehtë.

Artikulli do të fokusohet në tendencat e freskëta, jo më të vjetra se disa muaj, nga bota e ruajtjes së RDF. Metafora në paragrafin e parë është frymëzuar nga imazhi epik reklamues nën prerje.


foto epike

Çfarë po ndodh me depot RDF tani?

I. GraphQL për RDF Access

Ata thoneqë GraphQL pretendon të jetë gjuha universale e aksesit në bazën e të dhënave. Po në lidhje me aftësinë për të hyrë duke përdorur GraphQL në RDF?

Jashtë kutisë, kjo mundësi ofrohet nga:

Nëse depoja nuk ofron një mundësi të tillë, ajo zbatohet në mënyrë të pavarur duke shkruar "zgjidhësin" e duhur (zgjidhësin). Kjo u bë, për shembull, në projektin francez Turizmi i të Dhënave. Ose tashmë nuk mund të shkruani asgjë, por thjesht merrni HyperGraphQL.

Nga këndvështrimi i një ndjekësi ortodoks të Uebit Semantik dhe të Dhënave të Lidhura, e gjithë kjo është, natyrisht, e trishtueshme, pasi duket se synohet për integrime të ndërtuara rreth silosit të ardhshëm të të dhënave, dhe platforma jo të përshtatshme (sigurisht, ruajtje RDF) .

Përshtypjet nga krahasimi i GraphQL me SPARQL janë të dyfishta.

  • Nga njëra anë, GraphQL duket si një i afërm i largët i SPARQL: ai zgjidh problemet e rizgjedhjes dhe pyetjeve të shumta që janë karakteristike për REST - pa të cilat, me siguri, nuk do të ishte e mundur të merret në konsideratë gjuha e pyetjes, të paktën për ueb;
  • Nga ana tjetër, skema e ngurtë e GraphQL shqetëson. Prandaj, "introspektiviteti" i tij duket të jetë shumë i kufizuar në krahasim me refleksivitetin e plotë të RDF. Dhe nuk ka asnjë analog të shtigjeve të pronave, kështu që nuk është as shumë e qartë pse është "Graph-".

II. Përshtatës për MongoDB

Një tendencë plotësuese me atë të mëparshmen.

  • Në Stardog tani ndoshta - në veçanti, të gjitha në të njëjtin GraphQL - konfiguroni shfaqjen e të dhënave MongoDB në grafikë virtualë RDF;
  • Ontotext GraphDB kohët e fundit Kjo i lejon futni në fragmente SPARQL në MongoDB Query.

Duke folur më gjerësisht, për përshtatësit në burimet JSON që lejojnë pak a shumë "në fluturim" të përfaqësojnë JSON të ruajtur në këto burime si RDF, atëherë mund të kujtojmë edhe atë ekzistues për mjaft kohë. Krijo SPARQLtë cilat mund të rregullohen për shembull, te Apache Jena.

Duke përmbledhur dy tendencat e para, mund të themi se magazinat RDF demonstrojnë gatishmëri të plotë për integrim dhe funksionim në kushtet e "ruajtjes së shumëfishtë" (persistencë poliglote). Dihet, megjithatë, se kjo e fundit ka kohë që është jashtë mode, dhe për ta zëvendësuar atë duke ardhur multimodelimi. Po në lidhje me multimodelimin në botën e ruajtjes së RDF?

Me pak fjalë, në asnjë mënyrë. Unë do të doja t'i kushtoja një artikull të veçantë temës së DBMS me shumë modele, por tani për tani mund të shihni se nuk ka DBMS shumë-modele "të bazuara" në modelin e grafikut (RDF mund të konsiderohet një variant i tij). Disa modele të vogla të shumëfishta - mbështetje nga depozitat RDF të një modeli alternativ të grafikut LPG - do të diskutohen në Seksioni V.

III. OLTP vs. OLAP

Megjithatë, i njëjti Gartner shkruanse multi-modelimi është një kusht sine qua non kryesisht për dhomat e operacionit DBMS. Kjo është e kuptueshme: në një situatë të "ruajtjes së shumëfishtë", problemet kryesore lindin me transaksionalitetin.

Por ku në shkallën OLTP-OLAP janë depot RDF? Unë do të përgjigjesha kështu: as atje e as këtu. Për të treguar se për çfarë synohen, nevojitet një shkurtim i tretë. Si opsion do të sugjeroja OLIP — Përpunimi intelektual në internet.

Megjithatë, ende:

  • mekanizmat e integrimit të zbatuar në GraphDB me MongoDB nuk janë më pak synuar për të punuar rreth çështjeve të shkrimit të performancës;
  • Stardog shkon edhe më tej dhe plotësisht rishkruan motori, përsëri me synimin për të përmirësuar performancën e shkrimit.

Dhe tani më lejoni të prezantoj një lojtar të ri në treg. Nga krijuesit e IBM Netezza dhe Amazon Redshift - AnzoGraph™. Një foto nga një reklamë për një produkt të bazuar në të u vendos në fillim të artikullit. AnzoGraph pozicionohet si një zgjidhje GOLAP. Si ju pëlqen SPARQL me funksionet e dritares? -

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

IV. RocksDB

Më lart tashmë kishte një lidhje në njoftimin e Stardog 7 Beta, i cili thoshte se Stardog do të përdorte RocksDB si një sistem ruajtjeje bazë - ruajtja e vlerës së çelësit, forku i Facebook i LevelDB-së së Google. Pse ia vlen të flasim për një prirje të caktuar?

Së pari, duke gjykuar nga Artikull Wikipedia, jo vetëm depot RDF janë "transplantuar" në RocksDB. Ka projekte për të përdorur RocksDB si një motor ruajtjeje në ArangoDB, MongoDB, MySQL dhe MariaDB, Cassandra.

Së dyti, projektet (d.m.th., jo produktet) të lëndës përkatëse bëhen në RocksDB.

Për shembull, eBay përdor RocksDB në platformë për "grafin e njohurive" tuaj. Nga rruga, është qesharake të lexosh: gjuha e pyetjes filloi si një format i rritur në shtëpi, por kohët e fundit ajo ka qenë në tranzicion për të qenë shumë më tepër si SPARQL. Si në shaka: sado grafik njohurish të bëjmë, përsëri marrim RDF.

Një shembull tjetër - u shfaq disa muaj më parë Shërbimi i pyetjeve të historisë së Wikidata. Përpara prezantimit të tij, informacioni historik i Wikidata duhej të aksesohej përmes MWAPI në API standarde Mediawiki. Shumëçka tani është e mundur në SPARQL të pastër. "Nën kapuç" ka edhe RocksDB. Nga rruga, WDHQS e bëri atë, duket si personi i përfshirë në importimin e Freebase në Grafikun e Njohurive të Google.

V. Mbështetje LPG

Më lejoni t'ju kujtoj ndryshimin kryesor midis grafikëve LPG dhe grafikëve RDF.

Në LPG, vetitë skalare mund t'i bashkëngjiten instancave të skajeve, ndërsa në RDF ato mund të bashkohen vetëm me "llojet" e skajeve (por jo vetëm vetitë skalare, por edhe lidhjet e zakonshme). Ky kufizim i RDF në krahasim me LPG tejkaluar një lloj teknikë modelimi. Kufizimet e LPG-së në krahasim me RDF-në janë më të vështira për t'u kapërcyer, por grafikët e LPG-së janë më shumë si fotografi nga libri shkollor i Hararit sesa grafikët RDF, kështu që njerëzit i duan ato.

Natyrisht, detyra e "mbështetjes së LPG" ndahet në dy pjesë:

  1. duke bërë ndryshime në modelin RDF që bëjnë të mundur simulimin e konstruksioneve të LPG në të;
  2. duke bërë ndryshime në gjuhën e pyetjeve RDF që bëjnë të mundur aksesin e të dhënave në këtë model të modifikuar, ose zbatimin e aftësisë për të kërkuar këtë model në gjuhët e njohura të pyetjeve LPG.

V.1. Modeli i të dhënave

Këtu ka disa qasje të mundshme.

V.1.1. pronë e vetme

Qasja më e mirëfilltë për të harmonizuar RDF dhe LPG është ndoshta pronë e vetme:

  • Në vend të, për shembull, kallëzuesin :isMarriedTo përdoren kallëzues :isMarriedTo1, :isMarriedTo2 dhe kështu me radhë.
  • Këta kallëzues bëhen më pas subjekte të trinjakëve të rinj: :isMarriedTo1 :since "2013-09-13"^^xsd:date etj
  • Lidhja e këtyre rasteve të kallëzuesit me një kallëzues të përbashkët vendoset nga treshe të formës :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
  • Është e qartë se rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, por merrni parasysh pse nuk duhet thjesht të shkruani :isMarriedTo1 rdf:type :isMarriedTo.

Detyra e "mbështetjes së LPG" zgjidhet këtu në nivelin RDFS. Një vendim i tillë kërkon përfshirjen në përkatëse standard. Mund të kërkohen disa ndryshime nga depot RDF që mbështesin pasojat e bashkëngjitjes, por tani për tani, Singleton Property mund të mendohet si një teknikë tjetër modelimi.

V.1.2. Riifikimi u krye drejt

Qasjet më pak naive rrjedhin nga të kuptuarit se rastet e pronësisë instantohen në mënyrë të përkryer nga trenjakët. Duke qenë në gjendje të flasim për trenjakë, mund të flasim edhe për raste pronësie.

Më solide nga këto qasje është RDF*i njohur si RDR, i lindur në zorrët e Blazegraph. Është që në fillim të zgjedhur për veten time dhe AnzoGraph. Fortësia e qasjes përcaktohet nga fakti se brenda kornizës së saj ofruar ndryshimet përkatëse në Semantika RDF. Çështja, megjithatë, është jashtëzakonisht e thjeshtë. Në serializimin RDF Turtle, tani mund të shkruani diçka si kjo:

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

V.1.3. Qasje të tjera

Ju nuk mund të shqetësoheni me semantikën formale, por thjesht merrni parasysh se trenjakët kanë disa identifikues, të cilët, natyrisht, janë URI, dhe kompozoni treshe të reja me këto URI. Gjithçka që mbetet është t'u jepet akses këtyre URI-ve në SPARQL. Kështu që arrin stardog.

Në alegrograf shkoi në mënyrë të ndërmjetme. Dihet se identifikuesit e trenjakëve në Allegrograph ka, por kur zbatohen atributet e trefishta, ato nuk dalin jashtë. Megjithatë, edhe semantika formale është shumë larg. Veçanërisht, atributet e trefishtë nuk janë URI, dhe vlerat e këtyre atributeve gjithashtu mund të jenë vetëm fjalë për fjalë. Adhuruesit e LPG-së marrin pikërisht atë që dëshironin. Në formatin e shpikur posaçërisht NQX, një shembull i ngjashëm me atë të mësipërm për RDF* duket si ky:

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

V.2. Gjuhët e pyetjeve

Duke mbështetur LPG në një mënyrë ose në një tjetër në nivelin e modelit, duhet të bëni të mundur kërkimin e të dhënave në një model të tillë.

  • Blazegraph për pyetjet RDF* mbështet SPARQL* и shpirt i keq. Një pyetje SPARQL* duket kështu:

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

  • Anzograf gjithashtu mbështet SPARQL* dhe do të mbështesë Zero, gjuha e pyetjes në Neo4j.
  • Stardog ruan të vetën zgjerimi SPARQL dhe përsëri Gremlin. Ju mund të merrni URI-në e një treshe dhe "meta-informacioni" në SPARQL duke përdorur diçka si kjo:

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

  • Allegrograph gjithashtu mbështet të vetin zgjerimi SPARQL:

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

Rastësisht, GraphDB mbështeti Tinkerpop/Gremlin në një kohë pa mbështetur LPG, por kjo u ndal në versionin 8.0 ose 8.1.

VI. Shtrëngimi i licencave

Nuk ka pasur asnjë shtesë të fundit në kryqëzimin e grupeve "triplestore e zgjedhur" dhe "open source triplestore". Dyqanet e reja RDF me burim të hapur janë larg nga të qenit një zgjedhje e mirë për përdorim të përditshëm dhe kodi burimor për dyqanet e reja të trefishta që do të doja të përdorja (për shembull, AnzoGraph) është i mbyllur. Përkundrazi, mund të flasim për reduktime ...

Natyrisht, burimi i hapur më parë nuk është i mbyllur, por disa depo me burim të hapur gradualisht nuk konsiderohen më të denja për t'u zgjedhur. Virtuozi, i cili ka një botim me burim të hapur, për mendimin tim, po mbytet në defekte. Blazegraph bleu nga AWS dhe formoi bazën e Amazon Neptune; tani nuk është e qartë nëse do të ketë të paktën një lëshim më shumë. Ka mbetur vetëm Xhena...

Nëse burimi i hapur nuk është shumë i rëndësishëm, por thjesht dëshironi të provoni, atëherë gjithçka është gjithashtu më pak rozë se më parë. Për shembull:

  • Stardog ndalon shpërndani versionin falas (megjithatë, periudha e provës e atij të rregullt është dyfishuar);
  • в GraphDB Cloud, ku mund të zgjidhnit më parë planin bazë falas, regjistrimi i përdoruesit të ri pezullohet.

Në përgjithësi, hapësira po bëhet gjithnjë e më e paarritshme për një laik të zakonshëm të IT-së, zhvillimi i saj po bëhet shumë i korporatave.

Burimi: www.habr.com

Shto një koment