RDF является графовой моделью данных, она существует с 1997 г., является стандартом консорциума W3C и используется, например, в проекте schema.org и протоколе Open Graph. Кроме того, разработан целый ряд графовых СУБД на базе RDF, некоторые из них уже пользуются известностью и умеют делать вещи, на которые не способны другие СУБД.

RDF также является строительным блоком Semantic Web, причем Semantic Web имеет дурную репутацию. Как утверждают критики, это невозможно, это академично, это в основе ущербно, а работающие над этим люди не имеют представления о проблемах реального мира и реальном конструировании ПО и это невозможно будет масштабировать.

Однако, быть может RDF не совсем бесполезная вещь, и к RDF-СУБД стоит присмотреться? Как они соотносятся с Neo4j, самой популярной из ныне существующих графовых СУБД? Вот в некотором роде краш-тест.

Графы бывают разными

CEO компании, выпускающей Neo4j, Эмиль Айфрем, рассказывает, что провел много времени в мире Semantic Web, и в философском плане он, по большому счету, уже не может соглашаться с идеей представления мира в виде графа и его моделирования в этом духе.

«Semantic Web и Neo4j — духовные братья и сестры. В чем их различие, так это в деталях реализации, а я принадлежу к тем, кто считает, что детали действительно важны», — говорит Айфрем.

Он продолжает: «RDF по существу является публикационной моделью для Всемирной паутины. Ряд людей попытались превратить ее в модель данных для ПО, но я не думаю, что это имеет смысл. На более низком уровне RDF очень выразительна, но вместе с тем и слишком гранулярна.

Посудите сами: допустим, вы имеете узел, представляющий человека, и вы хотите дать ему имя. В RDF у вас будет один узел Person, к которому вам придется добавить другой узел для имени человека и еще связь ’hasName’.

В Neo4j модель более компактна: вы просто-напросто добавляете свойство для имени человека, и все. Это может показаться мелочью, но быть существенной разницей в плане применимости в продукте.

Другое различие связано с подходом к конструированию ПО. В сообществе Semantic Web имеется пул суперинтеллектуалов, но у них, как правило, крайне академический подход. Это люди, которые в основном выдают академические статьи, и это влияет на качество ПО.

Иногда все получается хорошо, но часто это очень трудно использовать. Возьмем, к примеру, API-интерфейсы: когда мы пишем наши API, мы ими завладеваем — каждым вызовом, каждым именем параметра. Говоря в общих чертах, люди, пишущие RDF-ПО, завладевают текстом, а не API».

Точку зрения Айфрема разделяет Пако Натан, директор группы O’Reilly Media Learning и эксперт по искусственному интеллекту (ИИ). По его словам, для ИИ-преобразований нужен лучший инструментарий, и люди, занимающиеся языком запросов SPARQL и базами данных triplestore (субъект-предикат-объект), пока еще далеки от таких вещей, как контейнеры, оркестровка, микросервисы и тому подобное.

RDF — где это подходит?

Значит, мы должны отвергнуть RDF как непрактичную модель, а RDF-хранилища как плохое ПО, написанное теоретиками, и двигаться дальше? Не будем спешить. Имеются RDF-вендоры, вполне профессионально занимающиеся своим делом, и RDF реально может предложить определенные вещи, которых нет в других графовых моделях данных.

Мы обсудили с Василом Момчевым, ответственным за разработку продукта GraphDB в компании Ontotext, плюсы и области применения RDF. В прошлом Ontotext работала над алгоритмами глубокого анализа текстов, но ныне наиболее известна своей графовой СУБД GraphDB на базе RDF.

«Наш анализ текстов поддерживается сложной семантической сетью для представления базового и извлеченного знания. Еще в 2006 г. мы выяснили, что ни одна из существовавших RDF-СУБД не удовлетворяла нашим требованиям по высоко масштабируемым базам данных. Таким образом был дан старт GraphDB», — говорит Момчев.

Он продолжает: «RDF-базы данных очень хороши для представления сложных метеданных, ссылочных данных и мастер-данных. Почти все наши клиенты используют эту технологию для представления понятий высокой сложности, где критически важны семантический контекст и качество данных.

RDF-технология очень сильна в формулировке стандартов того, как публиковать, классифицировать или сообщать информацию. Ее самой сильной функцией является способность открытым способом разделять и публиковать данные.

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

К ее типичными пользователям относятся провайдеры контента, хранящие очень ценную информацию, не имеющую сроков давности, и организации, нуждающиеся в стандартном способе публикации информационных ресурсов. Плюсами RDF могут быть более высокий уровень понятности, лучший семантический контекст, более легкое извлечение знаний и навигация».

GraphDB используют такие компании, как AstraZeneca и BBC, и выигрышными для RDF сценариями являются публикация данных и их интеграция. Но как насчет крупномасштабных транзакционных приложений реального времени?

Вот что говорит Момчев: «Масштабируемость находится в числе первых вопросов, задаваемых людьми по поводу потенциала баз данных RDF. Большинство наших заказчиков использует графы в диапазоне от 500 млн. до 1 млрд. RDF-фактов, а в самых крупных инсталляциях кластеров это число доходит до 15 млрд.

В реальном мире размеры типичных наборов данных меньше. Например, все структурированные знания Википедии составляют меньше 800 млн. фактов, и на самом деле это очень много.

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

Хотя мы поддерживаем требования ACID (атомарность, согласованность, изолированность, долговечность), движок нашей СУБД более рассчитан на крупные пакетные обновления, а не на мелкие транзакционные обновления».

Графы со схемами

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

«GraphDB можно использовать со схемой и без нее. Задание схемы дает пользователю возможность контролировать, что база данных будет выдавать как явную информацию или подтверждать в смысле ограничений на данные», — объясняет Момчев.

RDF допускает использование разных типов схем, от RDFS до OWL2. Каждая из них предлагает различные варианты компромисса между выразительностью и сложностью, от простых ограничений и наследования до описательной логики.

Некоторые RDF-хранилища, включая GraphDB, позволяют выводить новые знания из существующих фактов. По существу это умозаключения на базе правил, которые могут варьировать от простого наследования до всего, что может генерировать машина формирования умозаключений на базе OWL.

Например, если RDFS-схема содержит знание, что Persons (Люди) являются Entities (Сущности), то RDF(S)-совместимое хранилище, содержащее факт, что A есть Person, сделает вывод, что A есть Entity. При запросе к Entities в выборке будет присутствовать и A, даже если факт A есть Entity явно не содержится в базе данных.

По словам Айфрема, «наследование является примером того, как RDF-сообщество занимается не тем, что надо. Люди думают, что хорошо бы получить возможность моделировать все на свете, и начинают добавлять массу функций, в результате чего OWL-описания становятся такими сложными, что их невозможно использовать на практике. Вот почему мы так сомневаемся насчет добавления схем».

Любовь между графами

Раз уж RDF и Neo4j являются столь близкими родственниками, не разумно ли, чтобы эти два мира поддерживали взаимную связь, и, возможно, даже усваивали друг от друга некоторые функции? Однако родственные взаимоотношения зачастую бывают сложными, и, похоже, здесь имеет место то же самое, несмотря на определенные попытки сблизить два сообщества.

Такие функции, как именованные графы (возможность определять контекст для графов), выразительный язык запросов, происхождение и управление словарем, либо еще находятся в процессе обсуждения, либо добавлены в Neo4j только недавно. В мире RDF они существуют не один год.

«Мы все-таки пристально следим за RDF-сообществом в поиске идей и хотим иметь возможность легко импортировать и экспортировать RDF, — говорит Айфрем. — Здесь есть важный плюс: RDF использует URL, и наличие глобально уникального идентификатора имеет центральное значение для формата публикации. Но открыть RDF разработчикам? Категорическое нет».

Фактически, хотя это не очень выдающаяся функция, Neo4j может импортировать и экспортировать RDF-данные. Но реализовано это так, что Neo4j рассматривает RDF как еще один формат обмена данными, наподобие CSV, хотя и явно более мощный.

Но даже при том, что доступ из Neo4j к RDF является опцией, это возможно только при использовании Cypher, языка запросов Neo4j, а не SPARQL, языка запросов в составе стека RDF. Сравнение Cypher со SPARQL — тема довольно тонкая. Однако стоит отметить, что в настоящее время Cypher можно использовать только с Neo4j.

Напротив, SPARQL-адаптеры существуют для всего, от реляционных баз данных (по расширению это охватывает любые ANSI-SQL-совместимые системы, вроде озер данных Hadoop) до CSV. Это значит, что SPARQL можно использовать для интеграции многих разных хранилищ данных, а Cypher нельзя.

«Язык Cypher вызывает намного меньше разногласий, и у него есть потенциал как в смысле технологии, так и в плане продвижения на рынок. У нас был заметный интерес к интеграции с реляционными базами данных. Несколько лет назад это для нас могло иметь смысл, но сегодня Cypher интересует больше людей, чем SPARQL», — говорит Айфрем.

На конференции GraphConnect была сессия, посвященная взаимоотношениям между RDF и LPG, моделью данных Neo4j. Ее организовал бывший адепт RDF, обращенный в LPG, Джизес Барраса. Это опять-таки тонкая тема, связанная с тем, что это две разные модели графов, и прежде чем делать выбор, необходимо их исследовать.

На просьбу прокомментировать высказывания Баррасы Момчев сказал, что в целом с ним согласен, указав на различия двух моделей и пути альтернативного моделирования. Однако он довольно резко отреагировал на следующее утверждение Баррасы: «RDF-хранилища очень сильно базируются на индексах. Хранилища Neo4j — навигационные (в них используются не индексы, а смежность). Хранение информации на базе индексов подходит для не очень глубоких запросов, и при этом исключается анализ путей. Нативно графовые хранилища Neo4j являются наилучшим решением для глубоких запросов или запросов с обходами и путями переменной длины».

Вот, что об этом сказал Момчев: «С точки зрения реализации RDF-спецификация не требует создания многих индексов. Однако если вам нужны базовые заключения, типа A совпадает с B, индексы скорее всего понадобятся.

Однако это крайне сомнительное, спорное и предвзятое заявление в пользу LPG, игнорирующее тонны теоретических книг. Обычный компромисс всегда связан с соотношением производительности чтения и записи — чем больше индексов, тем медленнее запись, но быстрее чтение.

Если в Neo4j заявляют, что их хранилища лучше оптимизированы для сценариев общего назначения, я думаю, что это очень смелая гипотеза. В то же время многими разработчиками доказано, что утверждение про исключительную быстроту путевых запросов в сценариях реальной жизни является ошибочным.

Объективности ради я бы поставил вопрос иначе: хватает ли у вас контроля над индексированием, чтобы вы могли охватить и самые крайние сценарии использования? Насколько я знаю, нет — вы используете базу данных единственным образом, с той целью, с какой ее сконструировали».

Вердикт

«Наша пользовательская база в сто раз шире, чем у всех RDF-хранилищ вместе взятых, не потому, что мы такие умные, а потому что наше ПО так легко использовать». Хотя у Neo4j действительно есть недоброжелатели, похоже, данные о внедрении — частично — подтверждают эти слова Айфрема. RDF-базы данных в основном рассматриваются как нишевый рынок.

Комментарий Момчева: «Это зависит от того, как вы определяете термин „нишевый рынок“. В сравнении с другими специализированными базами данных, типа объектно-ориентированных, XML или баз данных временных рядов, я считаю, что RDF-СУБД представляют собой очень зрелый рынок с большим числом конкурентов, где каждый вендор имеет свои силы и свои слабости.

Конечно, графовые RDF-базы данных не столь вездесущи, как реляционные системы, которые по-прежнему доминируют на рынке. Главной причиной, вероятно, является лучшая предсказуемость последних в работе с более низкой степенью абстракции данных.

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

Итак, какой будет вердикт? Если вас заинтересовали графы, какой вариант графовой СУБД предпочесть? Как обычно, ответом будет «смотря по обстоятельствам». Это зависит от вашего конкретного сценария.

«Если вас заботят стандарты и то, как вы будете публиковать данные, чтобы их можно было повторно использовать в открытом формате или протоколе, с федерированием на базе SPARQL, со ссылками на открытые данные и тому подобным — выбирайте triplestore (т. е. RDF). Если вас заботит графовый анализ путей и быстрая транзакционная поддержка — вам подойдет Neo4j или другая реализация графов со свойствами», — говорит Момчев.