что такое графовая база данных

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

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

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

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

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

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

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

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

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

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

Amazon Neptune

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

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

Источник

Обработка графов в SQL Server и Базы данных SQL Azure

SQL Server предоставляет возможности баз данных Graph для моделирования связей «многие ко многим». Связи графов интегрированы в Transact-SQL и получают преимущества использования SQL Server в качестве базовой системы управления базами данных.

Что такое графовая база данных?

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

Когда следует использовать базу данных Graph

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

Функции Graph, появившиеся в SQL Server 2017 (14.x);

Мы начинаем добавлять расширения графа в SQL Server, чтобы упростить хранение и запрос данных графов. В первом выпуске представлены следующие функции.

Создание объектов Graph

Transact-SQL расширения позволяют пользователям создавать таблицы node или ребра. С этими узлами и краями могут быть связаны свойства. Поскольку узлы и грани хранятся в виде таблиц, все операции, поддерживаемые реляционными таблицами, поддерживаются в таблице node или EDGE. Пример:

Узлы и грани хранятся в виде таблиц.

Расширения языка запросов

MATCH Введено предложение New для поддержки сопоставления шаблонов и навигации с несколькими прыжками через граф. MATCH Функция использует синтаксис стиля ASCII для сопоставления шаблонов. Пример:

Полностью интегрировано в SQL Server подсистему

Инструментарий и экосистема

Преимущества существующих средств и экосистемы, которые SQL Server предлагают. Такие средства, как резервное копирование и восстановление, импорт и экспорт, просто работают с программой BCP. Другие средства или службы, такие как SSIS, SSRS или Power BI, будут работать с таблицами графов так же, как они работают с реляционными таблицами.

Ограничения ребер

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

Слияние DML

Инструкция Merge выполняет операции вставки, обновления или удаления в целевой таблице на основе результатов объединения с исходной таблицей. Например, можно синхронизировать две таблицы путем вставки, обновления или удаления строк в целевой таблице на основе различий между целевой таблицей и исходной таблицей. Использование предикатов MATCH в инструкции MERGE теперь поддерживается в базе данных SQL Azure и SQL Server vNext. Это значит, что теперь можно объединить текущие данные графа (таблицы узлов или пограничных таблиц) с новыми данными, используя предикаты MATCH для указания связей графа в одной инструкции, а не отдельные инструкции INSERT, UPDATE и DELETE.

Кратчайший путь

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

Источник

Графовые базы данных: святой Грааль для разработчиков?

На Хабре не утихают споры о том, какие базы данных лучше и круче, дискуссии о перспективах SQL и NoSQL. Я не удержался и решил порассуждать о том, где могут быть полезны именно графовые БД.

Прежде чем начать, давайте задумаемся, какая информация имеется у нас сегодня на повестке дня? Это уже не просто данные – это весьма непредсказуемая структура, которая со временем может превратиться либо в BigData, либо в сложную семантическую сеть, и часто разработчик не может заранее сказать, какой она будет. Так как же выбрать базу данных – или хотя бы ее архитектуру, чтобы создать действительно быстрое и эффективно работающее приложение?

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

Структура реляционной БД

Как альтернатива базам данных SQL где-то с начала 2000-х развивается направление NoSQL. В эту категорию объединяют все подряд – от иерархических и сетевых БД (где помимо иерархии предусмотрены дополнительные связи) до упрощенных БД ключ-значение и документарных баз данных без определенных параметров значений каждого элемента. Причина эволюции этой категории баз данных заключается в следующем: если у вас примитивные и однотипные наборы данных, а запросы касаются одной таблицы – то все ОК, и можно работать с SQL. Но если нет? Если нужно обратиться к 10, 100, 1000 таблиц, чтобы обработать запрос? Тогда реляционная база данных начинает работать медленно, а для написания запроса требуется немало строчек кода.

Пожалуй, наибольшей популярностью баз данных из категории NoSQL пользуются документарные БД, в частности, MongoDB. Они позволяют хранить объекты с произвольными наборами значений, что очень удобно – скажем, у платежного поручения будут одни поля, у приказа – другие. И все это хранится в одном и том же сегменте БД, без подразделения на примитивные таблицы. Однако и у этого подхода есть ограничения, о которых я расскажу парой абзацев ниже.

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

Плюсы и минусы

Итак, про реляционную архитектуру мы уже поговорили – это прекрасное решение для тех случаев, когда все просто и однозначно, но совершенно неповоротливая архитектура для создания сложных и гибких запросов, обработки разнообразных и многократных связей между объектами. Однако, нельзя забывать о таких преимуществах SQL-баз данных, как возможность создания сложных (JOIN) запросов. Такой подход делает стандартизированные реляционные БД более универсальными, ведь пусть даже большим количеством кода, но каждый запрос может быть в них реализован. Например, найти всех людей моложе 20 лет, у которых есть автомобили красного цвета, будет достаточно легко сделать в SQL, в то время как БД из категории NoSQL потребуют массы усилий для решения этой задачи.

Иллюстрация сложного запроса в SQL

Прямая альтернатива SQL – документарные базы данных. Их главное преимущество – это отсутствие единой схемы всех элементов (schemaless). В отличие от SQL эти базы могут сохранять любой сложный объект, например, документ с большим количеством полей за одну операцию, а также за одну операцию выдавать его. Это очень удобно, например, для добавления новых категорий товаров в каталог интернет-магазина, ведь для телевизора, микроволновой печи и утюга будут применяться совершенно разные свойства. В той же MongoDB можно работать с ними через короткие запросы, в то время как в SQL для получения и обновления такой сложной записи придется создавать специальные процедуры, выполняющие множество запросов.

Иллюстрация хранения различных типов данных в документарной базе

Минусы документарных баз также вытекают из их архитектурных особенностей. Например, документарная модель не подразумевает таких простых функций объединения (JOIN), а также возможности работать с двунаправленными связями. Кроме этого документарная база рассчитана на хранение отдельных элементов, не имеющих дополнительных связей между собой. Хороший пример того, с какими сложностями столкнулись создатели социальной сети Diaspora приведен тут (http://habrahabr.ru/post/231213/). Ребята сначала начали активно эксплуатировать преимущества документарной модели, но потом просто столкнулись с тем, что социальные данные имеют множество связей друг с другом и ох очень сложно представить в виде отдельных «документов». И им все равно пришлось вернуться к SQL.

Структура социальных данных, для которых не подошла документарная модель хранения

Теперь немного о графах. Они изначально ориентированы на связи между объектами, и эти связи могут иметь разные характеристики. Например, если заказчик требует разработать базу данных сериалов, где к каждому эпизоду каждого сериала относятся различные актеры, самым очевидным образом вырисовывается иерархическая модель, которая прекрасно ложится в документарную базу данных. Однако, как только заказчик говорит: «Слушайте, а давайте наша система будет также в один клик выводить фильмографию актеров», вся иерархия рассыпается и приходится либо дорабатывать БД (долго и мучительно), либо менять формат хранения данных.

Основным преимуществом графовых баз данных в этом свете является универсальность, ведь в них можно хранить и реляционные, и документарные и сложные семантические данные. А сама модель построения БД может меняться и модифицироваться в процессе развития приложения без изменения архитектуры и исходных запросов. А значит – не нужно будет ничего переписывать!

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

Графы все же перспективны?

Однако, раз уж мы говорим сегодня о разработке приложений, в процессе проектирования и даже на стадии «шлифовки», нередко появляются новые требования к структуре данных, и хорошая модель внезапно может стать плохой. Например, добавление новых связей делает неприемлемой документарную базу данных, а рост количества JOIN-ов катастрофически снижает производительность реляционной БД. В этом случае графы оказываются наиболее универсальным вариантом, позволяющим подстраховаться на случай изменения требований и расширения функционала в будущем. Нужно добавить к реляционным данным дополнительные связи? Без проблем! Нужно усложнить иерархическую документарную модель? Легко!

Графовые данные: множество объектов, множество типов связей между ними

Более того, сегодня активно идет доработка RDF – основного стандарта, согласно которому работают графовые базы данных. И, если вспомнить, именно стандартизация SQL сделала такими популярными именно реляционные БД. При этом ряд проектов демонстрирует поддержку OData для создания стандартных веб-запросов через HTTP, а также язык SPARQL, обладающий обширными возможностями для работы с различными видами запросов и данных (тут можно провести аналогию с SQL для реляционных БД). Но и, наконец, за счет развития архитектуры производительность графовых БД растет, и, возможно, скоро окажется выше реляционной даже при небольшом количестве связей. Так что, быть может, в скором времени графовые БД станут чем-то вроде Святого Грааля для разработчиков?

Источник

Введение в графовые базы данных SQL Server 2017

В преддверии старта курса «MS SQL Server Developer» подготовили для вас еще один полезный перевод.

Графовые базы данных — это важная технология для специалистов по базам данных. Я стараюсь следить за инновациями и новыми технологиями в этой области и, после работы с реляционными и NoSQL базами данных, я вижу, что роль графовых баз данных становится все больше. В работе со сложными иерархическими данными малоэффективны не только традиционные базы данных, но и NoSQL. Часто, с увеличением количества уровней связей и размера базы, наблюдается снижение производительности. А с усложнением взаимосвязей увеличивается и количество JOIN.

Конечно, в реляционной модели есть решения для работы с иерархиями (например, с помощью рекурсивных CTE), но это все равно остается обходными путями. При этом, функционал графовых баз данных SQL Server позволяет с легкостью обрабатывать несколько уровней иерархии. Упрощаются как модель данных, так и запросы, а следовательно, увеличивается их эффективность. Значительно сокращается объем кода.

Графовые базы данных — это выразительный язык для представления сложных систем. Эта технология уже довольно широко используется в ИТ-индустрии в таких областях, как социальные сети, антифрод-системы, анализ ИТ-сетей, социальные рекомендации, рекомендации по продуктам и контенту.

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

Графовая модель данных

Граф — это множество вершин (узлов, node) и ребер (взаимосвязей, edge). Вершины представляют сущности, а ребра — связи, в атрибутах которых может содержаться информация.

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

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

В современном мире моделирование взаимосвязей требует все более сложных методик. Для моделирования связей SQL Server 2017 предлагает возможности графовых баз данных. Вершины и ребра графа представляются в виде новых типов таблиц: NODE и EDGE. Для запросов к графу используется новая функция T-SQL под названием MATCH(). Так как этот функционал встроен в SQL Server 2017, то его можно использовать в ваших существующих базах данных без необходимости какой-либо их конвертации.

Польза графовой модели

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

Судя по всему, в будущем многие приложения смогут выиграть от использования графовых баз данных.

Моделирование данных: от реляционной модели к графовой

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

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

На следующей диаграмме изображена так же самая модель оргструктуры с четырьмя уровнями вложенности в более привычном виде. Сотрудники — это вершины графа из таблицы EMP. Сущность «сотрудник» связана сама с собою связью «подчиняется» (ReportsTo). В терминах графа, связь — это ребро (EDGE), которое связывает узлы (NODE) сотрудников.

Давайте создадим обычную таблицу EMP и добавим туда значения в соответствии с вышеприведенной диаграммой.

На приведенном ниже рисунке показаны сотрудники:

Теперь давайте посмотрим на представление тех же данных в виде графа. Вершина EMPLOYEE имеет несколько атрибутов и связана сама с собой связью «подчиняется» (EmplReportsTo). EmplReportsTo — это название связи.

В таблице ребер (EDGE) также могут присутствовать атрибуты.

Создадим таблицу узлов EmpNode

Синтаксис создания узла довольно прост: к выражению CREATE TABLE в конец добавляется «AS NODE».

Теперь преобразуем данные из обычной таблицы в графовую. Следующий INSERT вставляет данные из реляционной таблицы EMP.

В таблице узлов в специальной колонке $node_id_* хранится идентификатор узла в виде JSON. В остальных столбцах этой таблицы находятся атрибуты узла.

Создаем ребра (EDGE)

Создание таблицы ребер очень похоже на создание таблицы узлов, за исключением того, что используется ключевое слово «AS EDGE».

Теперь определим связи между сотрудниками, используя столбцы EMPNO и MGR. По диаграмме оргструктуры хорошо видно как написать INSERT.

Таблица ребер по умолчанию состоит из трех столбцов. Первый, $edge_id — идентификатор ребра в виде JSON. Два других ( $from_id и $to_id ) представляют связь между узлами. Кроме того, ребра могут иметь дополнительные свойства. В нашем случае это Deptno.

Системные представления

В системном представлении sys.tables появилось две новые колонки:

Объекты, связанные с графами, располагаются в папке Graph Tables. Иконка таблицы узлов помечена точкой, а таблицы ребер — двумя связанными кругами (что немного похоже на очки).

Выражение MATCH

Выражение MATCH взято из CQL (Cypher Query Language). Это эффективный способ запроса к свойствам графа. CQL начинается с выражения MATCH.

Давайте посмотрим на несколько примеров.

Приведенный ниже запрос отображает сотрудников, которым подчиняется Smith и его менеджер.

Следующий запрос предназначен для поиска сотрудников и менеджеров второго уровня для Smith. Если убрать предложение WHERE, то в результате будут отображаться все сотрудники.

И, наконец, запрос для сотрудников и менеджеров третьего уровня.

Теперь давайте изменим направление, чтобы получить начальников Smith’а.

Заключение

SQL Server 2017 зарекомендовал себя как полноценное корпоративное решение для различных ИТ-задач бизнеса. Первая версия SQL Graph очень многообещающая. Даже несмотря на некоторые ограничения, уже сейчас есть достаточно функционала для изучения возможностей графов.

Функционал SQL Graph полностью интегрирован в SQL Engine. Однако, как уже было сказано, в SQL Server 2017 есть следующие ограничения:

Нет поддержки полиморфизма.

Источник