ProHoster > блог > адміністраванне > Што зараз адбываецца з RDF-сховішчамі?

Што зараз адбываецца з RDF-сховішчамі?

Semantic Web і Linked Data падобныя да блізкага космасу: жыцця там няма. Каб адправіцца туды на больш-менш працяглы тэрмін… ну, не ведаю, што казалі вам у дзяцінстве ў адказ на "жадаю стаць касманаўтам". Але паназіраць за тым, што адбываецца, можна і знаходзячыся на Зямлі; стаць астраномам-аматарам ці нават прафесіяналам значна прасцей.

У артыкуле прамова пайдзе аб свежых, не старэй некалькіх месяцаў, трэндах са свету RDF-сховішчаў. Метафара ў першым абзацы была навеяна эпічных памераў рэкламнай карцінкай пад катом.


Эпічная карцінка

Што зараз адбываецца з RDF-сховішчамі?

I. GraphQL для доступу да RDF

кажуць, Што GraphQL прэтэндуе стаць універсальным мовай доступу да баз дадзеных. А як ідуць справы з магчымасцю доступу з выкарыстаннем GraphQL да RDF?

"Са скрынкі" такую ​​магчымасць падаюць:

Калі ж сховішча такой магчымасці не дае, яе рэалізуюць самастойна, напісаўшы адпаведны "распазнавальнік" (resolver). Так зрабілі, напрыклад, у французскім праекце DataTourisme. Ці ўжо можна нічога не пісаць, а проста ўзяць HyperGraphQL.

З пункту гледжання артадаксальнага прыхільніка Semantic Web і Linked Data усё гэта, вядома, сумна, паколькі здаецца прызначаным для інтэграцый, якія выбудоўваюцца вакол чарговых data silo, а не падыходных для таго платформаў (зразумела, RDF-сховішчаў).

Уражанні ад параўнання GraphQL са SPARQL застаюцца дваякія.

  • З аднаго боку, GraphQL выглядае далёкім сваяком SPARQL: у ім вырашаны характэрныя для REST праблемы перавыбаркі і множнасці запытаў - без чаго, напэўна, і нельга было б лічыцца мовай запытаў, хоць бы і для вэба;
  • З іншага боку, засмучае цвёрдая схемнасць GraphQL. Адпаведна, яго "інтраспектыўнасць" здаецца вельмі абмежаванай у параўнанні з поўнай рэфлексіўнасцю RDF. І няма ніякага аналага property paths, так што нават не вельмі зразумела, чаму ён "Graph-".

II. Адаптары да MongoDB

Трэнд, камплементарны папярэдняму.

  • у Stardog зараз магчыма – у прыватнасці, усё на тым жа GraphQL – наладзіць адлюстраванне дадзеных MongoDB у віртуальныя RDF-графы;
  • GraphDB з нядаўніх часоў дазваляе устаўляць у SPARQL фрагменты на MongoDB Query.

Калі казаць шырэй, пра адаптары да JSON-крыніц, якія дазваляюць больш-менш "на лёце" прадстаўляць які захоўваецца ў гэтых крыніцах JSON як RDF, то можна ўспомніць і даўнавата існуючы SPARQL Generate, Які можна прыладзіць, напрыклад, да Apache Jena.

Рэзюмуючы першыя два трэнду, можна сказаць, што RDF-сховішчы дэманструюць поўную гатоўнасць да інтэграцый і функцыянаванню ва ўмовах "шматварыянтнага захоўвання" (polyglot persistence). Вядома, зрэшты, што гэта апошняе ўжо даўно не ў модзе, і на змену яму будзе мультымадэльнасць. А як ідуць справы з мультымадэльнасцю ў свеце RDF-сховішчаў?

Калі сцісла, то ніяк. Тэме мультымадэльных СКБД хочацца прысвяціць асобны артыкул, пакуль жа можна заўважыць, што мультымадэльных СКБД, "заснаваных" на графавай мадэлі (разнавіднасцю яе можна лічыць RDF), цяпер няма. Аб нейкай малой мультымадэльнасці – падтрымцы RDF-сховішчамі альтэрнатыўнай графавай мадэлі LPG – будзе расказана ў раздзеле V.

III. OLTP vs. OLAP

Зрэшты, той жа Gartner піша, што мультымадэльнасць - умова sine qua non у першую чаргу для аперацыйных СКБД. Яно і зразумела: у сітуацыі "шматварыянтнага захоўвання" галоўныя праблемы ўзнікаюць з транзакцыйнасцю.

Вось толькі дзе на шкале OLTP-OLAP знаходзяцца RDF-сховішчы? Я б адказаў так: ні там, ні тут. Для абазначэння таго, да чаго яны прызначаны, патрэбна нейкая трэцяя абрэвіятура. Як варыянт прапанаваў бы OLIP - Online Intellectual Processing.

Аднак усё ж:

  • рэалізаваныя ў GraphDB механізмы інтэграцыі з MongoDB не ў апошнюю чаргу прызначаны для абыходу праблем з прадукцыйнасцю запісу;
  • Stardog ідзе яшчэ далей і цалкам перапісвае рухавічок, ізноў-ткі з мэтай падвысіць прадукцыйнасць запісу.

А зараз дазвольце прадставіць новага гульца на рынку. ад стваральнікаў IBM Netezza і Amazon Redshift - AnzoGraph. Малюнак з рэкламы прадукта на яго аснове была размешчана ў пачатку артыкула. AnzoGraph пазіцыянуе сябе як GOLAP-рашэнне. Як вам SPARQL з аконнымі функцыямі? -

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

IV. RocksDB

Вышэй ужо была спасылка на анонс Stardog 7 Beta, дзе гаварылася, што Stardog збіраецца выкарыстоўваць у якасці ніжэйлеглай сістэмы захоўвання RocksDB - сховішча «ключ-значэнне», фэйсбукаўскі форк гуглаўскай LevelDB. Чаму ўжо варта казаць аб нейкім трэндзе?

Па-першае, мяркуючы па артыкуле ў Вікіпедыі, на RocksDB перасаджваюцца не толькі RDF-сховішчы. Ёсць праекты па выкарыстанні RocksDB як рухавічка захоўвання ў ArangoDB, MongoDB, MySQL і MariaDB, Cassandra.

Па-другое, на RocksDB робяцца праекты (т. е. не прадукты) адпаведнай тэматыкі.

Напрыклад, eBay выкарыстоўвае RocksDB у платформе для свайго "графа ведаў". Між іншым, смешна чытаць: the query language started as home grown format, але больш за ўсё гэта будзе пераадольваць, каб быць больш за ўсё SPARQL. Як у анекдоце: колькі knowledge graph не робім, усё роўна атрымліваецца RDF.

Іншы прыклад - які з'явіўся некалькі месяцаў таму Wikidata History Query Service. Да яго з'яўлення па гістарычныя звесткі Вікідадзеных даводзілася звяртацца праз MWAPI да стандартнага Mediawiki API. Цяпер шмат што магчыма на чыстым SPARQL. Пад капотам тамака таксама RocksDB. Дарэчы, зрабіў WDHQS, здаецца, чалавек, які займаўся імпартам Freebase у Google Knowledge Graph.

V. Падтрымка LPG

Нагадаю асноўнае адрозненне LPG-графаў ад RDF-графаў.

У LPG на асобнікі рэбраў могуць наважвацца скалярныя ўласцівасці, у той час як у RDF яны могуць наважвацца толькі на "тыпы" рэбраў (затое не толькі скалярныя ўласцівасці, але і звычайныя сувязі). Гэтая абмежаванасць RDF у параўнанні з LPG пераадольваецца тымі ці іншымі тэхнікамі мадэлявання. Абмежаванасць жа LPG у параўнанні з RDF пераадольваецца складаней, але LPG-графы больш, чым RDF-графы, падобныя на карцінкі з падручніка Харары, таму людзі іх жадаюць.

Відавочна, задача "падтрымкі LPG" распадаецца на дзве часткі:

  1. занясенне ў мадэль RDF змен, якія даюць магчымасць імітаваць у ёй LPG-канструкцыі;
  2. занясенне ў мову запытаў да RDF змен, якія даюць магчымасць звяртацца да дадзеных у гэтай змененай мадэлі, – альбо ж рэалізацыя магчымасці рабіць запыты да гэтай мадэлі на папулярных мовах запытаў да LPG.

V.1. Мадэль дадзеных

Тут ёсць некалькі магчымых падыходаў.

V.1.1. Singleton Property

Самы літаральны падыход да гарманізацыі RDF і LPG – гэта, напэўна, singleton property:

  • Замест, напрыклад, прэдыката :isMarriedTo ужываюцца прэдыкаты :isMarriedTo1, :isMarriedTo2 і г.д.
  • Затым гэтыя прэдыкаты становяцца суб'ектамі новых трыплет. :isMarriedTo1 :since "2013-09-13"^^xsd:date і інш
  • Сувязь гэтых асобнікаў прэдыкатаў з агульным прэдыкатам усталёўваецца трыплетамі выгляду :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
  • Відавочна, што rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, але падумайце, чаму не варта пісаць проста :isMarriedTo1 rdf:type :isMarriedTo.

Задача "падтрымкі LPG" вырашаецца тут на ўзроўні RDFS. Такое рашэнне патрабуе ўнясення ў адпаведны стандарт. Нейкія змены могуць запатрабавацца ад RDF-сховішчаў, якія падтрымліваюць далучэнне следстваў, а пакуль Singleton Property можна ўспрымаць проста як яшчэ адну тэхніка мадэлявання.

V.1.2. Reification Done Right

Менш наіўныя падыходы вынікаюць з усведамлення таго, што асобнікі ўласцівасцяў цалкам инстанцируются трыплет. Маючы магчымасць казаць нешта пра трыплет, мы атрымаем магчымасць казаць і пра асобнікі ўласцівасцяў.

Самы самавіты з гэтых падыходаў - RDF*, ён жа RDR, які нарадзіўся у нетрах Blazegraph. Яго з самага пачатку абраў для сябе і AnzoGraph. Самавітасць падыходу вызначаецца тым, што ў яго рамках прапануюцца адпаведныя змены ў RDF Semantics. Іста, аднак, надзвычай простая. У Turtle-серыялізацыі RDF можна зараз будзе пісаць прыкладна так:

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

V.1.3. Іншыя падыходы

Можна не затлумляцца фармальнай семантыкай, а проста лічыць, што ў трыплет ёсць некаторыя ідэнтыфікатары, якія з'яўляюцца, натуральна, URI, і складаць новыя трыплет з гэтымі URI. Застанецца толькі даць доступ да гэтых URI у SPARQL. Так паступае Stardog.

У Allegrograph пайшлі прамежкавым шляхам. Вядома, што ідэнтыфікатары трыплет у Allegrograph ёсць, але пры рэалізацыі triple attributes вонкі яны не тырчаць. Аднак і да фармальнай семантыкі вельмі далёка. Характэрна, што атрыбуты трыплет - не URI, і значэння гэтых атрыбутаў таксама могуць быць толькі літараламі. Адэпты LPG атрымліваюць роўна тое, што хацелі. У адмыслова вынайдзеным фармаце NQX прыклад, аналагічны прыведзенаму вышэй для RDF*, выглядае так:

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

V.2. Мовы запытаў

Падтрымаўшы тым ці іншым спосабам LPG на ўзроўні мадэлі, трэба даць магчымасць рабіць запыты да дадзеных у такой мадэлі.

  • Blazegraph для запытаў да RDF* падтрымлівае SPARQL* и грэмлін. Запыт на SPARQL* выглядае так:

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

  • Anzograph таксама падтрымлівае SPARQL* і збіраецца падтрымліваць Шыфр, мова запытаў у Neo4j.
  • Stardog падтрымлівае ўласнае пашырэнне SPARQL і зноў-такі Gremlin. Атрымаць у SPARQL URI трыплет і «метаінфармацыю» можна з дапамогай прыкладна такой канструкцыі:

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

  • Allegrograph таксама падтрымлівае ўласнае пашырэнне SPARQL:

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

Дарэчы, GraphDB адзін час падтрымлівала Tinkerpop/Gremlin, не падтрымліваючы пры гэтым LPG, але ў версіі 8.0 ці 8.1 гэта спынілася.

VI. Узмацненне жорсткасці ліцэнзій

Ніякіх дадаткаў у скрыжаванні мностваў "triplestore of choice" і "open source triplestore" у апошні час не здаралася. Новым RDF-сховішчам з адчыненым зыходным кодам далёка да таго, каб стаць добрым выбарам для паўсядзённага выкарыстання, а зыходны код новых RDF-сховішчаў, якія жадалася бы выкарыстаць (таго ж AnzoGraph), зачынены. Хутчэй можна казаць нават аб змяншэнні…

Вядома, перш адчынены зыходны код не зачыняецца, але некаторыя сховішчы c адчыненым зыходным кодам паступова перастаюць разглядацца як годныя выбару. Virtuoso, які мае opensource-рэдакцыю, на мой погляд, тоне ў багах. Blazegraph набыты AWS і лёг у аснову Amazon Neptune; зараз незразумела, ці будзе яшчэ хоць адзін рэліз. Застаецца толькі Jena…

Калі ж адкрыты зыходны код не вельмі важны, а жадаецца проста паспрабаваць, тое ўсё таксама меней вясёлкава, чым раней. Напрыклад:

  • Зорны сабака спыняе распаўсюджваць бясплатную версію (зрэшты, вырас у два разы выпрабавальны перыяд звычайнай);
  • в GraphDB Cloud, дзе раней можна было выбраць бясплатны базавы план, прыпынена рэгістрацыя новых карыстальнікаў.

Увогуле, для радавога ІТ-абывацеля космас становіцца ўсё больш і больш недаступным, засваенне яго становіцца доляй карпарацый.

Крыніца: habr.com

Дадаць каментар