Semantic Web і Linked Data подібні до ближнього космосу: життя там немає. Щоб вирушити туди на більш-менш тривалий термін… не знаю, що казали вам у дитинстві у відповідь на «хочу стати космонавтом». Але поспостерігати за тим, що відбувається, можна і перебуваючи на Землі; стати астрономом-аматором чи навіть професіоналом набагато простіше.
У статті мова піде про свіжі, не старіші за кілька місяців, тренди зі світу RDF-сховищ. Метафора у першому абзаці навіяна епічних розмірів рекламною картинкою під катом.
Епічна картинка
I. GraphQL для доступу до RDF
, що GraphQL претендує стати універсальною мовою доступу до баз даних. А як справи з можливістю доступу з використанням GraphQL до RDF?
«З коробки» таку можливість надають:
- Stardog (, );
- продукти TopQuadrant (, ).
Якщо сховище такої можливості не надає, її реалізують самостійно, написавши відповідний «розпізнавач» (resolver). Так вчинили, наприклад, у французькому проекті . Або вже можна нічого не писати, а просто взяти .
З точки зору ортодоксального прихильника Semantic Web і Linked Data все це, звичайно, сумно, оскільки здається призначеним для інтеграцій, що вибудовуються навколо чергових data silo, а не платформ, що підходять для того (зрозуміло, RDF-сховищ).
Враження від порівняння GraphQL зі SPARQL залишаються подвійні.
- З одного боку, GraphQL виглядає далеким родичем SPARQL: у ньому вирішено характерні для REST проблеми перевибірки та множини запитів — без чого, мабуть, і не можна було б вважатися мовою запитів, хоча б і для Інтернету;
- З іншого боку, засмучує жорстка схемність GraphQL. Відповідно, його «інтроспективність» видається дуже обмеженою порівняно з повною рефлексивністю RDF. І немає ніякого аналога property paths, тому навіть не дуже зрозуміло, чому він «Graph-».
ІІ. Адаптери до MongoDB
Тренд, комплементарний попередньому.
- У Stardog тепер – зокрема, все на тому ж GraphQL – налаштувати відображення даних MongoDB у віртуальні RDF-графи;
- Ontotext GraphDB з недавніх пір вставляти в SPARQL фрагменти MongoDB Query.
Якщо говорити ширше, про адаптери до JSON-джерел, що дозволяють більш-менш «на льоту» представляти JSON як RDF, що зберігається в цих джерелах, то можна згадати і досить давно існуючий , який можна приладнати, , до Apache Jena.
Резюмуючи перші два тренди, можна сказати, що RDF-сховища демонструють повну готовність до інтеграцій та функціонування в умовах багатоваріантного зберігання (polyglot persistence). Відомо, що це останнє вже давно не в моді, і на зміну йому мультимодельність. А як справи з мультимодельністю у світі RDF-сховищ?
Якщо коротко, то ніяк. Темі мультимодельних СУБД хочеться присвятити окрему статтю, поки можна помітити, що мультимодельных СУБД, «заснованих» на графової моделі (різновидом її вважатимуться RDF), зараз немає. Про якусь малу мультимодельність - підтримку RDF-сховищами альтернативної графової моделі LPG - буде розказано в .
ІІІ. OLTP vs. OLAP
Втім, той самий Gartner , Що мультимодельність - умова sine qua non в першу чергу для операційних СУБД. Воно й зрозуміло: у ситуації «багатоваріантного зберігання» головні проблеми виникають із транзакційністю.
Ось тільки де на шкалі OLTP-OLAP знаходяться RDF-сховища? Я відповів би так: ні там, ні тут. Для позначення того, для чого вони призначені, потрібна якась третя абревіатура. Як варіант запропонував би OLIP - Online Intellectual Processing.
Проте все-таки:
- реалізовані в GraphDB механізми інтеграції з MongoDB не в останню чергу для обходу проблем із продуктивністю запису;
- Stardog йде ще далі і повністю двигун, знов-таки з метою підвищити продуктивність запису.
А тепер дозвольте уявити нового гравця на ринку. Від творців IBM Netezza і Amazon Redshift . Зображення з реклами продукту на його основі було розміщено на початку статті. AnzoGraph позиціонує себе як GOLAP-рішення. Як вам SPARQL з віконними функціями? -
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }IV. RocksDB
Вище вже на анонс Stardog 7 Beta, де говорилося, що Stardog збирається використовувати як нижчу систему зберігання RocksDB - сховище «ключ-значення», фейсбуківський форк гуглівської LevelDB. Чому вже варто говорити про якийсь тренд?
По-перше, судячи з На RocksDB «пересідають» не тільки RDF-сховища. Є проекти з використання RocksDB як двигун зберігання в ArangoDB, MongoDB, MySQL і MariaDB, Cassandra.
По-друге, на RocksDB робляться проекти (тобто продукти) відповідної тематики.
Наприклад, eBay використовує RocksDB в для свого "графа знань". Між іншим, кумедно читати: the query language started as home grown format, але більше, ніж раніше, це буде переглянуто, щоб більше more like SPARQL. Як в анекдоті: скільки knowledge graph не робимо, все одно виходить RDF.
Інший приклад — кілька місяців тому, що з'явився. . До появи за історичними відомостями Вікіданих доводилося звертатися через до стандартного Mediawiki API. Тепер багато можливо на чистому SPARQL. "Під капотом" там теж RocksDB. До речі, зробив WDHQS, схоже, людина, яка займалася імпортом Freebase у Google Knowledge Graph.
V. Підтримка LPG
Нагадаю основну відмінність LPG-графів від RDF-графів.
У LPG на екземпляри ребер можуть навішуватися скалярні властивості, тоді як і RDF можуть навішуватися лише з «типи» ребер (зате як скалярні властивості, а й звичні зв'язку). Ця обмеженість RDF у порівнянні з LPG тими чи іншими техніками моделювання. Обмеженість же LPG у порівнянні з RDF долається складніше, але LPG-графи більше, ніж RDF-графи, схожі на картинки з підручника Харарі, тому люди їх хочуть.
Очевидно, завдання «підтримки LPG» розпадається на дві частини:
- внесення в модель RDF змін, що дають змогу імітувати у ній LPG-конструкції;
- внесення до мови запитів до RDF змін, що дають можливість звертатися до даних у цій зміненій моделі, або ж реалізація можливості робити запити до цієї моделі популярними мовами запитів до LPG.
V.1. Модель даних
Тут є кілька можливих підходів.
V.1.1. Singleton Property
Самий буквальний підхід до гармонізації 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. Reification Done Right
Менш наївні підходи випливають з усвідомлення того, що екземпляри властивостей цілком інстанціюються триплетами. Маючи можливість говорити щось про триплети, ми матимемо можливість говорити і про екземпляри властивостей.
Найсолідніший із цих підходів — , він же RDR, у надрах Blazegraph. Його від початку для себе та AnzoGraph. Солідність підходу визначається тим, що в його рамках відповідні зміни до . Суть, однак, надзвичайно проста. У Turtle-серіалізації RDF можна тепер писати приблизно так:
<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .V.1.3. Інші підходи
Можна не морочитися формальної семантикою, а вважати, що з триплетів є деякі ідентифікатори, є, природно, URI, і складати нові триплети з цими URI. Залишиться лише дати доступ до цих URI у SPARQL. Так Stardog.
В Allegrograph проміжним шляхом. Відомо, що ідентифікатори триплетів у Allegrograph , але при реалізації трьох атрибутів назовні вони не стирчать. Однак і до формальної семантики дуже далеко. Примітно, що атрибути триплетів не URI, і значення цих атрибутів також можуть бути лише літералами. Адепти LPG отримують те, що хотіли. У спеціально винайденому форматі NQX приклад, аналогічний наведеному вище для RDF*, виглядає так:
:bob :marriedTo :alice {"since" : "2013-09-13"}V.2. Мови запитів
Підтримавши тим чи іншим способом LPG на рівні моделі, потрібно надати можливість робити запити до даних у такій моделі.
- Blazegraph для запитів до RDF* підтримує и . Запит на SPARQL* має такий вигляд:
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }- Anzograph також підтримує і збирається підтримувати , мова запитів у Neo4j.
- Stardog підтримує власне SPARQL та Гремлін. Отримати в 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), закритий. Швидше, можна говорити про зменшення…
Звичайно, спочатку відкритий вихідний код не закривається, але деякі сховища з відкритим вихідним кодом поступово перестають розглядатися як гідні вибору. Virtuoso, що має Opensource-редакцію, на мій погляд, тоне в багах. Blazegraph куплено AWS і ліг в основу Amazon Neptune; тепер незрозуміло, чи буде ще хоч один реліз. Залишається лише Jena…
Якщо ж відкритий вихідний код не дуже важливий, а хочеться просто спробувати, то теж менш райдужно, ніж раніше. Наприклад:
- Stardog поширювати безкоштовну версію (втім, виріс у два рази пробний період звичайної);
- в , де раніше можна було вибрати безкоштовний базовий план, реєстрацію нових користувачів припинено.
Загалом, для пересічного ІТ-обивателя космос стає дедалі більше недоступним, освоєння його стає долею корпорацій.
Джерело: habr.com