База данных графов

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

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

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

По состоянию на 2021 год , ни один язык графовых запросов не получил повсеместного распространения так же, как SQL для реляционных баз данных, и существует большое разнообразие систем, многие из которых тесно привязаны к одному продукту. Некоторые ранние усилия по стандартизации привели к созданию языков запросов от разных производителей, таких как Gremlin , SPARQL и Cypher . В сентябре 2019 года предложение о проекте по созданию нового стандартного языка графовых запросов (ISO/IEC 39075 Информационные технологии — Языки баз данных — GQL) было одобрено членами Объединенного технического комитета 1 ISO/IEC (ISO/IEC JTC 1). GQL задуман как декларативный язык запросов к базе данных, такой как SQL. Помимо интерфейсов языка запросов, доступ к некоторым графовым базам данных осуществляется через интерфейсы прикладного программирования (API).

Базы данных графов отличаются от вычислительных механизмов графов. Базы данных графов — это технологии, которые представляют собой переводы баз данных реляционной онлайн-обработки транзакций (OLTP). С другой стороны, графовые вычислительные машины используются в онлайн-аналитической обработке (OLAP) для массового анализа. Базы данных на графах привлекли значительное внимание в 2000-х годах из-за успехов крупных технологических корпораций в использовании собственных графовых баз данных. наряду с введением графовых баз данных с открытым исходным кодом .

Одно исследование пришло к выводу, что СУБД «сопоставима» по производительности с существующими механизмами анализа графов при выполнении запросов к графам.

История

В середине 1960-х годов навигационные базы данных , такие как IBM, от IMS поддерживали древовидные структуры в своей иерархической модели , но строгую древовидную структуру можно было обойти с помощью виртуальных записей.

Структуры графов могли быть представлены в базах данных сетевых моделей конца 1960-х годов. CODASYL , который определил COBOL в 1959 году, определил язык сетевых баз данных в 1969 году.

Размеченные графы могли быть представлены в графовых базах данных середины 1980-х годов, таких как логическая модель данных.

Базы данных коммерческих объектов (ODBMS) появились в начале 1990-х годов. В 2000 году группа управления объектными данными опубликовала стандартный язык для определения структур объектов и отношений (графов) в своей публикации ODMG'93.

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

В середине-конце 2000-х годов стали доступны коммерческие графовые базы данных с гарантиями ACID , такие как Neo4j и Oracle Spatial and Graph .

В 2010-х годах стали доступны коммерческие графовые базы данных ACID, которые можно было масштабировать по горизонтали . Кроме того, SAP HANA привнесла в графические базы данных технологии обработки данных в памяти и столбцы . Также в 2010-х годах стали доступны многомодельные базы данных , поддерживающие графовые модели (и другие модели, такие как реляционная база данных или документ-ориентированная база данных ), такие как OrientDB , ArangoDB и MarkLogic (начиная с версии 7.0). За это время графовые базы данных различных типов стали особенно популярны при анализе социальных сетей с появлением компаний, занимающихся социальными сетями. Также в течение десятилетия стали доступны облачные графовые базы данных, такие как Amazon Neptune и Neo4j AuraDB .

Фон

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

База данных графов — это база данных, основанная на теории графов . Он состоит из набора объектов, которые могут быть узлом или ребром.

• Узлы представляют собой сущности или экземпляры, такие как люди, предприятия, счета или любые другие элементы, которые необходимо отслеживать. Они примерно эквивалентны записи, отношению или строке в реляционной базе данных или документу в базе данных хранилища документов.
• Ребра , также называемые графами или отношениями , представляют собой линии, соединяющие узлы с другими узлами; представляющие отношения между ними. Значимые закономерности возникают при изучении соединений и взаимосвязей узлов, свойств и ребер. Края могут быть как направленными, так и ненаправленными. В неориентированном графе ребро, соединяющее два узла, имеет одно значение. В ориентированном графе ребра, соединяющие два разных узла, имеют разное значение в зависимости от их направления. Края — это ключевое понятие в графовых базах данных, представляющее абстракцию, которая не реализована напрямую в реляционной модели или модели хранилища документов .
• Свойства — это информация, связанная с узлами. Например, если бы Arc.Ask3.Ru была одним из узлов, она могла бы быть привязана к таким свойствам, как веб-сайт , справочный материал или слова, начинающиеся с буквы w , в зависимости от того, какие аспекты Википедии имеют отношение к данной базе данных.

Графовые модели

Граф помеченных свойств

Пример графа с метками свойств

Модель графа с помеченными свойствами представлена ​​набором узлов, связей, свойств и меток. Оба узла данных и их связи имеют имена и могут хранить свойства, представленные парами ключ-значение . Узлы могут быть помечены для группировки. Ребра, представляющие отношения, обладают двумя качествами: они всегда имеют начальный и конечный узлы и направлены; сделать граф ориентированным . Отношения также могут иметь свойства. Это полезно для предоставления дополнительных метаданных и семантики связям узлов. Прямое хранение отношений позволяет осуществлять за постоянное время обход .

Структура описания ресурсов (RDF)

Основная статья: RDF (информатика)

Пример RDF-графика

В графовой модели RDF каждое добавление информации представлено отдельным узлом. Например, представьте себе сценарий, в котором пользователю необходимо добавить свойство имени для человека, представленного в виде отдельного узла на графе. В модели графа с помеченными свойствами это можно сделать путем добавления свойства имени в узел человека. Однако в RDF пользователю необходимо добавить отдельный узел с именем hasName соединяя его с исходным узлом человека. В частности, графовая модель RDF состоит из узлов и дуг. Нотация графа RDF или оператор представлены: узлом для субъекта, узлом для объекта и дугой для предиката. Узел можно оставить пустым, использовать литерал и/или указать URI . Дугу также можно идентифицировать по URI. Литерал узла может быть двух типов: простой (нетипизированный) и типизированный. Простой литерал имеет лексическую форму и, при необходимости, языковой тег. Типизированный литерал состоит из строки с URI, идентифицирующим определенный тип данных. Пустой узел можно использовать для точной иллюстрации состояния данных, когда данные не имеют URI .

Характеристики

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

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

Хранилище

Базовый механизм хранения графовых баз данных может различаться. Некоторые зависят от реляционного механизма и «хранят» данные графа в таблице (хотя таблица является логическим элементом, поэтому этот подход накладывает другой уровень абстракции между базой данных графов, системой управления базой данных графов и физическими устройствами, на которых хранятся данные). действительно хранится). Другие используют для хранения хранилище «ключ-значение» или документо-ориентированную базу данных , что делает их по своей сути NoSQL структурами . Узел будет представлен как любое другое хранилище документов, но ребра, связывающие два разных узла, содержат внутри документа специальные атрибуты; атрибуты _from и _to.

Смежность без индекса

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

Приложения

Распознано несколько категорий графиков по типу данных. Gartner предлагает пять основных категорий графиков:

• Социальный граф : речь идет о связях между людьми; примеры включают Facebook , Twitter и идею шести степеней разделения.
• График намерений: касается рассуждений и мотивации.
• График потребления: также известный как «график платежей», график потребления широко используется в розничной торговле. Компании электронной коммерции, такие как Amazon, eBay и Walmart, используют графики потребления для отслеживания потребления отдельных клиентов.
• График интересов : отображает интересы человека и часто дополняется социальным графиком. У него есть потенциал следовать предыдущей революции в веб-организации, отображая Интернет по интересам, а не индексируя веб-страницы.
• Мобильный график: строится на основе мобильных данных. Мобильные данные в будущем могут включать данные из Интернета, приложений, цифровых кошельков, GPS и устройств Интернета вещей (IoT).

Сравнение с реляционными базами данных

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

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

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

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

Примеры

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

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

Напротив, графовые базы данных напрямую хранят связи между записями. Вместо того, чтобы найти адрес электронной почты путем поиска ключа пользователя в userpk столбец, запись пользователя содержит указатель, который напрямую ссылается на запись адреса электронной почты. То есть, выбрав пользователя, указатель можно перейти непосредственно к записям электронной почты, нет необходимости искать в таблице электронной почты совпадающие записи. Это может исключить дорогостоящие операции соединения. Например, если искать все адреса электронной почты пользователей с кодом города «311», система сначала выполнит обычный поиск, чтобы найти пользователей с кодом «311», а затем получит адреса электронной почты, перейдя по ссылкам, найденным в эти записи. Реляционная база данных сначала найдет всех пользователей в «311», извлечет список первичных ключей, выполнит еще один поиск любых записей в таблице электронной почты с этими первичными ключами и свяжет совпадающие записи вместе. Для этих типов распространенных операций графовые базы данных теоретически будут работать быстрее.

Истинная ценность графового подхода становится очевидной, когда выполняется поиск глубиной более одного уровня. Например, рассмотрим поиск пользователей, у которых есть «подписчики» (таблица, связывающая пользователей с другими пользователями) в коде города «311». В этом случае реляционная база данных должна сначала выполнить поиск всех пользователей с кодом города «311», затем выполнить поиск любого из этих пользователей в таблице подписчиков и, наконец, выполнить поиск в таблице пользователей, чтобы получить подходящих пользователей. Напротив, графовая база данных будет искать всех пользователей в «311», а затем переходить по обратным ссылкам через отношения подписчиков, чтобы найти пользователей-подписчиков. Это позволяет избежать нескольких поисков, просмотров и использования памяти, связанной с хранением всех временных данных из нескольких записей, необходимых для построения выходных данных. В терминах большой записи O этот запрос будет выглядеть так: $O(\log n)+O(1)$ время – т.е. пропорционально логарифму размера данных. Напротив, реляционная версия будет состоять из нескольких $O(\log n)$ поиск плюс $O(n)$ время, необходимое для объединения всех записей данных.

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

Свойства добавляют к этой структуре еще один уровень абстракции , что также улучшает многие распространенные запросы. Свойства — это, по сути, метки, которые можно применять к любой записи, а в некоторых случаях и к краям. Например, можно было бы пометить Кларка Гейбла как «актера», что позволило бы системе быстро найти все записи, в которых указаны актеры, а не режиссер или оператор. Если метки по краям разрешены, можно также пометить отношения между «Унесёнными ветром» и Кларком Гейблом как «главные роли» и, выполнив поиск по людям, которые являются «главными» «актёрами» в фильме « Унесённые ветром », В базе данных появятся Вивьен Ли , Оливия де Хэвилленд и Кларк Гейбл. Эквивалентный SQL-запрос должен будет полагаться на добавленные данные в таблицу, связывающую людей и фильмы, что усложнит синтаксис запроса. Эти типы меток могут улучшить производительность поиска при определенных обстоятельствах, но, как правило, они более полезны для предоставления дополнительных семантических данных конечным пользователям.

Реляционные базы данных очень хорошо подходят для плоского расположения данных, где отношения между данными имеют глубину всего один или два уровня. Например, в базе данных бухгалтерского учета может потребоваться поиск всех позиций для всех счетов-фактур для данного клиента (запрос с тремя соединениями). Базы данных графов предназначены для наборов данных, которые содержат гораздо больше ссылок. Они особенно хорошо подходят для систем социальных сетей , где отношения «друзей» по сути ничем не ограничены. Эти свойства делают графовые базы данных естественным образом подходящими для типов поиска, которые все чаще встречаются в онлайн-системах и в больших данных средах . По этой причине графовые базы данных становятся очень популярными для крупных онлайн-систем, таких как Facebook , Google , Twitter и подобных систем с глубокими связями между записями.

Для дальнейшей иллюстрации представьте себе реляционную модель с двумя таблицами: people стол (который имеет person_id и person_name столбец) и friend стол (с friend_id и person_id, который является внешним ключом из people стол). В этом случае поиск всех друзей Джека приведет к следующему SQL-запросу.

SELECT p2.person_name 
FROM people p1 
JOIN friend ON (p1.person_id = friend.person_id)
JOIN people p2 ON (p2.person_id = friend.friend_id)
WHERE p1.person_name = 'Jack';

Тот же запрос можно перевести в --

• Cypher — графовый язык запросов к базе данных.

  MATCH (p1:person {name: 'Jack'})-[:FRIEND_WITH]-(p2:person)
  RETURN p2.name
  

• SPARQL к базе данных графов RDF, , язык запросов стандартизированный W3C и используемый в нескольких RDF Triple и Quad. хранилищах
  • Полная форма

    PREFIX foaf: <http://xmlns.com/foaf/0.1/>
    
    SELECT ?name
    WHERE { ?s a          foaf:Person . 
            ?s foaf:name  "Jack" . 
            ?s foaf:knows ?o . 
            ?o foaf:name  ?name . 
          }
    

  • Краткая форма

    PREFIX foaf: <http://xmlns.com/foaf/0.1/>
    
    SELECT ?name
    WHERE { ?s foaf:name     "Jack" ;
               foaf:knows    ?o .
               ?o foaf:name  ?name .
          }
    

• SPASQL, гибридный язык запросов к базе данных, расширяющий SQL с помощью SPARQL.

  SELECT people.name
  FROM (
         SPARQL PREFIX foaf: <http://xmlns.com/foaf/0.1/>
                SELECT ?name
                WHERE { ?s foaf:name  "Jack" ; 
                           foaf:knows ?o .
                        ?o foaf:name  ?name .
                      }
      ) AS people ;
  

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

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

Список графовых баз данных

Ниже приводится список известных графовых баз данных:

имя	текущий версия	последний выпускать дата (ГГГГ-ММ-ДД)	программное обеспечение лицензия	язык программирования	описание
Аэроспайк	7.0	2023-11-15	Собственный	С	Aerospike Graph — это хорошо масштабируемая база данных графов свойств с малой задержкой, построенная на проверенной платформе данных Aerospike в режиме реального времени. Aerospike Graph сочетает в себе корпоративные возможности базы данных Aerospike — наиболее масштабируемой базы данных NoSQL, работающей в режиме реального времени, — с моделью данных графа свойств с помощью графического вычислительного механизма Apache Tinkerpop. Разработчики получат встроенную поддержку языка запросов Gremlin, которая позволит им напрямую писать мощные бизнес-процессы.
АллегроГраф	7.0.0	2020-04	Собственная лицензия , клиенты: Eclipse Public License v1.	C# , C , Common Lisp , Java , Python	Структура описания ресурсов (RDF) и база данных графов.
Амазонка Нептун	1.3.2.1	2024-06-20	Собственный	Не разглашается	Amazon Neptune — это полностью управляемая графовая база данных от Amazon.com . Он используется как веб-сервис и является частью Amazon Web Services . Поддерживает популярные графовые модели, граф свойств и , W3C RDF а также соответствующие им языки запросов Apache TinkerPop, Gremlin , SPARQL и openCypher .
АнзоГраф БД	2.1	2020-02	Собственный	С , С++	AnzoGraph DB — это ) с массовым параллелизмом база данных в стиле Graph Online Analytics Processing ( GOLAP , созданная для поддержки SPARQL и языка запросов Cypher для анализа триллионов взаимосвязей. База данных AnzoGraph предназначена для интерактивного анализа больших наборов данных семантической тройки , но также поддерживает помеченные свойства в соответствии с предлагаемыми стандартами W3C .
АрангоДБ	3.9.1	2022-04	Бесплатный Apache 2 , проприетарный	C++ , JavaScript , .NET , Java , Python , Node.js , PHP , Scala , Go , Ruby , Elixir	Собственная графовая система базы данных NoSQL , разработанная ArangoDB Inc, поддерживающая три модели данных (ключ/значение, документы, графики), с одним ядром базы данных и унифицированным языком запросов, называемым AQL (язык запросов ArangoDB). Обеспечивает масштабируемость и высокую доступность за счет репликации между центрами обработки данных, автоматического сегментирования, автоматического переключения при сбое и других возможностей.
Azure Космос БД		2017	Собственный	Не разглашается	Мультимодальная база данных, поддерживающая концепции графов с использованием Apache Gremlin. языка запросов
Датастакс Предприятие График	v6.0.1	2018-06	Собственный	Ява	Распределенная масштабируемая база данных реального времени; поддерживает Tinkerpop и интегрируется с Cassandra.
бесконечный график	2021.2	2021-05	Собственная , коммерческая, бесплатная версия объемом 50 ГБ.	Java , C++ , язык запросов DO	Распределенная, облачная и масштабируемая графовая база данных для сложных запросов и операций в реальном времени. Его объекты Vertex и Edge имеют уникальные 64-битные идентификаторы объектов, которые значительно ускоряют операции навигации по графу и поиска пути. Он поддерживает пакетные или потоковые обновления графика наряду с одновременными параллельными запросами. Язык запросов DO в InfiniteGraph позволяет выполнять как запросы на основе значений, так и сложные графические запросы. InfiniteGraph выходит за рамки графовых баз данных и поддерживает сложные объектные запросы.
ЯнусГраф	1.0.0	2023-10-21	Апач 2	Ява	Открытый исходный код, масштабируемый, распределенный по графовой базе данных кластера с несколькими компьютерами в рамках The Linux Foundation ; поддерживает различные серверные части хранилища ( Apache Cassandra , Apache HBase , Google Cloud Bigtable , Oracle Berkeley DB ); поддерживает глобальную аналитику графических данных, составление отчетов, а также извлечение, преобразование и загрузку (ETL) посредством интеграции с платформами больших данных ( Apache Spark , Apache Giraph , Apache Hadoop ); поддерживает географический, числовой диапазон и полнотекстовый поиск через внешние индексные хранилища ( Elasticsearch , Apache Solr , Apache Lucene ).
МаркЛогик	8.0.4	2015	Собственная . бесплатная версия для разработчиков	Ява	Многомодельная база данных NoSQL , в которой хранятся документы (JSON и XML) и данные семантических графов ( тройки RDF ); также имеет встроенную поисковую систему.
Microsoft SQL-сервер 2017	RC1		Собственный	SQL /T-SQL, R , Python	Предлагает возможности графовой базы данных для моделирования отношений «многие ко многим». Отношения графов интегрированы в Transact-SQL и используют SQL Server в качестве основной системы управления базами данных.
ТуманностьГраф	3.7.0	2024-03	Версия с открытым исходным кодом находится под управлением Apache 2.0, Common Article 1.0.	C++ , Go , Java , Python	Масштабируемая база данных распределенных графов с открытым исходным кодом для хранения и обработки миллиардов вершин и триллионов ребер с задержкой в ​​миллисекунды. Он разработан на основе распределенной архитектуры без общего доступа и обеспечивает линейную масштабируемость.
Neo4j	5.22.0	2024-07-25	GPLv3 Community Edition, коммерческие варианты и варианты AGPLv3 для корпоративных и расширенных выпусков	Java , .NET , JavaScript , Python , Go , Ruby , PHP , R , Erlang / Elixir , C / C++ , Clojure , Perl , Haskell	Открытый исходный код, поддержка ACID, кластеризация высокой доступности для корпоративных развертываний, а также веб-администрирование, включающее полную поддержку транзакций и визуальный обозреватель графов связей между узлами; доступен из большинства языков программирования с помощью встроенного интерфейса REST веб- API и собственного протокола Bolt с официальными драйверами.
Онтотекст GraphDB	10.7.1	2024-07-22	Проприетарные версии , версии Standard и Enterprise являются коммерческими , бесплатная версия — бесплатной.	Ява	Высокоэффективная и надежная база данных семантических графов с поддержкой RDF и SPARQL, также доступная в виде кластера высокой доступности. Интегрирует OpenRefine для приема и согласования табличных данных и поверх него для доступа к данным на основе онтологий . Подключается к Lucene , SOLR и Elasticsearch для полнотекстового и фасетного поиска , а также к Kafka для обработки событий и потоков. Поддерживает OGC GeoSPARQL . Обеспечивает доступ JDBC к Knowledge Graphs .
ОпенЛинк Виртуоз	8.2	2018-10	Версия с открытым исходным кодом — GPLv2 , версия Enterprise — частная.	С , С++	Многомодельная (гибридная) система управления реляционными базами данных (RDBMS), которая поддерживает как SQL, так и SPARQL для декларативных (определение данных и манипулирование данными) операций над данными, смоделированными в виде таблиц SQL и/или графиков RDF. Также поддерживает индексацию RDF-Turtle, RDF-N-Triples, RDF-XML, JSON-LD, а также сопоставление и создание связей (таблиц SQL или графиков RDF) из многочисленных типов документов, включая CSV, XML и JSON. Может быть развернут как локальный или встроенный экземпляр (как используется в NEPOMUK Semantic Desktop), сетевой сервер с одним экземпляром или сетевой сервер с несколькими экземплярами эластичного кластера без общего доступа.
Oracle RDF-график; часть базы данных Oracle	21в	2020	Собственный	СПАРКЛ , SQL	Возможности RDF Graph как функции в многомодельной базе данных Oracle: RDF Graph: комплексное управление графами RDF W3C в базе данных Oracle с собственными логическими рассуждениями и трехуровневой защитой меток. ACID, высокая доступность, масштаб предприятия. Включает визуализацию, RDF4J и собственную конечную точку Sparql.
График свойств Oracle; часть базы данных Oracle	21в	2020	Собственный; Спецификация языка с открытым исходным кодом	PGQL , Java, Python	Граф свойств; состоящий из набора объектов или вершин и набора стрелок или ребер, соединяющих объекты. Вершины и ребра могут иметь несколько свойств, которые представлены в виде пар ключ-значение. Включает PGQL, SQL -подобный язык графовых запросов и механизм анализа в памяти (PGX), содержащий почти 60 готовых алгоритмов параллельных графов. Включает REST API и визуализацию графиков.
ОриентБД	3.2.28	2024-02	Community Edition — Apache 2 , Enterprise Edition — коммерческая версия.	Ява	Второе поколение распределенная графовая база данных с гибкостью документов в одном продукте (т.е. это одновременно графовая база данных и документная NoSQL база данных); лицензируется по лицензии Apache 2 с открытым исходным кодом; и имеет полную ACID поддержку ; имеет репликацию с несколькими хозяевами; поддерживает режимы без схемы, полный и смешанный; имеет профилирование безопасности на основе пользователя и ролей; поддерживает язык запросов, аналогичный SQL . Он имеет HTTP REST и JSON API .
RedisGraph	2.0.20	2020-09	Доступная лицензия на исходный код Redis	С	База данных Property Graph с возможностью запроса в памяти, которая использует разреженные матрицы для представления матрицы смежности в графах и линейную алгебру для запроса графа.
SAP Хана	2.0 СПС 05	2020-06	Собственный	C , C++ , Java , JavaScript и SQL -подобный язык.	в памяти ACID Граф свойств, поддерживаемый транзакциями
Спаркзее	5.2.0	2015	Частное , коммерческое , бесплатное ПО для оценки, исследований и разработок.	С++	Высокопроизводительная масштабируемая система управления базами данных от Sparsity Technologies; главной особенностью является производительность запросов при извлечении и исследовании больших сетей; имеет привязки для Java , C++, C# , Python и Objective-C ; Версия 5 — это первая графическая мобильная база данных .
Скррл Предприятие	2.0	2015-02	Собственный	Ява	Распределенная графовая база данных, работающая в режиме реального времени, обеспечивающая безопасность на уровне ячеек и массовое масштабирование.
Терадата Астра	7	2016	Собственный	Java , SQL , Python , C++ , R	База данных массовой параллельной обработки (MPP), включающая запатентованные механизмы, поддерживающие собственный SQL, MapReduce , а также хранение и обработку графических данных; предоставляет набор библиотек аналитических функций и визуализации данных.
ТерминусБД	11.0.6	2023-05-03	Апач 2	Пролог , Rust , Python , JSON-LD	Документоориентированный граф знаний; мощь графа корпоративных знаний и простота документов.
ТигрГраф	3.10.1	2024-05-07	Собственный	С++	Собственная графовая система управления базой данных с массивной параллельной обработкой (MPP)
ТипБД	2.14.0	2022-11	Бесплатная, GNU AGPLv3 , проприетарная	Java , Python , JavaScript	TypeDB — это строго типизированная база данных с богатой и логичной системой типов . TypeDB дает вам возможность решать сложные проблемы, а TypeQL — это язык запросов. TypeDB позволяет моделировать предметную область на основе логических и объектно-ориентированных принципов. TypeDB, состоящая из типов сущностей, связей и атрибутов , а также иерархий типов, ролей и правил, позволяет вам мыслить на более высоком уровне, в отличие от объединенных таблиц, столбцов, документов, вершин, ребер и свойств.

Языки программирования графовых запросов

• AQL (язык запросов ArangoDB) : SQL-подобный язык запросов, используемый в ArangoDB как для документов, так и для графиков.
• Язык запросов Cypher запросов к графу (Cypher): декларативный язык для Neo4j , который обеспечивает специальный и программный (подобный SQL) доступ к графу.
• GQL : предлагаемый стандартный язык запросов к графам ISO.
• GraphQL : язык запросов и манипулирования данными с открытым исходным кодом для API. Dgraph реализует модифицированный язык GraphQL под названием DQL (ранее GraphQL+-).
• Gremlin : язык графового программирования, который является частью проекта с открытым исходным кодом Apache TinkerPop.
• SPARQL : язык запросов для баз данных RDF, который может извлекать и манипулировать данными, хранящимися в формате RDF.
• запросы обычного пути — теоретический язык для запросов к графовым базам данных.

См. также

• Преобразование графа
• Иерархическая модель базы данных
• Ученый-компьютерщик
• Вадалог
• База данных объектов
• База данных RDF
• Структурированное хранилище
• Текстовый график
• Wikidata — это дочерний проект Wikipedia, который хранит данные в графовой базе данных. Обычный просмотр веб-страниц позволяет просматривать узлы, отслеживать ребра и выполнять SPARQL . запросы