RDF — инструмент для неструктурированных данных

До сих пор наиболее распространенной моделью хранения данных была реляционная, которая с конца 70-х годов и поныне является стандартом де-факто на хранение структурированных данных, а язык SQL — стандартом на их обработку. Однако  доля  структурированных данных становится все меньше, и реляционная модель испытывает все больше проблем при работе со значительными объемами данных — давно, например, была замечена деградация производительности реляционных СУБД при решении задач аналитической обработки, характерными чертами которых являются «длинные» SQL-запросы, работающие с несколькими таблицами при наличии большого числа агрегатов.

Сегодня задачи, выходящие за рамки реляционной модели, принято относить к классу NoSQL, каждый подкласс которого решает ту или иную проблему, плохо реализуемую с помощью SQL, — например, базы данных с поколоночным хранением, документо-ориентированные, графовые, базы данных ключ-значение и объектные. Скажем, базы данных ключ-значение применяются для задач, характеризующихся чрезвычайно большими объемами, отсутствием операций join и ограниченными требованиями к обновлению данных (например, только добавление). В силу своего объема такие базы заведомо распределенные, что, в свою очередь, означает полный отказ от транзакций — такая упрощенная модель данных дает новые возможности повышения производительности за счет широкого использования параллельных архитектур.

Еще один класс задач, трудно решаемых на реляционной модели, — это задачи на сильно связанных данных или графовые задачи. Попытки решения таких задач на реляционной модели приводят к непредсказуемому количеству соединений в запросах, поэтому для решения графовых задач сегодня наибольшее распространение получили RDF-хранилища, главным достоинством которых является наличие хорошо проработанных стандартов комитета W3C на язык описания графов (Resource Description Framework, RDF) и на обработку графовых данных (SPARQL — рекурсивный акроним: SPARQL Protocol And Rdf Query Language).

Модель RDF возникла в конце 90-х годов, а в 2001 году в журнале Scientific American была опубликована знаменитая статья Тима Бернерса Ли, провозглашающая приход эры семантической паутины (Semantic Web). С той поры в сетевом сообществе стал лавинообразно нарастать интерес ко всему, что связано с семантической обработкой, в том числе и к RDF, который в 2004 году был принят как стандарт комитета W3C.

Основа RDF — это хорошо известное специалистам по искусственному интеллекту представление данных в виде утверждений (троек, triples) субъект-предикат-объект, описывающих направленную связь от субъекта к объекту. Для идентификации субъектов, объектов и предикатов используется идентификатор Uniform Resource Identifier (URI), являющийся обобщением понятия URL. Например:

субъект/объект:

Предикат:

Объекты, кроме URI, могут быть представлены также литералами, например, название журнала: «Journal 1 (1940)»^^xsd:string.

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

Наиболее известные форматы представления RDF — текстовые файлы XML, JSON, N-Triples, N3 и Turtle. Например, представление некоторых данных в формате Turtle:

@prefix xsd: .

@prefix f: .



xsd:type ;

f:name «Стандарт специализированной медицинской помощи детям с галактоземией»;

f:mkb ;

f:service , ;

f:drug ;



xsd:type ;

f:name «Оптиконевромиелит [болезнь Девика]»;



xsd:type ;

f:name «Общее нейропсихологическое обследование»;



xsd:type ;

f:name «Актовегин»;

Данный пример представляет фрагмент графа, описывающего стандарт медицинской помощи при заболевании, включая диагноз по классификатору МКБ 10, связанные с ним медицинские услуги и медикаментозное лечение.

Модель RDF по существу описывает ориентированный граф (рис.1), в котором каждая тройка — это описание отношения, то есть связи между двумя узлами.

Рис.1. Ориентированный граф модели RDF

Язык запросов

Модель RDF служит для описания данных, но не описывает методов их обработки. Существует целый ряд языков запросов к RDF-данным: DQL, N3QL, R-DEVICE, RDFQ, RDQ, RDQL, SeRQL и т. д., но самым популярным стал SPARQL, принятый в качестве стандарта W3C. Язык SPARQL, в отличие от SQL (который критикуют, в частности, за отсутствие кросс-платформности, проблемы с обработкой отсутствующих данных, неоднозначную грамматику и семантику), обладает более стройной структурой и мощью. Основная часть запроса на SPARQL — шаблон, описывающий подграф, который требуется найти в общем графе. Шаблон представляется в виде набора троек с переменными — например, запрос на поиск в некотором графе человека по имени Петр:

select? x

where {? x: тип: человек.

? x: имя «Петр»

}

Здесь Блок «select» содержит список переменных для вывода результата запроса; «?x» — это переменная, которая в момент поиска приобретет значение URI найденного объекта. Блок «where» содержит набор троек, составляющих шаблон запроса. В результате поиска будет найден подграф, удовлетворяющий шаблону (рис. 2).

Рис. 2. Пример результата по запросу

Язык SPARQL прост в освоении для человека, знакомого с SQL, — многое в SPARQL ему покажется известным. Например, в языке присутствуют такие конструкции, как UNION, ORDER BY, GROUP BY, DISTINCT, OFFSET и LIMIT. На сегодняшний день SPARQL является одним из самых выразительных языков обработки данных. Кроме языка запросов, стандарт SPARQL регламентирует протокол взаимодействия с базой данных и формат результата, что является большим шагом вперед по сравнению с SQL.

Вместе с достоинствами модель RDF и язык SPARQL имеют и недостатки. Начнем с достоинств.

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

Современная архитектура. Запросы к хранилищу RDF обычно совершаются с помощью протокола HTTP, благодаря чему они легко встраиваются в сервисные архитектуры без построения промежуточных слоев, потери надежности и производительности. RDF и SPARQL лучше работают с интернациональным контентом, чем базы SQL.

Стандартизация. Уровень стандартизации RDF и SPARQL гораздо выше, чем в SQL, — усилиями комитета W3C определены стандарты не только на модель RDF и язык SPARQL, но и на идентификацию ресурсов (URI), протокол взаимодействия компонентов (HTTP), точку доступа SPARQL и т. д. Благодаря стандартизации, данные, выгруженные из любого RDF-хранилища, можно загружать в RDF-хранилища различных производителей. Запросы на SPARQL одинаково выполняются на разных хранилищах, что высоко ценят разработчики, сталкивающиеся с проблемами переноса данных и запросов из одной базы в другую.

Метаданные. SPARQL позволяет легко отследить происхождение любых единиц данных. В RDF легко хранить самые разные метаданные. На основе метаданных можно делать сложные запросы, выбирая, скажем, данные из конкретных источников, в конкретном временном диапазоне и т. д.

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

Инструментарий RDF

Почти все производители реляционных СУБД избегают широкой огласки результатов тестов конфигураций, построенных на том или ином инструментарии SQL, и единственным открытым источником являются тесты TPC для дорогих высокопроизводительных систем, решающих ограниченный класс задач. Мир систем RDF открыт для исследований, экспериментов и тестов — легко можно найти результаты тестов на разных задачах, на компьютерах разной мощности и архитектуры, а главное, подобрать наиболее подходящий для решения конкретной прикладной задачи инструментарий работы с моделью RDF.

Berlin SPARQL Benchmark (BSBM). Тест (www4.wiwiss.fu-berlin.de/bizer/berlinsparqlbenchmark) моделирует данные, связанные с электронной коммерцией, включая товары от разных производителей, отзывы покупателей о товарах и т. д. Данный тест предназначен для оценки скорости выполнения SPARQL-запросов. Модель приближена к реляционной, поэтому есть возможность оценить, насколько эффективна была бы замена базы данных SQL на RDF-хранилище. Модель и запросы теста весьма продуманны и приближены к практике. Возможно, поэтому BSBM — один из наиболее популярных тестов. В опубликованных на сайте разработчиков теста результатах за февраль 2011 года лидером являются такие средства разработки для RDF, как Virtuoso, 4Store, OWLIM и Jena TDB.

SP²Bench SPARQL Performance Benchmark. Тест (dbis.informatik.uni-freiburg.de/index.php?project=SP2B) построен на модели известной библиотеки DBLP литературы по логическому программированию (DataBase systems and Logic Programming): публикации, статьи, журналы, книги и т. д. Так же, как и BSBM, данный тест разработан для оценки скорости выполнения SPARQL-запросов, однако он использует более изощренные запросы, в ущерб их реалистичности. Данный тест хорош для тестирования оптимизатора запросов, поскольку содержит много сложных операций объединения. В опубликованных результатах места распределились следующим образом: Virtuoso, Sesame, ARQ. Недавно проведенное нами сравнительное тестирование сервера RDF NitrosBase Storage на тестах SP2Bench показало его значительное превосходство в производительности перед Virtuoso (от 10 до 10 тысяч раз в зависимости от запроса).

DBpedia SPARQL Benchmark. Тест DBPSB (svn.aksw.org/papers/2011/VLDB_AKSWBenchmark/public.pdf) основан на реальных запросах к базе знаний Dbpedia. Методика разработки теста настолько же оригинальна, насколько целесообразна. Авторы анализируют логи реальных обращений пользователей к базе Dbpedia, кластеризуют их и выделяют наиболее статистически значимые группы запросов, которые затем вносятся в очередную версию теста. Таким образом, DBPSB — это максимально приближенный к жизни тест. Наиболее быстро этот тест выполняет Virtuoso, затем идут OWLIM, Sesame и Jena TDB.

Lehigh University Benchmark. Тест LUBM (swat.cse.lehigh.edu/projects/lubm/) специально разработан для оценки семантических возможностей, поэтому не так распространен, как другие. Основан он на онтологической базе знаний о некотором университете. Известны результаты этого теста, прежде всего, для систем со средствами логического вывода, такими как OWLIM, YarcData, Sesame и др.

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

Apache Jena — Java API для разработки приложений Semantic Web. Продукт включает в себя несколько хранилищ, собственное хранилище троек (Jena TDB), интерфейс к реляционному хранилищу (Jena SDB), хранилище в памяти (In-Memory), а также средства для поддержки собственных хранилищ. Наиболее сильная сторона Jena — богатый программный интерфейс. Многие RDF-хранилища используют Jena API для доступа к собственным СУБД (IBM, OWLIM и т. д.). Слабой стороной является низкая производительность даже на родном хранилище.

Ontotext OWLIM — семейство семантических репозиториев или RDF СУБД с собственным ядром, реализованным на Java, с поддержкой семантики на RDFS (RDF Scheme) и OWL. Продукт OWLIM активно используется в научно-исследовательских проектах и программных системах. Выпускается в следующих редакциях: OWLIM-Lite для приложений, поддерживающих менее 100 млн троек; OWLIM-SE (ранее BigOWLIM) предназначен для обработки больших объемов данных, с большими потоками запросов; OWLIM-Enterprise (ранее BigOWLIM Replication Cluster) предназначен для построения масштабируемых производительных надежных решений, основанных на параллельной обработке и имеющих средства автоматической защиты от сбоев.

OpenLink Software Virtuoso — обладает собственным мощным RDF-хранилищем, полной реализацией SPARQL, возможностью чтения данных RDF из файлов формата XML и Turtle. Кроме того, поддерживается SPARQL/Update (SPARUL) — расширение SPARQL для поддержки обновления данных. Продукт является одним из лидеров по производительности.

Крупные корпорации, такие как IBM и Oracle, также разрабатывают собственные RDF-решения. Первая встроила в очередную версию СУБД DB2 вариант модели RDF, имеющий название NoSQL Graph Support, с интерфейсом на основе расширения API Jena. Отличается высокой производительностью выполнения RDF-операций. Компания Oracle подключила RDF к своему продукту для работы с пространственными данными — Spatial Data Option, который теперь называется Spatial and Graph Option.

Кроме того, разрабатываются специализированные компьютеры, ориентированные на работу с графовой информацией и поддерживающие модель RDF. Например, в начале 2012 года компания Cray объявила о создании нового высокопроизводительного программно-аппаратного комплекса uRiKA (universal RDF integration Knowledge Appliance), ориентированного на рынок семантических баз данных.

Задачи

После статьи Тима Бернерса Ли в общественном сознании модель RDF стала прочно ассоциироваться с семантической паутиной, однако потенциал этой модели намного выше. Например, большинство задач, решаемых сегодня в рамках реляционной модели, легко можно решать и на RDF. Кроме того, RDF-хранилища позволяют собирать, хранить и индексировать данные из различных источников — в частности, при решении актуальной задачи интеграции сервисов, которая сводится к объединению разрозненных реляционных баз в единую базу и приводит к задаче обработки квазиструктурированных данных. Данные внутри каждой из баз строго структурированы для работы с реляционной моделью, но каждая база структурирована по-своему, поэтому задача их интеграции в рамках реляционной модели требует реинжиниринга всего решения. Если же конвертировать такие базы в модель RDF, то интеграция сведется к простому слиянию RDF-графов и переписыванию запросов из SQL в SPARQL, что не составляет труда в силу гораздо большей выразительности SPARQL по сравнению с SQL.

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

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

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

Владислав Головков (vgolovkov@nitrosbase.com), Андрей Портнов (aportnov@nitrosbase.com), Виктор Чернов (vc@nitrosbase.com) — сотрудники компании «Компайл Груп» (Москва).