ProHoster > блог > интернет вести > Што се случува со складирањето RDF сега?

Што се случува со складирањето RDF сега?

Семантичката мрежа и поврзаните податоци се како вселената: таму нема живот. Да одам таму повеќе или помалку долг временски период... Не знам што ти рекоа како дете како одговор на „Сакам да станам астронаут“. Но, можете да набљудувате што се случува додека сте на Земјата; Многу е полесно да се стане аматерски астроном или дури и професионалец.

Статијата ќе се фокусира на неодамнешните, не постари од неколку месеци, трендови од светот на складирањето RDF. Метафората во првиот пасус е инспирирана од рекламната слика со епска големина под резот.


Епска слика

Што се случува со складирањето RDF сега?

I. GraphQL за RDF пристап

Тие велатдека GraphQL има за цел да стане универзален јазик за пристап до базата на податоци. Што е со можноста за пристап до RDF користејќи GraphQL?

Надвор од кутијата оваа можност е обезбедена од:

Доколку складиштето не обезбеди таква можност, тоа може да се имплементира независно со пишување соодветен „резолатор“. Така направија, на пример, во францускиот проект DataTourisme. Или повеќе не можете да пишувате ништо, туку само да земете HyperGraphQL.

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

Впечатоците од споредувањето на GraphQL со SPARQL се двојни.

  • Од една страна, GraphQL изгледа како далечен роднина на SPARQL: тој ги решава проблемите на повторното земање примероци и мноштвото прашања кои се типични за REST - без кои, веројатно, не би било можно да се разгледаат јазик за пребарување, барем за веб;
  • Од друга страна, ригидната шема на GraphQL е разочарувачка. Според тоа, неговата „интроспективност“ изгледа многу ограничена во споредба со целосната рефлексивност на RDF. И не постои аналог на патеките на имотот, па не е ни многу јасно зошто е „График-“.

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

Тренд комплементарен на претходниот.

  • Во Стардог сега можеби - особено, сите на истиот GraphQL - конфигурирајте го мапирањето на податоците на MongoDB во виртуелни RDF графикони;
  • Ontotext GraphDB неодамна таа им овозможува на вметнете фрагменти во SPARQL на MongoDB Query.

Ако зборуваме пошироко за адаптери на JSON извори, кои овозможуваат повеќе или помалку „во лет“ да го претставуваат JSON складирани во овие извори како RDF, можеме да се потсетиме на прилично долгогодишниот SPARQL Генерирање, што може да се прилагоди, на пример, до Апачи Јена.

Сумирајќи ги првите два тренда, можеме да кажеме дека складиштата RDF покажуваат целосна подготвеност за интеграција и работа во услови на „упорност на полиглот“. Познато е, меѓутоа, дека ова последново одамна е надвор од мода, и се заменува со доаѓа мулти-модел. Што е со мулти-моделирањето во светот на складирањето RDF?

Накратко, нема шанси. Би сакал да посветам посебна статија на темата за мулти-моделски DBMS, но засега може да се забележи дека во моментов не постојат мултимоделски DBMS „засновани“ на графички модел (RDF може да се смета за негов тип) . Ќе се дискутира за некои мали мулти-моделирање - поддршка за складирање RDF за алтернативен модел на графикон за LPG дел V.

III. OLTP наспроти. OLAP

Сепак, истиот Гартнер пишуватој мултимодел е sine qua non услов првенствено за операционите сали DBMS. Ова е разбирливо: во ситуација на „мултиваријантно складирање“, главните проблеми се јавуваат со трансакцијата.

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

Сепак, сепак:

  • механизмите за интеграција со MongoDB имплементирани во GraphDB не се најмалку важни наменети да работат околу пишување проблеми со перформансите;
  • Стардог оди уште подалеку и целосно препишува мотор, повторно со цел да се подобрат перформансите за снимање.

Сега дозволете ми да воведам нов играч на пазарот. Од креаторите на 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 на Google. Зошто вреди да се зборува за одреден тренд?

Прво, судејќи по Статија на Википедија, не само складиштата на RDF се „пресадуваат“ на RocksDB. Постојат проекти за користење RocksDB како мотор за складирање во ArangoDB, MongoDB, MySQL и MariaDB, Cassandra.

Второ, проекти (односно, не производи) на релевантни теми се креираат на RocksDB.

На пример, eBay користи RocksDB во платформа за вашиот „график на знаење“. Патем, смешно е да се прочита: Јазикот за прашања започна како домашен формат, но во поново време се преоѓа да биде многу повеќе како SPARQL. Како во шегата: колку и да правиме графикон за знаење, сепак завршуваме со RDF.

Друг пример - оној што се појави пред неколку месеци Услуга за барање историја на Википодатоци. Пред неговото воведување, мораше да се пристапи преку историските информации на Википодатоци MWAPI на стандардниот Mediawiki API. Сега многу е можно со чист SPARQL. „Под хаубата“ има и RocksDB. Патем, WDHQS е направен, се чини, од лицето кое го увезе Freebase во Графикот на знаење на Google.

V. Поддршка за ТНГ

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

Во ТНГ, скаларните својства можат да се доделат на инстанци на рабовите, додека кај RDF тие можат да се доделат само на „типови“ на рабовите (но не само скаларни својства, туку и обични врски). Ова ограничување на RDF во споредба со ТНГ надминат една или друга техника на моделирање. Ограничувањата на ТНГ во споредба со RDF се потешко да се надминат, но графиконите на ТНГ се повеќе како слики од учебник Харари отколку графикони на RDF, поради што луѓето ги сакаат.

Очигледно, задачата за „поддршка за ТНГ“ спаѓа во два дела:

  1. правење промени во моделот RDF што овозможуваат симулирање на структури на ТНГ во него;
  2. правење промени во јазикот на барањето RDF што овозможуваат пристап до податоци во овој модифициран модел или имплементирање на способноста да се поставуваат барања до овој модел на популарни јазици за пребарување на LPG.

V.1. Модел на податоци

Постојат неколку можни пристапи овде.

V.1.1. Имотот на Синглтон

Најбуквалниот пристап за усогласување на RDF и LPG е веројатно синглтон имот:

  • Наместо, на пример, прирокот :isMarriedTo се користат предикати :isMarriedTo1, :isMarriedTo2 i t. d.
  • Овие предикати потоа стануваат предмет на нови тројки: :isMarriedTo1 :since "2013-09-13"^^xsd:date итн
  • Поврзаноста на овие инстанци на предикати со заеднички прирок се воспоставува со тројки од формата :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
  • Очигледно тоа rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, но размислете зошто не треба само да пишувате :isMarriedTo1 rdf:type :isMarriedTo.

Проблемот со „поддршката за ТНГ“ е решен овде на ниво на RDFS. Ваквата одлука бара вклучување во соодветното стандард. Можеби ќе бидат потребни одредени промени за продавниците за RDF кои поддржуваат последици за прикачување, но засега, Singleton Property може да се смета како само уште една техника за моделирање.

V.1.2. Реификацијата е направено правилно

Помалку наивни пристапи произлегуваат од сознанието дека случаите на сопственост се целосно неодржливи со тројки. Со тоа што ќе можеме да кажеме нешто за тројки, ќе можеме да зборуваме за случаи на имот.

Најсилниот од овие пристапи е RDF*, познат како RDR, роден во длабочините на Блажеграф. Тоа е од самиот почеток избран за себе и AnzoGraph. Цврстината на пристапот се определува со тоа што во неговите рамки понудени соодветните промени во RDF Семантика. Поентата, сепак, е исклучително едноставна. Во Turtle серијализацијата на RDF сега можете да напишете нешто вака:

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

V.1.3. Други пристапи

Не можете да се замарате со формалната семантика, туку едноставно да претпоставите дека тројките имаат одредени идентификатори, кои се, се разбира, URI и создаваат нови тројки со овие URI. Останува само да се даде пристап до овие URI во SPARQL. Значи пристигнува Ѕвездено куче.

Во Алегрограф отиде на среден начин. Познато е дека тројните идентификатори во Алегрограф постои, но при имплементирање на тројни атрибути тие не се издвојуваат. Сепак, сè уште е многу далеку од формалната семантика. Вреди да се одбележи дека атрибутите на тројката не се URI, а вредностите на овие атрибути исто така можат да бидат само буквални. Приврзаниците на ТНГ го добиваат токму она што го сакале. Во специјално измислениот формат 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. Заострување на лиценците

Немаше неодамнешни дополнувања на пресекот на комплетите „тројна продавница по избор“ и „тројна продавница со отворен код“. Новите продавници со отворен код RDF се далеку од тоа да бидат добар избор за секојдневна употреба, а новите тројни продавници што би сакал да ги користам (како AnzoGraph) се со затворен код. Наместо тоа, можеме да зборуваме за намалувања...

Се разбира, отворениот код не беше затворен во минатото, но некои складишта со отворен код полека веќе не се сметаат за вредни за избор. Виртуозот, кој има издание со отворен код, според мене се дави во бубачки. Blazegraph беше купен од AWS и ја формираше основата на Амазон Нептун; сега не е јасно дали ќе има барем уште едно издание. Останува само Јена...

Ако отворениот код не е многу важен, но само сакате да го пробате, тогаш сè е исто така помалку розово од порано. На пример:

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

Општо земено, за просечен ИТ човек, просторот станува сè понепристапен, неговиот развој станува многу корпорации.

Извор: www.habr.com

Додадете коментар