что такое графовая модель данных

Что такое графовая БД?

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

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

Ниже приведен пример графа социальной сети. Имея данные о людях (узлы) и взаимосвязях между ними (ребра), можно узнать, кто является «друзьями друзей» конкретного человека (например, пользователя по имени Howard).

Примеры использования

Выявление мошенничества

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

Сервисы рекомендаций

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

Графовые базы данных на AWS

Amazon Neptune

В основе Amazon Neptune лежит специально созданное высокопроизводительное ядро графовой базы данных, оптимизированное для хранения миллиардов взаимосвязей и выполнения запросов к графу с задержками на уровне миллисекунд. Neptune поддерживает популярные модели графов Property Graph и Resource Description Framework (RDF) консорциума W3C, а также соответствующие языки запросов – Apache TinkerPop Gremlin и SPARQL, что позволяет просто создавать запросы для эффективной навигации по наборам сложносвязанных данных.

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

Источник

Графовые базы данных

Светлана Комарова

Автор статьи. Системный администратор, Oracle DBA. Информационные технологии, интернет, телеком. Подробнее.

Система управления графовыми базами данных (далее графовые базы данных) поддерживает методы создания ( Create ), чтения ( Read ), изменения ( Update ) и удаления ( Delete ) (CRUD), основан­ные на графовой модели данных. Графовые базы данных, как прави­ло, поддерживают систему транзакций реального времени (OLTP). Соответственно, они оптимизированы для выполнения транзакций и спроектированы с учетом транзакционной целостности и опера­тивности.

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

Взаимосвязи в графовой модели данных являются гражданами первого сорта. Здесь к ним относятся не так, как в других системах управления базами данных, где для отображения взаимосвязей при­меняются такие механизмы, как внешние ключи или внешние опера­ции, например MapReduce. Собирая абстракции узлов и взаимосвя­зей в связанные структуры, графовая база данных позволяет строить модели любой сложности, лучше всего отражающие предметную об­ласть. Полученные модели проще и в то же время нагляднее, чем те, что создаются с помощью традиционных реляционных баз данных или других NOSQL-хранилищ.

На рис. 1 приведен графический обзор некоторых графовых баз данных из представленных сегодня на рынке, основанных на разных моделях хранения и обработки.

Рис. 1. Обзор графовых баз данных

Механизмы вычисления графов

Механизмы вычисления графов позволяют выполнять глобальные графовые вычислительные алгоритмы для больших наборов дан­ных. Они предназначены для решения таких задач, как идентифи­кация кластеров данных или получение ответов на такие вопросы, как: «Сколько всего взаимосвязей, сколько их в среднем, полна ли социальная сеть?»

Из-за своей направленности на глобальные запросы механизмы вычисления графов, как правило, оптимизированы для сканирования и пакетной обработки больших объемов информации, и в этом отно­шении они похожи на другие технологии пакетного анализа, такие как интеллектуальный анализ данных (data mining) или аналитиче­ская обработка в реальном времени (OLAP), используемые в реля­ционном мире. Некоторые механизмы вычисления включают в себя и средства хранения графов, а другие (большинство) заботятся толь­ко об обработке данных, получаемых из внешнего источника, а затем возвращают результаты для сохранения в другом месте.

Рисунок 2 иллюстрирует типовую архитектуру развертывания механизмов вычисления графов. Она включает в себя систему записи (System of Record, SOR) базы данных со свойствами OLTP (напри­мер, MySQL, Oracle или Neo4j), которая обслуживает запросы и от­вечает на запросы, поступающие от приложений (и в конечном счете от пользователей). Периодически задания на извлечение, преобразо­вание и загрузку данных (Extract, Transform, Load, ETL) перемещают данные из системы записи базы данных в механизм вычисления гра­фов для выполнения автономных запросов и анализа.

Рис. 2. Укрупненная схема типичной среды движков расчетов графов

Существуют разные типы механизмов вычисления графов. Наи­более известными из них являются одномашинные (in-memory/single machin), такие как Cassovary, и распределенные, такие как Pegasus и Giraph. В основе большинства распре­деленных механизмов вычисления графов лежит идея, изложенная в статье «Pregel: a system for large-scale graph processing», опублико­ванной на сайте Google, ко­торая описывает движок Google для классификации страниц.

Преимущества графовых баз данных

Производительность

Одной из веских причин выбора графовой базы данных является большой прирост производительности при работе со взаимосвя­занными данными, по сравнению с реляционными базами данных и NOSQL-хранилищами. В отличие от реляционных баз данных, где учет взаимосвязей интенсивно ухудшает производительность запро­сов на больших наборах данных, производительность графовых баз данных остается неизменной с увеличением объема хранимых дан­ных. Это связано с тем, что запросы локализуются в определенной части графа. В результате время выполнения каждого запроса зави­сит от размера части графа, которую требуется обойти для удовле­творения запроса, а не от общего размера графа.

Гибкость

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

Присущая графам возможность расширения означает, что мож­но добавлять новые виды взаимосвязей, новые узлы, новые метки и новые подграфы в существующую структуру, не нарушив при этом существующих запросов и функционала приложения. Это положи­тельно влияет на производительность разработки и снижает риски для проекта. Благодаря гибкости графовой модели не требуется предварительно моделировать задачу в мельчайших подробностях, что очень неудобно из-за быстро меняющихся бизнес-требований. Способность графов к расширению также позволяет уменьшить количество миграций, что снижает нагрузку при обслуживании данных и уменьшает риск потери данных.

Оперативность

Модель данных должна не отставать от прочих составных частей при­ложения и использовать технологии, соответствующие современным итерационным методам развертывания программного обеспечения. Современные графовые базы данных оснащены всем необходимым для разработки и системного обслуживания. В частности, встроенная графовая модель данных, лишенная схем, в сочетании со встроенным программным интерфейсом (API) и языком запросов позволяет эф­фективно вести разработку приложений.

В то же время благодаря отсутствию схемы графовые базы данных не предполагают наличия ориентированных на схемы механизмов контроля данных, которые широко применяются в реляционном мире. Но в этом нет ничего страшного, здесь они заменены гораздо более удобными и действенными видами контроля. Как мы увидим в главе 4, контроль выполняется в программной форме, с помощью тестов для моделей данных и запросов, а также с помощью определения бизнес­правил, основанных на графе. Сейчас такая методика уже не вызывает сомнений: разработка с помощью графовых баз данных полностью соответствует современным методикам гибкой и надежной разработ­ки программного обеспечения, что позволяет разработке приложений с использованием графовых баз данных не отставать от бизнес-среды.

Итоги

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

В следующем моем блоге мы сравним несколько различных технологий обработки взаимосвязанных данных, начнем с реляционных баз дан­ных, затем перейдем к агрегированным NOSQL-хранилищам и за­кончим графовыми базами данных. Обсудив их, мы узнаем, почему графы и графовые базы данных являются лучшим средством для мо­делирования, хранения и выборки взаимосвязанных данных. Затем, в последующих главах, будут описаны проектирование и реализация решений, основывающихся на графовых базах данных.

Источник

Знакомство с графовой базой данных Neo4j

Mar 15, 2019 · 6 min read

Содержание

История происхождения графов

Среди жителей Кёнигсберга (нынешний Калиниград) была распространена такая загадка: как пройти по всем городским мостам через реку, не проходя ни по одному из них дважды. Многие пытались решить эту задачу как теоретически, так и практически, во время прогулок. Впрочем, доказать или опровергнуть возможность существования такого маршрута никто не мог.

Решил задачку Леонард Эйлер, сформулировав ряд правил и доказав, что пройти по мостам, не повторяясь, невозможно.

Так и зародилась теория графов.

Что такое граф?

Граф — абстрактный математический объект, представляющий собой множество вершин (точек) и набор рёбер (линий ), то есть соединений между парами вершин.

Ориентированный граф

Ориентиров а нный граф — это граф, ребро которого имеет заданное направление между вершинами.

Петля

Если вершина графа соединена ребром сама с собой, то такое ребро называется петлей.

Классификация графов

Связанный граф

Если из любой вершины есть путь до любой другой — такой граф называется связанным.

В данном примере есть путь от вершины А до вершины D, хоть он и пролегает через другие вершины.

Сильно связанный граф

Граф называется сильно связанным, если любая его вершина соединена с любой другой ребром. Если связи ориентированные — то граф называется ориентированно связанным.

Взвешенный граф

Если к каждому ребру в соответствие поставлено некоторое число (вес ребра) — такой граф называется взвешенным.

Мультиграф

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

Где используются графы

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

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

По весам ребер можно посчитать время в пути, так же и выбрать оптимальный путь с помощью какого-либо алгоритма. Алгоритмов поиска кратчайшего пути в графе много, самый известный — алгоритм Дейкстры, вы наверняка о нем слышали.

Карту города тоже можно представить в виде графа.

Данный граф применим в системах навигации для поиска оптимального маршрута. Перекрестки — вершины графа, а дороги — ребра.

Молекулярный граф — связный неориентированный граф, соответсвует формуле химического соединения таким образом, что вершины графа — атомы молекулы, а ребра — химические связи между этими атомами.

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

Даже 3D-объект можно представить в виде графа:

Каждая вершина хранит координаты x, y, z.

Граф — довольно абстрактная вещь, поэтому ее можно применить практически во всех сферах жизни.

Графовые базы

Первая графовая СУБД Neo4j создана в 2007 году, сейчас их уже десятки, наиболее популярные:

Neo4j

Графовая СУБД с открытым исходным кодом, реализована на Java компанией Neo Technology.

Не уступает по производительности реляционным базам данных благодаря собственному формату хранения данных.

Приложение может взаимодействовать с БД по одному из протоколов:

Продолжим знакомство с Neo4j на примере стандартной БД “Movie”

Пользователь может просматривать БД с помощью Neo4j Browser

Вершины графа в Neo4j имеют свой тип, в БД Movie у нас 2 типа вершин:
* Person (name — имя актера, born — год рождения)
* Movie (title — наименование фильма, released — год выхода)

Если проводить аналогию с реляционными базами, то Person и Movie — это таблицы.

Для работы с БД используется язык запросов Cypher.

Cypher

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

Для начала найдем актера с именем Том Хэнкс

MATCH — аналог WHERE, в круглых скобках мы описываем свойства вершины (условие поиска), а RETURN — аналог SELECT, в нем мы описываем, что вернуть.

Теперь поищем фильмы, в которых снимался Том Хэнкс.

Запрос усложнился, в MATCH мы описали вершины обоих типов, и отношение между ними (ребро) в квадратных скобках.

Теперь посмотрим, кто снимался с Томом на одной площадке, и в каком фильме:

Текст запроса приближен к текстовому отображению графа:

Где и когда использовать графовые СУБД

Графовые базы уже нашли применение в:

Если в вашем приложении планируется много сущностей и связей многие-ко-многим, то это один из признаков, что предпочтительней выбрать графовую СУБД (утверждение Martin Kleppmann’а в книге “Designing Data Intensive Applications”).

А если у вас уже есть приложение с множеством связей, и обход этих связей занимает много времени и ресурсов — стоит присмотреться в сторону графов, т.к. обход связей в них практически ничего не стоит.

Выводы

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

Например, площадка medium использует Neo4j для хранения отношений между различными сущностями (Стек, который позволил Medium обеспечить чтение на 2.6 тысячелетия), а данные хранит в NoSQL БД dynamoDB.

Если вас заинтересовали графовые базы, то на официальном сайте Neo4j можно скачать БЕСПЛАТНО книгу с осьминогом, в ней больше информации про внутреннее устройство Neo4j и Cypher.

Источник

База данных, модель данных

Что такое информационные технологии? В первую очередь их можно подразделить на технологии обработки, технологии передачи и технологии хранения информации. Ниже речь пойдет о центральном понятии технологий хранения — базах данных.

Прообразы того, что сейчас называется базами данных, существовали и в докомпьютерную эпоху. Ими были библиотечные каталоги, телефонные и бухгалтерские книги и т. д. C появлением компьютеров все эти данные стали переносить в них, так появились первые компьютерные базы данных. Поначалу это были просто файлы, но со временем выяснилось, что с ростом объема данных, разнообразия и сложности задач становится необходимой специальная организация данных. Например, требуются индексы – специальные структуры, позволяющие в большой базе быстро находить нужные записи.

Базы данных в современном понимании появились в середине 60-х годов. В настоящее время их так или иначе используют практически все программные системы. Например, база данных системы управления предприятием может хранить сведения о следующих взаимосвязанных объектах:

Из приведенного примера понятно, насколько важны при хранении сведений об объектах связи между ними. Поэтому неудивительно, что первыми моделями данных (и, соответственно, базами данных) были следующие.

Иерархическая. Это наиболее естественная модель для отражения взаимосвязей в организациях и других иерархически организованных структурах.

Сетевая. Для ряда задач иерархическая модель слишком жестка, необходимо ее расширение. Например, если одна и та же деталь входит в несколько узлов, в иерархической модели данных это отражено быть не может.

Для управления базами данных используется специальные программные утилиты, получившие название систем управления базами данных (СУБД). Базы данных и СУБД часто путают, называя «базами данных» и то, и другое. Поэтому нелишне еще раз отметить:

База данных (БД) – это собственно данные в удобном для их хранения и обработки формате;

Система управления базами данных (СУБД) – это программа, которая умеет, с одной стороны, получать от пользователя или пользовательского приложения запросы на добавление, поиск и модификацию данных, с другой стороны, по запросам пользователя эти данные в базах искать, добавлять, извлекать, удалять, модифицировать.

Одна СУБД может управлять несколькими базами данных, и можно сказать, что у каждой СУБД свой формат баз данных.

Функциями СУБД являются также создание индексов, поддержка транзакций, обеспечение целостности данных, резервное копирование и восстановление, защита от сбоев и пр.

Как видно из рисунка, любая база данных управляется СУБД, доступна через СУБД, и только через СУБД. То есть, база данных и СУБД – это единый организм, одно без другого не существует.

Реляционная модель

В числе первых моделей данных, описанных выше, отсутствует самая, возможно, простая и базовая модель, возникшая даже раньше других, но долго не имевшая общепринятого названия. Иногда ее называли линейной, иногда табличной. Суть ее заключается в простом последовательном расположении сведений об объектах. Например, на рисунке ниже каждая строка представляет собой запись сведений об одном объекте, и эти записи расположены последовательно (линейно).

Такую модель можно рассматривать как вырожденную иерархическую или сетевую. Однако именно она впоследствии развилась в ставшую широко известной реляционную модель Кодда. В начале 70-х Эдгар Кодд [1] строго описал реляционную модель на основе разработанных им реляционной алгебры и реляционного исчисления.

Реляционная модель быстро завоевала популярность и стала использоваться повсеместно, отчасти в связи с тем, что в то время большая часть данных была слабо связанной и для большинства приложений было достаточно отдельных таблиц.

Однако иногда необходимо было связывать данные. В рамках реляционной модели это делалось довольно неудобным способом, и, что хуже, поиск по таким связям (операции соединения таблиц, JOIN), был очень медленным.

Производительность деградировала тем быстрее, чем больше соединяемых таблиц было задействовано в одном запросе. Например, если из базы данных, схема которой представлена на рисунке выше, требуется получить информацию о всех людях, имеющих автомобиль марки Toyota (одна операция JOIN), поиск будет достаточно быстрым. Однако если требуется получить информацию о всех людях, имеющих автомобили марки Toyota, ремонтировавшиеся в фирменных автосервисах, находящихся в определенном городе (четыре операции JOIN), скорость поиска будет намного ниже.

На рисунке выше видно, что рост времени поиска данных в реляционных базах данных в зависимости от количества операций JOIN может быть экспоненциальным.

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

Стандартизация реляционной модели, SQL

Большим достижением создателей реляционной модели явилась её стандартизация.

Были стандартизованы основные понятия и терминология, был разработан мощный язык запросов – Structured Query Language (SQL), на котором можно было выразить практически любое действие над базой данных. Поэтому реляционные СУБД часто называют SQL СУБД.

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

По-видимому, именно эта стандартизованность явилась основным конкурентным преимущество реляционных СУБД. Для сравнения, объектным СУБД, развивавшимся в то же время, и обладавшим рядом архитектурных преимуществ, но так и оставшимся проприетарными в части, например, языков запросов, так и не удалось занять сколь-нибудь значительную долю рынка.

NoSQL, графовые базы данных

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

Развитие бизнеса в эпоху Internet привело не только к значительному увеличению объемов данных, но и существенному их усложнению. Можно сказать, что реляционные СУБД просто перестали справляться. Разочарование в реляционной модели привело к появлению альтернативных моделей, учитывающих новые реалии. Стали появляться и активно развиваться СУБД, основанные на модели ключ-значение, документные, колоночные и, наконец, графовые. Эти модели получили общее название NoSQL.

Среди всех NoSQL-моделей, по нашему мнению, наибольший интерес сегодня представляет графовая модель данных. Почему?

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

Во-вторых, наше время характеризуется ростом связности данных.

В-третьих, в начале XXI века Internet сообщество взяло курс на построение Semantic Web (Web 3.0) [2]. Напомним вкратце, что

Указанная тенденция выглядит достаточно долговременной. Так, в 2018 году аналитическое агентство Gartner в своем «Hype Cycle for Emerging Technologies» [3] указало на «Knowledge Graphs» как на восходящий тренд, и в 2019 году в «Technology Trends for 2019» «Graphs» по-прежнему сохраняют свое место.

Модели графовых СУБД. RDF, SPARQL

Существует две основных разновидности графовой модели данных: Property Graph и RDF-граф (RDF — Resource Description Framework).

Property Graph (пример его приведен на рисунке ниже) – это ориентированный граф, в котором вершины соответствуют «записям», а ребра — «связям» между ними. Дополнительно и ребра, и связи могут быть снабжены скалярными атрибутами.

Наиболее известной СУБД, работающей с моделью Property Graph, является Neo4j. В основном, СУБД, работающие с Property Graph, имеют проприетарные интерфейсы и несовместимы друг с другом.

Модель данных RDF еще раньше развивалась в недрах науки искусственного интеллекта (ИИ) как один из способов представления знаний. После 2001 года, когда в журнале Scientific American была опубликована статья [2] знаменитого Тима Бернерса Ли (автора идеи всемирной паутины – World Wide Web), в Internet сообществе стал лавинообразно нарастать интерес к графовым базам, в частности, RDF. В 2004 г. RDF принят как стандарт комитета W3C (World Wide Web Consortium).

RDF – это формат задания графа, представленный в виде троек «субъект – предикат – объект».

Пример на рисунке ниже показывает тройки, определяющие человека по имени Петр Иванов как автора некоторой статьи в журнале «Вопросы биологии».

RDF тройки по несложным правилам логически могут быть «упакованы» в граф, изображенный на рисунке ниже.

На графе, заданном таким образом, можно делать запросы с помощью специальных языков. Наиболее известный из них — язык, принятый в качестве стандарта W3C –SPARQL. Его синтаксис похож на SQL, язык SPARQL, как и SQL, имеет декларативную основу.

Например, на графе, фрагмент которого представлен на рисунке выше, можно с помощью SPARQL запроса найти всех авторов, печатавшихся в издательстве «Вопросы биологии», или, например, найти в каких издательствах печатался автор Петр Иванов, родившийся 29 июля 1983 г. и т.д., и т.п.

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

Стандартизация RDF

Поскольку RDF вышел из ИИ, то он приспособлен для задач обработки знаний. Хотя, строго говоря, RDF – это информационная модель, она не достаточна для построения семантических систем. Зато модель RDF легкая и стройная, и пригодна для решения широкого круга задач, не только в рамках Semantic Web, но и в других прикладных областях. Для семантической обработки имеются стандартные расширения, совместимые с RDF, также принятые консорциумом W3C.

Благодаря усилиям консорциума W3C модель RDF удалось сделать гораздо более стандартизованной, чем это было достигнуто для реляционной модели.

Переход от SQL баз данных к RDF системам обещает такой же технологический скачок, как переход от самых первых СУБД к SQL.

Применения графовых СУБД

Можно выделить несколько направлений, в которых применение графовых СУБД наиболее эффективно.

Государственный сектор

Управление процессами, документооборот, аналитика, социологические исследования, и т.д. Клиентами могут быть федеральные и региональные министерства, исследовательские организации, и т.д.

Жизненный цикл предприятий

Интеграция и управление жизненным циклом предприятий в системах автоматизации предприятий. Применение графовых технологий дает возможность единообразно хранить и обрабатывать очень разнородную информацию, включая данные систем ERP, EAM, PLM, САПР и т.д. Клиенты – компании, переходящие на ISO 15926 и другие стандарты на основе RDF, например, Bentley, Siemens, OAK, OCK, Росатом, Роснефть, РАО ЕЭС и т.д.

Маркетинг, реклама, PR

Сбор и анализ разнородной информации из блогов, соц. сетей и т.д. для выявления источников информации, предпочтений пользователей; программы лояльности; SEO и т. д.

Единая база событий, фактов, компаний, предприятий, журналистов, изданий, статей, сообщений и т.д.

Оборона

АСУ вооруженными силами; системы распределения военной информации; системы планирования войсковых операций; системы анализа и поддержки принятия решений на ТВД; средства автоматизации процессов боевого информационного обеспечения и управления войсками; тренажерные системы; и т.д.

Безопасность

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

Бизнес-аналитика

Построение аналитических систем нового поколения; построение систем Semantic Data Warehouse — нового класса хранилищ, использующего взаимосвязи данных для повышения качества принятия решений. Клиенты – государственный сектор, банки, предприятия, корпорации, страховые компании и т.д.

Управление сетями и дата-центрами

Управление жизненным циклом вычислительных комплексов, дата-центров, компьютерных и телекоммуникационных сетей и т.д.; моделирование и оптимизация взаимодействия физического, сетевого и других. уровней. Возможные клиенты – дата-центры, Internet провайдеры, службы коммуникаций и кибербезопасности.

Социальные приложения, рекомендационные сервисы и коммерция

Построение и анализ социальных графов. Применение графовых подходов позволяет выявлять модели аналогичного поведения, групп влияния, неявных групп, и т.д. Возможные клиенты: Компании-разработчики Web-сервисов для более тонкого учета предпочтений клиентов; разработчики приложений для мобильных устройств, Интернет-торговли, форумов и социальных сетей.

Образование

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

Геосервисы, геоприложения

Построение взаимосвязей разнородных данных на карте, связанной с людьми, местами и событиями, компаниями, предприятиями и т.д.; решение задач логистики, маршрутизации и т.д. Возможные клиенты –Министерство обороны, МЧС, другие министерства, разработчики социальных приложений и т.д.

Проблемы графовых СУБД

Графовые СУБД в силу своей гибкости и универсальности завоевывает все большее место на рынке. Но широкому их распространению по-прежнему мешает проблема их сравнительно низкой производительности на простых запросах, а именно:

Таким образом, получается, что графовые СУБД проявляют свои преимущества только при большом количестве связей. Но для типовых современных приложений характерно кол-во связей (операций JOIN в терминах SQL баз) от 2 до 5. То есть, применение графовых СУБД в настоящее время ограничено только сильно связанными данными.

Решение — Графовая СУБД NitrosBase

Графовая СУБД NitrosBase RDF Storage целиком основана на технологии NitrosBase, которая создавалась и оттачивалась более 20 лет. Технологические новации NitrosBase занимают лидирующие позиции по производительности, что неоднократно было отмечено наградами на отраслевых выставках и конференциях.

Проведенные нами сравнительные тесты широко известного набора SP2Bench показали значительное превосходство в производительности NitrosBase Storage над конкурентами. Например, на рисунке ниже показаны сравнительные результаты запроса 6 из набора SP2Bench. Запрос состоял в том, чтобы получить множество публикаций, авторы которых не публиковались ранее. Результаты показывают превосходство NitrosBase по сравнению с одной из наиболее производительных RDF СУБД более чем в 200 раз.

NitrosBase RDF Storage проявляет свои преимущества не только при большом количестве связей, она быстрее всех известных на рынке реляционных СУБД даже при небольшом количестве связей, характерном для типовых современных приложений.

С помощью NitrosBase можно уже сейчас начать широкое распространение графовых СУБД для всех имеющихся на рынке ниш обработки данных.

Источник