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-графы;
  • Ontotext 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 c оконными функциями? —

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

IV. RocksDB

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

Во-первых, cудя по статье в Википедии, на RocksDB «пересаживаются» не только RDF-хранилища. Есть проекты по использованию RocksDB как движка хранения в ArangoDB, MongoDB, MySQL и MariaDB, Cassandra.

Во-вторых, на RocksDB делаются проекты (т. е. не продукты) соответствующей тематики.

Например, eBay использует RocksDB в платформе для своего «графа знаний». Между прочим, забавно читать: the query language started as a home grown format, but more recently it has been transitioning to be much more like 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* и Gremlin. Запрос на SPARQL* выглядит так:

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

  • Anzograph тоже поддерживает SPARQL* и собирается поддерживать Cypher, язык запросов в 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-хранилищам с открытым исходным кодом далеко до того, чтобы стать хорошим выбором для повседневного использования, а исходный код новых триплсторов, которые хотелось бы поиспользовать (того же AnzoGraph), закрыт. Скорее, можно говорить об убавлениях…

Конечно, прежде открытый исходный код не закрывается, но некоторые хранилища c открытым исходным кодом постепенно перестают рассматриваться как достойные выбора. Virtuoso, имеющий opensource-редакцию, на мой взгляд, тонет в багах. Blazegraph куплен AWS и лег в основу Amazon Neptune; теперь непонятно, будет ли еще хоть один релиз. Остается лишь Jena…

Если же открытый исходный код не очень важен, а хочется просто попробовать, то всё тоже менее радужно, чем раньше. Например:

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

В общем, для рядового ИТ-обывателя космос становится все более и более недоступным, освоение его становится уделом корпораций.

Источник: habr.com