ProHoster > Блог > интернет новини > Какво се случва с RDF хранилищата сега?

Какво се случва с RDF хранилищата сега?

Семантичната мрежа и свързаните данни са като космоса: там няма живот. Да отидеш там за повече или по-малко дълъг период от време... Не знам какво са ти казвали като дете в отговор на „Искам да стана космонавт“. Но можете да наблюдавате какво се случва, докато сте на Земята; Много по-лесно е да станеш астроном любител или дори професионалист.

Статията ще се фокусира върху последните, не по-стари от няколко месеца, тенденции от света на RDF съхранението. Метафората в първия параграф е вдъхновена от епичното по размер рекламно изображение под разреза.


Епична картина

Какво се случва с RDF хранилищата сега?

I. GraphQL за RDF достъп

Те казватче GraphQL има за цел да стане универсален език за достъп до база данни. Какво ще кажете за възможността за достъп до RDF чрез GraphQL?

Извън кутията тази възможност се предоставя от:

Ако хранилището не предоставя такава възможност, то може да бъде внедрено независимо чрез написване на подходящ „разрешител“. Така направиха например във френския проект DataTourisme. Или вече не можете да пишете нищо, а просто да вземете HyperGraphQL.

От гледна точка на ортодоксален привърженик на семантичния уеб и свързаните данни, всичко това, разбира се, е тъжно, тъй като изглежда предназначено за интеграции, изградени около следващия силоз за данни, а не подходящи платформи (RDF магазини, разбира се) .

Впечатленията от сравнението на GraphQL със SPARQL са двойни.

  • От една страна, GraphQL изглежда като далечен роднина на SPARQL: той решава проблемите с повторната извадка и множеството заявки, които са типични за REST - без които вероятно не би било възможно да се разгледа език за заявки, поне за мрежата;
  • От друга страна, твърдата схема на GraphQL е разочароваща. Съответно, неговата „интроспективност“ изглежда много ограничена в сравнение с пълната рефлексивност на RDF. И няма аналог на пътеките на свойствата, така че дори не е много ясно защо е „Graph-“.

II. Адаптери за MongoDB

Тенденция, допълваща предишната.

  • Сега в Stardog може би - по-специално, всички на един и същ GraphQL - конфигурирайте картографирането на MongoDB данни във виртуални RDF графики;
  • Ontotext GraphDB наскоро Тя позволява на вмъкнете фрагменти в SPARQL на MongoDB Query.

Ако говорим по-широко за адаптери към JSON източници, които позволяват повече или по-малко „в движение“ да представят JSON, съхранен в тези източници като RDF, можем да си припомним доста дългогодишната SPARQL Генериране, който може да се регулира, например, до Apache Jena.

Обобщавайки първите две тенденции, можем да кажем, че RDF хранилищата демонстрират пълна готовност за интегриране и работа в условия на „постоянство на полиглоти“. Известно е обаче, че последното отдавна не е на мода и се измества от идва мулти-модел. Какво ще кажете за мулти-моделирането в света на RDF съхранението?

Накратко няма как. Бих искал да посветя отделна статия на темата за многомоделните СУБД, но засега може да се отбележи, че в момента няма многомоделни СУБД, „базирани“ на графичен модел (RDF може да се счита за негов вид) . Няколко малки мултимоделиране - поддръжка на RDF съхранение за алтернативен графичен модел на LPG - ще бъдат обсъдени в раздел V.

III. OLTP срещу. OLAP

Въпреки това, същият Gartner пишече мултимоделът е задължително условие преди всичко за операционни зали СУБД. Това е разбираемо: в ситуация на „многовариантно съхранение“ основните проблеми възникват с транзакционността.

Но къде се намират RDF хранилищата в скалата OLTP-OLAP? Бих отговорил така: нито там, нито тук. За да се посочи за какво са предназначени е необходимо трето съкращение. Като вариант бих предложил ОЛИП — Онлайн интелектуална обработка.

Все пак обаче:

  • механизмите за интеграция с MongoDB, внедрени в GraphDB, не са на последно място предназначени за заобикаляне на проблеми с производителността при запис;
  • 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 като основна система за съхранение - хранилище за ключ-стойност, разклонение на Facebook на LevelDB на Google. Защо си струва да говорим за определена тенденция?

Първо, съдейки по Статия в Уикипедия, не само RDF хранилищата са „трансплантирани“ в RocksDB. Има проекти за използване на RocksDB като двигател за съхранение в ArangoDB, MongoDB, MySQL и MariaDB, Cassandra.

Второ, проекти (т.е. не продукти) по подходящи теми се създават в RocksDB.

Например eBay използва RocksDB в платформа за вашата „графика на знанието“. Между другото, смешно е да се чете: езикът за заявки започна като домашен формат, но напоследък преминава към много повече като SPARQL. Както във вица: колкото и графика на знания да направим, все пак стигаме до RDF.

Още един пример – появил се преди няколко месеца Услуга за търсене на история на Wikidata. Преди въвеждането му, историческата информация на Wikidata трябваше да бъде достъпна чрез MWAPI към стандартния API на Mediawiki. Сега много е възможно с чист SPARQL. „Под капака“ има и RocksDB. Между другото, WDHQS е направен, изглежда, от лицето, което импортира Freebase в Google Knowledge Graph.

V. LPG поддръжка

Нека ви напомня за основната разлика между LPG графиките и RDF графиките.

В LPG скаларните свойства могат да бъдат присвоени на крайни екземпляри, докато в RDF те могат да бъдат присвоени само на крайни „типове“ (но не само скаларни свойства, но и обикновени връзки). Това ограничение на RDF в сравнение с LPG преодолявам една или друга техника на моделиране. Ограниченията на LPG в сравнение с RDF са по-трудни за преодоляване, но LPG графиките са по-скоро като снимки от учебник на Harari, отколкото RDF графики, поради което хората ги искат.

Очевидно задачата за „поддръжка на LPG“ се разделя на две части:

  1. извършване на промени в RDF модела, които правят възможно симулирането на LPG структури в него;
  2. извършване на промени в езика за заявки RDF, които правят възможен достъп до данни в този модифициран модел, или прилагане на възможността да се правят заявки към този модел на популярни езици за заявки LPG.

V.1. Модел на данни

Тук има няколко възможни подхода.

V.1.1. Сингълтън собственост

Най-буквалният подход за хармонизиране на RDF и LPG вероятно е единична собственост:

  • Вместо например сказуемото :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. Реификацията е направена правилно

По-малко наивните подходи произтичат от осъзнаването, че екземплярите на свойства са напълно инстанцируеми от триплети. Като можем да кажем нещо за тризнаци, ще можем да говорим за случаи на собственост.

Най-стабилният от тези подходи е RDF*, известен още като RDR, роден в дълбините на Blazegraph. Това е от самото начало избрани за себе си и AnzoGraph. Солидността на подхода се определя от факта, че в неговите рамки предлагани съответните промени в RDF семантика. Въпросът обаче е изключително прост. В сериализацията на Turtle на RDF вече можете да напишете нещо подобно:

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

V.1.3. Други подходи

Не можете да се занимавате с формална семантика, а просто да приемете, че триплетите имат определени идентификатори, които, разбира се, са URI, и да създадете нови триплети с тези URI. Всичко, което остава, е да се даде достъп до тези URI в SPARQL. Така пристига Stardog.

В Алегрограф отиде по междинен начин. Известно е, че триплетните идентификатори в Allegrograph има, но при прилагане на тройни атрибути те не стърчат. Все още обаче е много далеч от формалната семантика. Трябва да се отбележи, че триплетните атрибути не са URI и стойностите на тези атрибути също могат да бъдат само литерали. Привържениците на LPG получават точно това, което искат. В специално създадения формат NQX, пример, подобен на горния за RDF*, изглежда така:

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

V.2. Езици за заявки

След като поддържате LPG по един или друг начин на ниво модел, трябва да направите възможно да правите заявки за данни в такъв модел.

  • Поддържа Blazegraph за RDF* заявки SPARQL* и Гремлин. SPARQL* заявка изглежда така:

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

  • Анзограф също поддържа SPARQL* и ще подкрепи Cypher, език за заявки в Neo4j.
  • Stardog подкрепя своите разширение SPARQL и отново Гремлин. Можете да получите триплетния URI и „метаинформация“ в SPARQL, като използвате нещо подобно:

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

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

Между другото, GraphDB по едно време поддържаше Tinkerpop/Gremlin, без да поддържа LPG, но това спря във версия 8.0 или 8.1.

VI. Затягане на лицензите

Не е имало скорошни добавки към пресечната точка на наборите „triplestore of choice“ и „open source triplestore“. Новите RDF хранилища с отворен код далеч не са добър избор за ежедневна употреба, а новите тройни хранилища, които бих искал да използвам (като AnzoGraph), са със затворен код. По-скоро можем да говорим за намаления...

Разбира се, отвореният код не е бил затворен в миналото, но някои хранилища с отворен код постепенно вече не се смятат за заслужаващи избор. Virtuoso, който има издание с отворен код, според мен тъне в бъгове. Blazegraph беше закупен от AWS и формира основата на Amazon Neptune; сега не е ясно дали ще има поне още едно издание. Остава само Йена...

Ако отвореният код не е много важен, но просто искате да го изпробвате, тогава всичко също е по-малко розово от преди. Например:

  • Звездно куче прекратява разпространявайте безплатната версия (пробният период на обикновената версия обаче се е удвоил);
  • в GraphDB Cloud, където преди това можехте да изберете безплатен основен план, регистрациите на нови потребители са спрени.

Като цяло за обикновения ИТ човек космосът става все по-недостъпен, развитието му става част от корпорациите.

Източник: www.habr.com

Добавяне на нов коментар