RDF е инструмент за неструктурирани данни

Релационният модел, който служи като основа за технологията за данни в продължение на десетилетия, вече не е доминиращ - на сцената навлизат нови задачи, които изискват отчитане и идентифициране на значително по-голям брой връзки. Сред новите методи за обработка на данни RDF моделът се откроява: преходът от SQL бази данни към RDF системи обещава технологичен скок, сравним с прехода от Cobol към SQL.

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

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

Задачата за ефективно организиране на метаданни е главоболие за дизайнерите на системи за управление на мултимедия, а когато става въпрос за динамично променящи се изисквания за модел, процесът обикновено може да стигне до задънена улица. Изходът е семантичният уеб.

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

Основата на RDF е представянето на данни под формата на изявления (тройки, тройки) субект-предикат-обект, което описва насочена връзка от субект към обект, добре позната на специалистите по изкуствен интелект. Субектите, обектите и предикатите се идентифицират с помощта на Uniform Resource Identifier (URI), който е обобщение на концепцията за URL. Например:

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

За разлика от релационния модел, който има твърда структура, RDF моделът е доста гъвкав - всеки субект може да съдържа свои собствени предикати и обекти,например в една база данни с продукти всички продукти имат предикат „Цена“, но в същото време хладилниците могат да имат предикат „Обем на фризера“, а телевизорите могат да имат предикат „Диагонал на екрана“.

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

Този пример е фрагмент от графика, която описва стандарта на грижа за дадено заболяване, включително диагноза според класификатора на ICD 10, свързани медицински услуги и лечение на наркотици.

RDF моделът по същество описва насочен граф (фиг. 1), в който всяка тройка е описание на връзка, тоест връзка между два възела.

Фиг.1. Модел на насочена графа RDF

Език за заявки

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

Тук блокът "избор" съдържа списък с променливи за показване на резултата от заявката; "?x" е променлива, която по време на търсенето ще придобие стойността на URI на намерения обект. Блокът "къде" съдържа набор от тройки, които съставят шаблона на заявката. INв резултат на търсенето ще бъде намерен подграф, който удовлетворява шаблона (фиг. 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 заявките се изпълняват еднакво в различни хранилища, което е високо оценено от разработчиците,изправен пред проблемите на прехвърляне на данни и заявки от една база данни в друга.

Все още е трудно да си представим напълно възможностите на семантичния уеб днес, както и възможностите на WWW преди петнадесет или двадесет години, но първоначално в научната среда, която е родила мрежата, тя е била ориентирана по-специално към взаимодействие с програми.

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

Основният недостатък на RDF модела в сравнение с релационния модел е може би неговата "младост". SQL има много години инсталиране и оперативен багаж зад гърба си, включително в критични приложения - функционалното богатство на такива бази данни все още значително превъзхожда RDF. Транзакционният механизъм в RDF хранилищата, като правило, ако е приложен, е доста груб.

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

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

Референтен показател на DBpedia SPARQL. Еталонният тест на DBPSB (svn.aksw.org/papers/2011/VLDB_AKSWBenchmark/public.pdf) се основава на реални заявки към базата от знания на Dbpedia. Методологията за разработване на тестове е т.нколкото оригинално, толкова и целесъобразно. Авторите анализират регистрационните файлове на реални потребителски заявки към базата данни на Dbpedia, групират ги и идентифицират най-статистически значимите групи заявки, които след това се включват в следващата версия на теста. По този начин DBPSB е тест, възможно най-близо до живота. Virtuoso изпълнява този тест най-бързо, следван от OWLIM, Sesame и Jena TDB.

Референтен показател на университета Lehigh. Тестът LUBM (swat.cse.lehigh.edu/projects/lubm/) е специално разработен за оценка на семантичните способности и следователно не е толкова често срещан като другите. Базира се на онтологична база от знания за определен университет. Резултатите от този тест са известни преди всичко за системи с инструменти за извод, като OWLIM, YarcData, Sesame и др.

Днес има бърз растеж на пазара на инструменти за разработка, базирани на RDF модела - някои инструменти имат специализирана архитектура за обработка на графики, някои са изградени върху релационни бази данни.

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

Ontotext OWLIM е семейство от семантични хранилища или RDF DBMS със собствено ядро, реализирано в Java, с поддръжка на семантика на RDFS (RDF схема) и 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 DBMS вариант на RDF модела, наречен NoSQL Graph Support, с интерфейс, базиран на Jena API разширението. Характеризира се с висока производителност на RDF операции. Oracle свърза RDF със своя продукт за пространствени данни, опцията за пространствени данни, сега наричана опция за пространствени и графични данни.

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

След статията на Тим Бърнърс Лий моделът RDF стана силно свързан със семантичната мрежа в общественото съзнание, но потенциалът на този модел е много по-голям. Например повечето задачиднес в рамките на релационния модел е лесно да се реши в RDF. В допълнение, RDF хранилищата ви позволяват да събирате, съхранявате и индексирате данни от различни източници - по-специално, когато решавате действителната задача за интегриране на услуги, която се свежда до комбиниране на различни релационни бази данни в една база данни и води до задачата за обработка на квазиструктурирани данни. Данните във всяка от базите данни са строго структурирани, за да работят с релационния модел, но всяка база данни е структурирана по свой начин, така че задачата за интегрирането им в рамките на релационния модел изисква реинженеринг на цялото решение. Ако обаче такива бази данни се преобразуват в RDF модел, тогава интеграцията ще се сведе до просто сливане на RDF графики и пренаписване на заявки от SQL към SPARQL, което не е трудно поради много по-голямата изразителност на SPARQL в сравнение с SQL.

RDF хранилищата са идеални за задачи, които изискват отчитане и идентифициране на голям брой връзки. В допълнение към най-широко обявените задачи, свързани с развитието на семантичния уеб, има голям брой класически задачи, които изискват използването на графични подходи:

Почти всички проблеми, при които броят на връзките между обекти надвишава броя на обектите или чиято основна цел е да анализират връзки, могат да се считат за кандидати за решаване с помощта на RDF системи.

Владислав Головков ([email protected]),Андрей Портнов ([email protected]),Виктор Чернов ([email protected]) са служители на Compile Group (Москва).

Споделяйте материал с колеги и приятели