Что сейчас происходит с RDF-хранилищами?

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


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


Содержание


I. GraphQL для доступа к RDF
II. Адаптеры к MongoDB
III. OLTP vs. OLAP
IV. RocksDB
V. Поддержка LPG
     V.1. Модели данных
           V.1.1. Singleton Property
           V.1.2. Reification Done Right
           V.1.3. Прочие подходы
     V.2. Языки запросов
VI. Ужесточение лицензий


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


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


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



Если же хранилище такой возможности не предоставляет, её реализуют самостоятельно, написав соответствующий «распознаватель» (resolver). Так поступили, например, во французском проекте DataTourisme. Или уже можно ничего не писать, а просто взять HyperGraphQL.


С точки зрения ортодоксального приверженца Semantic Web и Linked Data всё это, конечно, печально, поскольку кажется предназначенным для интеграций, выстраиваемых вокруг очередных data silos, а не подходящих для того платформ (разумеется, RDF-хранилищ).


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


  • С одной стороны, GraphQL выглядит дальним родственником SPARQL: в нем решены характерные для REST проблемы перевыборки и множественности запросов — без чего, наверное, и нельзя было бы считаться языком запросов, хотя бы и для веба, и иметь в названии «-QL»;
  • С другой стороны, огорчает жесткая схемность 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, где раньше можно было выбрать бесплатный базовый план, регистрация новых пользователей приостановлена.

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

Комментарии 19

    0
    4 года назад RDF казался космосом и пришлось относительно долго в него вникать, когда я пришел на проект, но сейчас его мощь более чем очевидна. Однако технические моменты и производительность хранилища — в самом деле боль. Оно у нас свое, на базе обычный sql-БД (поддерживается как mysql, так и postgres).
    Классы сущностей тут github.com/oat-sa/generis/tree/master/core/kernel/classes
    Реализация хранилища тут github.com/oat-sa/generis/tree/master/core/kernel/persistence/smoothsql

    Предупреждаю заранее всех, решит возмутиться увиденному, код древнее мамонтов, но так как он ядро всего, туда не спешат лезть руками.
      0

      А какая стратегия укладки триплетов в таблицы у вас, если словами? Просто EAV, одна таблица с тремя столбцами?

        0
        Да, именно так. Плоская таблица и поля subject, predicate, object + вспомогательные, вроде пользователя, что сделал запись и даты создания/обновления.
          +1
          Должно работать небыстро по сравнению с purpose-built RDF-хранилищами… Хотя вот в Virtuoso подход практически такой же. Но там «под капотом» своя собственная, а не сторонняя, реляционная СУБД.

          Быть может, в зависимости от типов запросов, помогли бы составные индексы наподобие [таких](http://docs.openlinksw.com/virtuoso/rdfperfrdfscheme/). А SPARQL-то у вас нет, да?

          [Вот](https://www.springer.com/gp/book/9783642193569) не совсем ещё старая книжка, рассказывающая, как все устроено под капотом у purpose-built RDF-хранилищ (надеюсь, найдете, где скачать). Было ещё что-то хорошее и объемное, напишу, если вспомню.

          Спасибо за ссылки, всегда приятно покопаться в чужой БД СУБД.
      0
      из других подходов есть еще ArangoDB + AQL. RDF там конечно тоже можно хранить, но более интересен комплексный подход — Document store + Graph DBMS + Key-value store
        0
        Каноничный RDF, к сожалению, в ArangoDB сохранить не получится; что-то более-менее RDF-подобное — наверное, да. Под «комплексным подходом» вы имеете в виду мультимодельные возможности ArangoDB? И подход, опять же, к чему? Если, например, говорить о подходах к интеграции гетерогенных данных, то да, мультимодельные СУБД и триплсторы немного конкурируют. Постараюсь в ближайшее время написать о мультимодельных СУБД отдельную статью, буду рад получить там ваши комментарии.
          +1
          RDF слишком примитивен и если мы говорим о поиске/хранении знаний, а не о перетягивании старой парадигмы в сегодняшний день, то multi-model хранилище более эффективно. намного удобнее работать со связанными обьектами (документами), особенно при их создании/редактировании. да и мапится это все out of the box в JSON и далее в C++/Javascript. я собственно и написал «про другие подходы» так как задачи иногда не стоят с нуля, порой получаешь нафталиновое RDF/XML наследие как данность в начале проекта
            0
            Я с симпатией отношусь к ArangoDB (и к OrientDB тоже с симпатией отношусь). Если не вступать в теоретические дискуссии, а просто прицепиться к словам «знание» и «сегодняшний день», то на прошедшей на днях Knowledge Graph Conference, если судить по аннотациям докладов, ArangoDB никто не упоминал.
        0
          0
          Blazegraph куплен AWS и лег в основу Amazon Neptune; теперь непонятно, будет ли еще хоть один релиз.
          Blazegraph 2.1.5 все-таки вышел, но теперь, скорее всего, точно всё.
            +3
            I. GraphQL для доступа к RDF

            Этот тренд усиливается с каждым месяцем. Как минимум, два спеца и целая DBMS выразили поддержку только с конца года...



            Кажется утверждается MultiAPI для MultiDBMS. GraphQL так хорош?
            Это очень похоже на ситуацию с аналитикой семилетней давности. Отрасль радостно приняла колончатые базы как практичную вещь, при этом понимая, что кубы все равно лучше. Любим одних, женимся на других?
              +2

              Спасибо за ссылки! Автор первой статьи писал мне как-то в LinkedIn: generally speaking, most people don't actually want to use SPARQL, and I think that's more important than any of the technology. Собственно, и всё.


              Я рассматриваю поддержку RDF-хранилищами GraphQL как очередную попытку понравиться и стать понятными конвенциональным разработчикам. Предыдущей был JSON-LD. В дополнение к тому, что говорил в статье, могу добавить, что GraphQL сильно похож на MQL, язык запросов к Freebase, который особой популярности в LD-сообществе не приобрел.


              Если интересует тема LD, есть Telegram-группа «Linked Data Russia»: https://t.me/linkeddatarussia, я больше там по этой теме пишу.

                +1
                Да, не вооруженным глазом видно, SemanticWeb ищет спасительные соломинки — то JSON-LD, то теперь GraphQL. И напрашивается реакция: чем смотреть по сторонам, не лучше ли разобраться в себе, хорошенько покопаться в модели. Возможно пора уже заменить RDF на что-то более практичное ради успеха триплсторов.

                Спасибо за ссылку на группу. Давно искал более-менее живое общение на тему SW.
                  +2

                  Не все так плохо. Как обстоят дела, я писал в двух заключительных разделах другой статьи. Конечно, хочется увеличения рынка раз в несколько. Большие ожидания связываются с гартнеровскими «knowledge graphs». Но в той же статье отмечается, что все это вряд ли про российский рынок.


                  Некая ревизия модели сейчас в повестке есть — это RDF*, см. о ней раздел V.1.2 этой (под которой комментарий). Впрочем, можно сказать, что тут тоже «спасительная соломинка» — LPG.


                  Кстати, если совсем интересно, JSON-LD тоже вносит изменения в модель. Предикаты в нем могут быть пустыми узлами (другой вопрос, что за этим не стоит формальной семантики). Никто такого специально не хотел, так получилось. В принципе, это может быть использовано как один из способов поддержки LPG (см. раздел V.1 этой статьи), только ни одно RDF-хранилище такого не сохранит.

                    0
                    Насчет «отказаться от RDF» я конечно поспешил (спасибо группе — посвятили). Но, что важнее, присутствует прогресс.
                    Можно, наверное, выделить две серии корневых изменений:

                    1) Named graph + LinkedData (2014-2015)

                    2) RDF* + Knowledge graphs (2018-2019)

                    Так вот, думаю, накатывает новая (Бог любит троицу?). Об этом могут свидетельствовать подвижки внутри гигантов: построение экосистемы данных (Сбербанк). И мне еще кажется недооцененной идея прикреплять к триплам id (как это вроде есть в Stardog). RDF* — хорошо, но не достаточно.
              +2

              А почему в разделе VI не упомянута реификация через rdf:Statement, rdf:subject, predicate and object? Это совсем не "Reification Done Right"? Из-за объёма?

                0

                Это стандартная техника моделирования, речь же в разделе о поддержке LPG шла скорее о поддержке на уровне примитивов моделирования, что, конечно, уменьшает и объем.


                Но главная проблема неприминимости реификации в чистм виде — что, что реифицируемые суждения не утверждаются. Ну т.е Фреге перед rdf:Statement знак штопора не поставил бы. В то время как в LPG ребро между узлами графа обычно все-таки что-то утверждает. Хотя, конечно, если строго, то семантики в двух узлах LPG-графа и ребре между ними столько же, сколько в бельевой веревке на двух гвоздях :-).


                См. еще https://www.w3.org/TR/swbp-n-aryRelations/#RDFReification.

                +1

                Кстати, вот в 2015 проводили очень практичное исследование по реификации https://www.researchgate.net/publication/329482695_Reifying_RDF_What_Works_Well_With_Wikidata. Интересно, его кто-то повторял на современных хранилищах?

                  0

                  У GraphDB есть сравнение времени загрузки и занимаемого места на диске. GraphDB придерживается SA-интерпретации RDR.


                  К слову, у упоминаемой вами статьи было продолжение. Рисунок 7 показательный. Почему выбрали всё-таки Blazegraph, см. тут.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое