Из Википедии, бесплатной энциклопедии
  (Перенаправлено из баз данных Graph )
Перейти к навигации Перейти к поиску

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

Базы данных Graph - это тип базы данных NoSQL , созданный для устранения ограничений реляционных баз данных . В то время как модель графа явно определяет зависимости между узлами данных, реляционная модель и другие модели баз данных NoSQL связывают данные неявными связями. Другими словами, отношения - это первоклассный гражданин в базе данных графов, и их можно помечать, направлять и задавать свойства. Это сравнивается с реляционными подходами, в которых эти отношения подразумеваются и должны быть уточнены во время выполнения. Базы данных графов похожи на базы данных сетевых моделей 1970-х годов в том, что оба представляют общие графы, но базы данных сетевых моделей работают на более низком уровне абстракции [3]и не хватает легкого обхода цепочки ребер. [4]

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

По состоянию на 2017 год ни один универсальный язык графовых запросов не был принят так же, как SQL был принят для реляционных баз данных, и существует большое разнообразие систем, чаще всего тесно связанных с одним продуктом. Были предприняты некоторые усилия по стандартизации, что привело к появлению языков запросов от различных поставщиков, таких как Gremlin , SPARQL и Cypher . Помимо интерфейсов на языке запросов, доступ к некоторым базам данных графов осуществляется через интерфейсы прикладного программирования (API).

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

Исследования показали, что использование графоцентрического механизма выполнения и диспетчера хранения бесполезно. [6]

История [ править ]

В середине 1960-х годов, навигационные базы данных , такие как IBM «s IMS поддерживает дерево -как структур в своей иерархической модели , но строгая структура дерева может быть обойдена с виртуальными записей. [7] [8]

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

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

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

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

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

Фон [ править ]

Базы данных графов используют узлы, свойства и ребра.

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

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

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

Графические модели [ править ]

График помеченных свойств [ править ]

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

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

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

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

Свойства [ править ]

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

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

Хранилище [ править ]

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

Смежность без индекса [ править ]

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

Типы графиков [ править ]

Есть несколько типов графиков, которые можно разделить на категории. Gartner предлагает пять широких категорий графиков: [15]

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

Сравнение с реляционными базами данных [ править ]

Поскольку Кодд «S 1970 документ о реляционной модели , [16] реляционные базы данных были де - факто отраслевым стандартом для крупномасштабных систем хранения данных. Однако реляционные модели требуют строгой схемы, а нормализация данных накладывает ограничения на то, как можно запрашивать отношения.

Традиционно базы данных разрабатывались с использованием реляционной модели, в которой данные нормализованы для поддержки транзакций ACID . В процессе нормализации данных удаляются все повторяющиеся данные в базе данных. Цель нормализации данных - сохранить целостность данных . Реляционная модель обеспечивает выполнение транзакций ACID, разделяя данные на множество таблиц.

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

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

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

Примеры [ править ]

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

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

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

Истинная ценность графического подхода становится очевидной, когда выполняются поиски на глубину более одного уровня. Например, рассмотрим поиск пользователей, у которых есть «подписчики» (таблица, связывающая пользователей с другими пользователями) в коде зоны «311». В этом случае реляционная база данных должна сначала выполнить поиск всех пользователей с кодом области в «311», затем выполнить поиск в таблице подписчиков для любого из этих пользователей, а затем, наконец, выполнить поиск в таблице пользователей, чтобы найти подходящих пользователей. Напротив, графовая база данных будет искать всех пользователей в «311», а затем следовать по обратным ссылкам через отношения подписчика, чтобы найти пользователей-подписчиков. Это позволяет избежать нескольких поисков, поисков,и использование памяти, связанное с хранением всех временных данных из нескольких записей, необходимых для построения вывода. С точки зрениябольшой O , этот запрос будет временем, т. е. пропорциональным логарифму размера данных. Напротив, реляционная версия будет включать несколько поисков плюс время, необходимое для объединения всех записей данных. [18]

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

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

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

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

ВЫБЕРИТЕ  p2 . person_name  ИЗ  людей  p1  ПРИСОЕДИНЯЙТЕСЬ к  другу  ON  ( p1 . person_id  =  friend . person_id ) ПРИСОЕДИНЯЙТЕСЬ к  людям  p2  ON  ( p2 . person_id  =  friend . friend_id ) ГДЕ  p1 . person_name  =  'Джек' ;

Тот же запрос может быть переведен на -

  • Cypher , язык запросов к базе данных графов
    МАТЧ ( p1 : человек ) - [ : ДРУГ - С ] - ( p2 : человек ) ГДЕ p1 . name = "Джек"   ВОЗВРАТ p2 . название
  • SPARQL , язык запросов к базе данных графов RDF, стандартизированный W3C и используемый в нескольких хранилищах RDF Triple и Quad.
    • Длинная форма 
      ПРЕФИКС  foaf :  <http://xmlns.com/foaf/0.1/>ВЫБЕРИТЕ  ? Name WHERE  {  ? S  a  foaf : Person  .  ? s  foaf : имя  "Джек"  .  ? s  foaf : знает  ? o  .  ? o  foaf : имя  ? имя  .  }
    • Короткая форма 
      ПРЕФИКС  foaf :  <http://xmlns.com/foaf/0.1/>ВЫБЕРИТЕ  ? Name WHERE  {  ? S  foaf : name  "Джек"  ;  FOAF : знает  O?  .  ? o  foaf : имя  ? имя  .  }
  • SPASQL, гибридный язык запросов к базе данных, расширяющий SQL с помощью SPARQL.
    ВЫБЕРИТЕ  людей . имя ОТ  (  ПРЕФИКС SPARQL  foaf : <http://xmlns.com/foaf/0.1/> SELECT ? name WHERE { ? s foaf : name "Джек" ; foaf : знает ? o . ? o foaf : name ? name . } ) КАК люди ;

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

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

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

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

ИмяВерсияЛицензияЯзыкОписание
АллегроГраф7.0.0 (апрель 2020 г.)Собственные , клиенты: Eclipse Public License v1C # , C , Common Lisp , Java , PythonСтруктура описания ресурсов (RDF) и база данных графов
Амазонка Нептун1.0.4.0 (октябрь 2020 г.) [20]ПроприетарныйНе разглашаетсяAmazon Neptune - это полностью управляемая база данных графов от Amazon.com . Он используется как веб-сервис и является частью Amazon Web Services . Поддерживает популярный граф граф модели собственности и W3C «s RDF , и их соответствующих языков запросов Apache TinkerPop Гремлин и SPARQL .
БД AnzoGraph2.1 (февраль 2020 г.)ПроприетарныйC , C ++AnzoGraph DB - это массивно-параллельная база данных в стиле GOLAP (Graph Online Analytics Processing), созданная для поддержки SPARQL и Cypher Query Language для анализа триллионов взаимосвязей. База данных AnzoGraph предназначена для интерактивного анализа больших наборов данных семантических троек , но также поддерживает помеченные свойства в соответствии с предлагаемыми стандартами W3C . [21] [22] [23] [24]
ArangoDB3.7.2 / (21 августа 2020 г.)Бесплатный Apache 2 , проприетарный ,C ++ , JavaScript , .NET , Java , Python , Node.js , PHP , Scala , Go , Ruby , ElixirНативная многомодельная система баз данных NoSQL, разработанная ArangoDB Inc. Система баз данных поддерживает три важные модели данных (ключ / значение, документы, графики) с одним ядром базы данных и унифицированным языком запросов под названием AQL (ArangoDB Query Language)
График DataStax Enterprisev6.0.1 (июнь 2018 г.)ПроприетарныйЯваРаспределенная масштабируемая база данных в реальном времени; поддерживает Tinkerpop и интегрируется с Cassandra [25]
DGraph20.07.3 (янв 2021 г.)Apache 2Go , GraphQL , JavaScript , .NET , Java , PythonОткрытый исходный код , распределенная база данных графа с GraphQL на основе языка запросов. [26] [27]
Ядро Гракна1.8.4Бесплатно, GNU AGPLv3ЯваGrakn является открытым исходным кодом , распределенных граф знаний для систем знаниеориентированных. Это эволюция реляционной базы данных для сильно взаимосвязанных данных, поскольку она предоставляет схему на уровне концепции, которая полностью реализует модель сущность – связь (ER) . Однако схема Гракна - это система типов , реализующая принципы представления знаний и рассуждений . Это позволяет декларативному языку запросов Grakn, Graql (язык логических и аналитических запросов Grakn), предоставлять более выразительный язык моделирования и способность выполнять логические рассуждения над большими объемами сложных данных. По сути, Grakn - этобаза знаний для систем искусственного интеллекта и когнитивных вычислений .
InfiniteGraph2021.2 (май 2021 г.)Собственная , коммерческая, бесплатная версия на 50 ГБЯваРаспределенная, облачная и масштабируемая графовая база данных для сложных запросов и операций в реальном времени. Его объекты Vertex и Edge имеют уникальные 64-битные идентификаторы объектов, которые значительно ускоряют навигацию по графу и операции поиска пути. Он поддерживает пакетные или потоковые обновления графа вместе с параллельными запросами.
ЯнусГраф0.5.3 (24 декабря 2020 г.) [28]Apache 2ЯваОткрытый исходный код, масштабируемый, распределенный по базе данных графа кластера с несколькими машинами под управлением Linux Foundation ; поддерживает различные бэкенды хранения ( Apache Cassandra , Apache HBase , Google Cloud Bigtable , Oracle BerkeleyDB ); [29] поддерживает глобальную аналитику графовых данных, отчетность и ETL за счет интеграции с платформами больших данных ( Apache Spark , Apache Giraph , Apache Hadoop ); поддерживает географический, числовой диапазон и полнотекстовый поиск через внешние хранилища индексов ( Elasticsearch , Apache Solr , Apache Lucene ). [30]
MarkLogic8.0.4 (2015)Собственная , бесплатная версия для разработчиковЯваМультимодельная база данных NoSQL, в которой хранятся документы (JSON и XML) и данные семантического графа ( тройки RDF ); также имеет встроенную поисковую систему
Microsoft SQL Server 2017RC1ПроприетарныйSQL / T-SQL, R , PythonПредлагает возможности графической базы данных для моделирования отношений «многие ко многим». Связи графов интегрированы в Transact-SQL и используют SQL Server в качестве основной системы управления базами данных. [31]
График туманности2.0.0-альфа (ноябрь 2020 г.)Apache 2.0, открытый исходный код, Common Clause 1.0C ++, Go, Java , PythonМасштабируемая база данных распределенных графов с открытым исходным кодом для хранения и обработки миллиардов вершин и триллионов ребер с задержкой в ​​миллисекунды. Он разработан на основе распределенной архитектуры без совместного использования ресурсов для линейной масштабируемости. [32]
Neo4j4.2.6 (май 2021 г.) [33]GPLv3 Community Edition, коммерческий и AGPLv 3 варианта для корпоративных и продвинутых изданийJava , .NET , JavaScript , Python , Go ,

Ruby , PHP , R , Erlang / Elixir , C / C ++ , Clojure , Perl , Haskell

Открытый исходный код, поддерживает ACID, имеет кластеризацию высокой доступности для корпоративных развертываний и поставляется с веб-администрированием, которое включает полную поддержку транзакций и визуальный обозреватель графа связей узлов; доступный из большинства языков программирования с использованием встроенного интерфейса веб-API REST и проприетарного протокола Bolt с официальными драйверами.
Ontotext GraphDB9,7 (апрель 2021 г.)Проприетарная , Стандартная и Корпоративная версии являются коммерческими , а бесплатная - бесплатная.ЯваВысокоэффективная и надежная графическая база данных с поддержкой RDF и SPARQL, также доступная в виде кластера высокой доступности.
OpenLink  Virtuoso8.2 (октябрь 2018)Версия с открытым исходным кодом - GPLv 2, Enterprise Edition является проприетарнойC , C ++Мультимодельная (гибридная) система управления реляционными базами данных (СУБД), которая поддерживает как SQL, так и SPARQL для декларативных операций (определение данных и манипулирование данными) с данными, смоделированными в виде таблиц SQL и / или графиков RDF. Также поддерживает индексацию RDF-Turtle, RDF-N-Triples, RDF-XML, JSON-LD, а также отображение и создание отношений (таблиц SQL или графиков RDF) из множества типов документов, включая CSV, XML и JSON. Может быть развернут как локальный или встроенный экземпляр (как используется в семантическом рабочем столе NEPOMUK ), сетевой сервер с одним экземпляром или сетевой сервер с несколькими экземплярами эластичного кластера без совместного использования ресурсов [34]
Oracle RDF Graph; часть Oracle Database21c (2020)ПроприетарныйSPARQL, SQLВозможности RDF Graph как функции многомодельной Oracle Database: RDF Graph: комплексное управление W3C RDF-графом в Oracle Database с собственным логическим обоснованием и трехуровневой защитой меток. ACID, высокая доступность, масштаб предприятия. Включает визуализацию, RDF4J и конечную точку конечного конца Sparql.
График свойств Oracle; часть Oracle Database21c (2020)Собственный; Спецификация языка с открытым исходным кодомPGQL , Java, PythonГрафик свойств - состоящий из набора объектов или вершин и набора стрелок или ребер, соединяющих объекты. Вершины и ребра могут иметь несколько свойств, которые представлены парами "ключ-значение". Включает PGQL, язык запросов графов, подобный SQL, и аналитический механизм в памяти (PGX), почти 60 встроенных алгоритмов параллельных графов. Включает REST API и визуализацию графиков.
OrientDB3.0.28 (февраль 2020 г.)Community Edition - это Apache 2 , Enterprise Edition - коммерческаяЯваБаза данных с распределенными графами второго поколения с гибкостью документов в одном продукте (т. Е. Это и база данных графов, и база данных NoSQL документов); под лицензией Apache 2 с открытым исходным кодом; и имеет полную поддержку ACID ; имеет репликацию и сегментирование с несколькими мастерами ; поддерживает режимы без схемы, полный и смешанный; имеет профили безопасности на основе пользователей и ролей; поддерживает язык запросов, аналогичный SQL. Имеет HTTP REST и JSON API .
RedisGraph2.0.20 (сен 2020)Доступная лицензия Redis SourceCЗапрашиваемая база данных графов свойств в памяти, которая использует разреженные матрицы для представления матрицы смежности в графах и линейную алгебру для запросов к графу. [35]
SAP HANA2.0 SPS 05 (июнь 2020 г.) [36]ПроприетарныйC , C ++ , Java , JavaScript и SQL- подобные языкиГраф свойств, поддерживаемых транзакциями ACID в памяти [37]
Sparksee5.2.0 (2015)Собственное , коммерческое , бесплатное ПО для оценки, исследований и разработокC ++Высокопроизводительная масштабируемая система управления базами данных от Sparsity Technologies; главная особенность - производительность запросов при поиске и исследовании больших сетей; имеет привязки для Java , C ++ , C # , Python и Objective-C ; версия 5 - первая мобильная база данных на графах
Sqrrl  Enterprise2.0 (февраль 2015 г.)ПроприетарныйЯваРаспределенная база данных графов в реальном времени, обеспечивающая безопасность на уровне ячеек и масштабируемость [38]
Терадата Астра7 (2016)ПроприетарныйJava , SQL , Python , C ++ , RБаза данных MPP, включающая запатентованные механизмы, поддерживающие собственный SQL, MapReduce и хранение и обработку данных графов; предоставляет набор аналитических библиотек функций и визуализации данных [39]
TerminusDB4,2 (2021 год)Бесплатный Apache 2 ,Пролог , Rust , JSON-LDБаза данных графов на основе моделей, предназначенная для представления графов знаний
ТигрГраф3,1 (2021 год)ПроприетарныйC ++Система управления базой данных собственного графа MPP [40]

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

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

См. Также [ править ]

  • Преобразование графа
  • Иерархическая модель базы данных
  • База данных объектов
  • База данных RDF
  • Структурированное хранилище
  • Текстовый график

Ссылки [ править ]

  1. ^ Николаос Г. Бурбакис (1998). Искусственный интеллект и автоматизация . World Scientific. п. 381. ISBN. 9789810226374. Проверено 20 апреля 2018 .
  2. ^ Yoon, Byoung-Ха; Ким, Сон-Кю; Ким, Сон-Ён (март 2017 г.). «Использование графической базы данных для интеграции разнородных биологических данных» . Геномика и информатика . 15 (1): 19–27. DOI : 10.5808 / GI.2017.15.1.19 . ISSN 1598-866X . PMC 5389944 . PMID 28416946 .   
  3. ^ a b Углы, Ренцо; Гутьеррес, Клаудио (1 февраля 2008 г.). «Обзор моделей графовых баз данных» (PDF) . ACM Computing Surveys . 40 (1): 1–39. CiteSeerX 10.1.1.110.1072 . DOI : 10.1145 / 1322432.1322433 . S2CID 207166126 . Архивировано из оригинального (PDF) 15 августа 2017 года . Проверено 28 мая 2016 . сетевым моделям [...] не хватает хорошего уровня абстракции: сложно отделить db-модель от реальной реализации.   
  4. ^ Silberschatz, Avi (28 января 2010). Концепции системы баз данных, шестое издание (PDF) . Макгроу-Хилл. п. Д-29. ISBN  978-0-07-352332-3.
  5. ^ «Графические базы данных ворвались в мейнстрим» . www.kdnuggets.com . Проверено 23 октября 2018 .
  6. ^ Фан, Цзин; Джеральд, Адальберт (2014-12-25). Дело против специализированных движков графической аналитики (PDF) . Конференция по исследованиям инновационных систем данных (CIDR).
  7. ^ Silberschatz, Avi (28 января 2010). Концепции системы баз данных, шестое издание (PDF) . Макгроу-Хилл. п. E-20. ISBN  978-0-07-352332-3.
  8. ^ Паркер, Лотарингия. «Примечания IMS» . vcu.edu . Дата обращения 31 мая 2016 .
  9. ^ Купер, Габриэль М. (1985). Логическая модель данных: новый подход к логике базы данных (PDF) (доктор философии). Документ STAN-CS-85-1069 . Дата обращения 31 мая 2016 .
  10. ^ «SAP объявляет о новых возможностях в облаке с HANA» . 2014-10-22 . Проверено 7 июля 2016 .
  11. ^ Frisendal, Томас (2017-09-22). «Графики свойств» . graphdatamodeling.com . Проверено 23 октября 2018 .
  12. ^ Das, S; Шринивасан, Дж; Перри, Мэтью; Чонг, Юджин; Банерджи, Джей (24 марта 2014 г.). «Повесть о двух графах: графы свойств как RDF в Oracle» . Cite journal requires |journal= (help)
  13. ^ a b Имейте, Кристиан Тейл; Дженсен, Ларс Джул (2013-10-17). «Готовы ли графические базы данных для биоинформатики?» . Биоинформатика . 29 (24): 3107–3108. DOI : 10.1093 / биоинформатики / btt549 . ISSN 1460-2059 . PMC 3842757 . PMID 24135261 .   
  14. ^ «Структура описания ресурсов (RDF): концепции и абстрактный синтаксис» . www.w3.org . Проверено 24 октября 2018 .
  15. ^ «Конкурентная динамика потребительской сети: пять графиков обеспечивают устойчивое преимущество» . www.gartner.com . Проверено 23 октября 2018 .
  16. ^ a b Кодд, EF (1970-06-01). «Реляционная модель данных для больших общих банков данных». Коммуникации ACM . 13 (6): 377–387. DOI : 10.1145 / 362384.362685 . ISSN 0001-0782 . S2CID 207549016 .  
  17. ^ "Графические базы данных, 2-е издание" . О'Рейли | Safari . Проверено 23 октября 2018 .
  18. ^ a b c d «От реляционных баз данных к графам» . Neo4j .
  19. ^ a b "Примеры, в которых блистают базы данных Graph: версия Neo4j" , ZeroTurnaround
  20. ^ «Amazon Neptune Engine версии 1.0.4.0 (12.10.2020)» . AWS . Проверено 17 ноября, 2020 .
  21. ^ «База данных параллельных распределенных графов в памяти, предназначенная для аналитики» . www.Cambridgesemantics.com . Проверено 20 февраля 2018 .
  22. ^ Rueter, Джон (15 февраля 2018). «Cambridge Semantics объявляет о поддержке аналитики на основе графов AnzoGraph для Amazon Neptune и графических баз данных» . Businesswire . Проверено 20 февраля 2018 года .
  23. Рианна Зейн, Барри (2 ноября 2016 г.). «Базы данных семантических графов: достойный преемник реляционных баз данных» . www.dbta.com . Проверено 20 февраля 2018 года .
  24. ^ «Cambridge Semantics объявляет о поддержке AnzoGraph для Amazon Neptune и баз данных Graph» . Тенденции и приложения баз данных . 2018-02-15 . Проверено 8 марта 2018 .
  25. ^ Woodie, Alex (21 июня 2016). «За гранью Титана: Эволюция новой графической базы данных DataStax» . Датанами . Проверено 9 мая 2017 года .
  26. ^ "Свойства системы Dgraph" . db-engines.com . Источник 2021-01-26 .
  27. ^ «Dgraph собирает 3 миллиона долларов для своей базы данных распределенного графа с открытым исходным кодом, выпуск 1.0» . TechCrunch . Источник 2021-01-26 .
  28. ^ "JanusGraph версии 0.5.3" . 24 декабря 2020 г. - через Github.
  29. ^ "Бэкэнды хранилища JanusGraph" . Архивировано из оригинала на 2018-10-02 . Проверено 1 октября 2018 .
  30. ^ "Индексные хранилища JanusGraph" . Архивировано из оригинала на 2018-10-02 . Проверено 1 октября 2018 .
  31. ^ «Что нового в SQL Server 2017» . Документы Microsoft . 19 апреля 2017 . Проверено 9 мая 2017 года .
  32. ^ «Дебюты Nebula Graph для открытия аналитики больших данных» . Датанами . 29 июня 2020 . Проверено 2 декабря 2020 года .
  33. ^ «Примечания к выпуску: Neo4j 4.2.6» . Платформа графической базы данных Neo4j . Проверено 5 мая 2021 .
  34. ^ "Диаграммы архитектуры развертывания кластеров для виртуоза" . Википедия с открытым исходным кодом Virtuoso . Программное обеспечение OpenLink . Проверено 9 мая 2017 года .
  35. ^ Эубанк, Key. «RedisGraph становится общедоступным» . i-programmer.info .
  36. ^ «Что нового в SAP HANA 2.0 SPS 05» . Информация о продукте . Проверено 26 июня 2020 .
  37. ^ Рудольф, Майкл; Paradies, Маркус; Борнхёвд, Кристоф; Ленер, Вольфганг. Графическая история базы данных SAP HANA (PDF) . Конспект лекций по информатике .
  38. ^ Ванян, Джонатан (18 февраля 2015). «Связанный с АНБ Sqrrl внимательно следит за кибербезопасностью и получает финансирование в размере 7 миллионов долларов» . Гигаом . Проверено 9 мая 2017 года .
  39. ^ Woodie, Alex (23 октября 2015). «Искусство аналитики, или чему нас могут научить зеленые волосы» . Датанами . Проверено 9 мая 2017 года .
  40. ^ «Forrester Wave ™: платформы графических данных, 4 квартал 2020 г.» . aws . 16 ноя 2020 . Проверено 16 ноября, 2020 .
  41. ↑ Свенссон, Йохан (5 июля 2016 г.). «Гостевая точка зрения: реляционные и графические базы данных: какие и когда использовать?» . Сан-Диего Таймс . БЖ Медиа . Проверено 30 августа +2016 .
  42. ^ TinkerPop, Apache. "Apache TinkerPop" . Apache TinkerPop . Проверено 2 ноября 2016 .