Хабрахабр

[Из песочницы] Что сейчас происходит с RDF-хранилищами?

Чтобы отправиться туда на более-менее длительный срок… ну, не знаю, что говорили вам в детстве в ответ на «хочу стать космонавтом». Semantic Web и Linked Data подобны ближнему космосу: жизни там нет. Но понаблюдать за происходящим можно и находясь на Земле; стать астрономом-любителем или даже профессионалом гораздо проще.

Метафора в первом абзаце была навеяна эпических размеров рекламной картинкой под катом. В статье речь пойдет о свежих, не старее нескольких месяцев, трендах из мира RDF-хранилищ.

Эпическая картинка

image

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

А как обстоят дела с возможностью доступа с использованием GraphQL к RDF? Говорят, что GraphQL претендует стать универсальным языком доступа к базам данных.

«Из коробки» такую возможность предоставляют:

Так поступили, например, во французском проекте DataTourisme. Если же хранилище такой возможности не предоставляет, её реализуют самостоятельно, написав соответствующий «распознаватель» (resolver). Или уже можно ничего не писать, а просто взять 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 c оконными функциями?

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

IV. RocksDB

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

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

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

Между прочим, забавно читать: the query language started as a home grown format, but more recently it has been transitioning to be much more like SPARQL. Например, eBay использует RocksDB в платформе для своего «графа знаний». Как в анекдоте: сколько knowledge graph ни делаем, все равно получается RDF.

До его появления за историческими сведениями Викиданных приходилось обращаться через MWAPI к стандартному Mediawiki API. Другой пример — появившийся несколько месяцев назад Wikidata History Query Service. «Под капотом» там тоже RocksDB. Теперь многое возможно на чистом SPARQL. Кстати, сделал WDHQS, похоже, человек, занимавшийся импортом Freebase в Google Knowledge Graph.

V. Поддержка LPG

Напомню основное отличие LPG-графов от RDF-графов.

Эта ограниченность RDF по сравнению с LPG преодолевается теми или иными техниками моделирования. В LPG на экземпляры ребер могут навешиваться скалярные свойства, в то время как в RDF они могут навешиваться лишь на «типы» ребер (зато не только скалярные свойства, но и обычные связи). Ограниченность же LPG по сравнению с RDF преодолевается сложнее, но LPG-графы больше, чем RDF-графы, похожи на картинки из учебника Харари, поэтому люди их хотят.

Очевидно, задача «поддержки LPG» распадается на две части:

  1. внесение в модель RDF изменений, дающих возможность имитировать в ней LPG-конструкции;
  2. внесение в язык запросов к RDF изменений, дающих возможность обращаться к данным в этой измененной модели, — либо же реализация возможности делать запросы к этой модели на популярных языках запросов к LPG.

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

Здесь имеется несколько возможных подходов.

1. V. Singleton Property 1.

Самый буквальный подход к гармонизации 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 можно воспринимать просто как еще одну техника моделирования.

1. V. Reification Done Right 2.

Имея возможность говорить что-то о триплетах, мы получим возможность говорить и об экземплярах свойств. Менее наивные подходы проистекают из осознания того, что экземпляры свойств вполне инстанциируются триплетами.

Его с самого начала избрал для себя и AnzoGraph. Самый солидный из этих подходов — RDF*, он же RDR, родившийся в недрах Blazegraph. Суть, однако, чрезвычайно проста. Солидность подхода определяется тем, что в его рамках предлагаются соответствующие изменения в RDF Semantics. В Turtle-сериализации RDF можно теперь будет писать примерно так:

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

1. V. Прочие подходы 3.

Останется лишь дать доступ к этим URI в SPARQL. Можно не заморачиваться формальной семантикой, а просто считать, что у триплетов есть некие идентификаторы, являющиеся, естественно, URI, и составлять новые триплеты с этими URI. Так поступает Stardog.

Известно, что идентификаторы триплетов в Allegrograph есть, но при реализации triple attributes наружу они не торчат. В Allegrograph пошли промежуточным путем. Примечательно, что атрибуты триплетов — не URI, и значения этих атрибутов тоже могут быть только литералами. Однако и до формальной семантики очень далеко. В специально изобретенном формате NQX пример, аналогичный приведенному выше для RDF*, выглядит так: Адепты LPG получают ровно то, что хотели.

: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
}

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

0 или 8. Кстати, GraphDB одно время поддерживала Tinkerpop/Gremlin, не поддерживая при этом LPG, но в версии 8. 1 это прекратилось.

VI. Ужесточение лицензий

Новым RDF-хранилищам с открытым исходным кодом далеко до того, чтобы стать хорошим выбором для повседневного использования, а исходный код новых RDF-хранилищ, которые хотелось бы поиспользовать (того же AnzoGraph), закрыт. Никаких прибавлений в пересечении множеств «triplestore of choice» и «open source triplestore» в последнее время не случалось. Скорее можно говорить даже об убавлениях…

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть