Войти
В вычислениях, база данных графиков (GDB ) - это база данных, которая использует структуру графа для семантических запросов с узлами, ребрами и свойства для представления и хранить данные. Ключевым понятием системы является граф (или ребро, или взаимосвязь). График связывает элементы данных в хранилище с набором узлов и ребер, причем ребра соответствует отношениям между узлами. Связи позволяет напрямую связывать данные в хранилище и во многих случаях извлекать их с помощью одной операции. В базах данных Graph отношения между приоритетными данными. Запрос отношений выполняется быстро, потому что они постоянно хранятся в базе данных. Отношения можно интуитивно визуализировать с помощью графовых базовых данных, что делает их полезными для сильно взаимосвязанных данных.
Графовые базы данных - это тип базы данных NoSQL, созданный для предотвращения ограничений реляционных баз данных. В то время как модель графа явно определяет зависимости между узлами данных, реляционная модель и другие модели базовых данных NoSQL связывают данные неявными связями. Другими словами, отношения - это первоклассный гражданин в базе данных графа, и их можно маркировать, направлять и задавать свойства. Это сравнивается с реляционными подходами, которые подразумеваются и уточняются во время выполнения. Базы данных графов похожи на базы данных сетевые модели 1970-х годов в том, что обе они предоставляют общие графы, но базы данных сетевые модели работают на более низком уровне абстракции и не имеют простого обхода по цепочке ребер.
Базовый механизм хранения графовых баз данных может варьироваться. Некоторые из них зависят от реляционного механизма и «хранятся» данные графа в таблице (хотя таблица является логической, поэтому этот подход накладывает другой уровень абстракции между базовыми данными графа, системой управления базой данных графа и физических устройств, на которых фактически хранятся данные). Другие используют для хранения хранилище «ключ-значение» или документно-ориентированную базу данных, что делает их по сути структурами NoSQL.
Для получения данных из базы данных графа требуется язык запросов, отличный от SQL, который был разработан для обработки данных в реляционной системе и поэтому не может «элегантно» дескриптор обхода графа. По состоянию на 2017 год принят один универсальный язык запросов графов, так как SQL был принят для реляционных баз данных, и существует большое количество систем, чаще всего связанных с одним продуктом. Были предприняты некоторые усилия по стандартизации, что привело к созданию языков запросов от различных поставщиков, таких как Gremlin, SPARQL и Cypher. Помимо интерфейса запросов языков, доступ к некоторым базам данных графов осуществляется через интерфейс прикладного программирования (API).
Графические базы данных отличаются от графических вычислительных машин. Графические базы данных - это технологии, которые являются трансляциями реляционных баз данных транзакций транзакций (OLTP). С другой стороны, вычислительные машины графов используются в оперативной аналитической обработке (OLAP) для массового анализа. Графические базы данных привлекли к себе внимание в 2000-х годах Графические базы данных благодаря успехам крупных технологических корпораций в собственных базовых данных, а также внедрению графовых баз данных с открытым исходным кодом.
В середине 1960-х навигационные базы данных, такие как IBM IMS поддерживали дерево -подобные структуры в его иерархической модели, но строгую древовидную структуру можно обойти с помощью виртуальных записей.
Графические структуры могут быть представлены в базах данных сетевых моделей с конца 1960-х гг. CODASYL, который определил COBOL в 1959 году, определил язык сетевой базы данных в 1969 году.
Помеченные графы могли быть представлены в качестве базовых данных с середины 1980-х годов, например в качестве логической модели данных.
В начале 1990-х годов появилось несколько улучшенных графовых баз данных, которые ускорились в конце 1990-х с попытками индексировать веб-страницы.
В середине-конце 2000-х стали доступны коммерческие графические базы данных с гарантией ACID, такие как Neo4j и Oracle Spatial and Graph.
В 2010-х стали доступны коммерческие базы данных графов ACID, которые можно масштабировать по горизонтали. Кроме того, SAP HANA привнес в графические базы данных технологии in-memory и columnar. Также в 2010-х годах стали доступны многомодельные базы данных, которые поддерживали модели графов (и другие модели, такие как реляционная база данных или документно-ориентированная база данных ), например OrientDB, ArangoDB и MarkLogic (начиная с его версии 7.0). За это время графические базы данных различных типов популярных социальных сетей с созданием компаний, занимающихся социальными сетями.
Графические базы данных используют узлы, свойства и ребра. Графические базы данных отображают данные в том виде, в каком они рассматриваются концептуально. Это достигается путем передачи данных в узлы и их отношения в ребра.
База данных графов - это база данных, основанная на теории графов. Он состоит из набора объектов, который может быть узлом или ребром.
Модель графа помеченных представлен набором узлов, отношений, свойств и меток. Оба узла и их отношения имеют имена и могут хранить свойства, представленные парами «ключ / значение» . Узлы можно пометить для группировки. Ребра, обеспечивающие отношения, обладают двумя качествами: они всегда имеют начальный узел и конечный узел и оказываются; превращение графа в ориентированный граф. Отношения также могут иметь свойства. Это предоставляет для дополнительных метаданных и семантики взаимосвязей узлов. Прямое хранение отношений позволяет константное время обход.
Пример графа RDF В модели графа RDF, каждое добавление информации представленное узлом. Например, представьте сценарий, в котором пользователь должен добавить свойство имени для человека, представленного в виде отдельного узла на графике. В модели графа помеченных свойств это может быть сделано путем добавления свойств имени в узел человека. Однако в RDF пользователь должен добавить отдельный узел с именем hasName, соединяющий его с исходным узлом person. В частности, модель графа RDF состоит из узлов и дуг. Обозначение графа RDF или оператор представлен: узлом для субъекта, узлом для объекта и дугой для предиката. Узел может быть оставлен пустым, может быть литералом и / или идентифицирован URI. Дуга также может быть идентифицирована с помощью URI. Литерал для узла может быть двух типов: простой (нетипизированный) и типизированный. Обычная литерал имеет лексическую форму и, возможно, языковой тег. Типизированный литерал из строки с URI, который идентифицирует конкретный тип данных. Пустой узел может установить для точной иллюстрации состояния данных, когда данные не имеют URI.
. Он используется в протоколе Open Graph Facebook, чтобы «разрешить любую веб-страницу. иметь ту же функциональность, что и любой другой объект на Facebook »и Семантическая сеть.
Графические базы данных являются мощным инструментом для графоподобных запросов. Например, вычисление кратчайшего пути между двумя узлами графа. Другие графоподобные запросы на базе данных графов естественным образом (например, вычисление диаметра графа или обнаружение сообщества).
Графики гибкие, то есть они позволяют пользователю вставлять новые данные в существующий граф без функциональности приложения. Разработчику базы данных не нужно планировать подробные сведения о будущих сценариях использования базы данных.
Базовый механизм хранения графовых баз данных может различаться. Некоторые из них зависят от реляционного механизма и «хранятся» данные графа в таблице (хотя таблица является логической, поэтому этот подход накладывает другой уровень абстракции между базовыми данными графа, системой управления базой данных графа и физических устройств, на которых фактически хранятся данные). Другие используют для хранения хранилище ключей и значений или документно-ориентированную базу данных, что делает их по своей сути структурми NoSQL. Узел будет представлен как любое другое хранилище документов, которые связывают два разных узла, специальные атрибуты внутри его документа; атрибуты _от и _то.
Производительность поиска данных зависит от скорости доступа от одного узла к другому. Позволяет свободная от индекса иметь прямые физические физические адреса RAM и физически указывать на другие соседние узлы, это приводит к быстрому поиску. Собственная система графов с безиндексной структурой не должна перемещаться через какие-либо другие структурные данные, чтобы найти связи между узлами. Непосредственно связанные узлы в графе сохраняются в кэше после извлечения одного из узлов, что делает поиск данных даже быстрее, чем в первый раз, когда пользователь выбирает узел. Однако за такое преимущество платить приходится. безиндексная способность приносит в жертву запросов, которые не используют обход графа. Базы данных с собственными графами используют безиндексную способность для обработки операций CRUD с сохраненными данными.
Есть несколько типов графиков, которые можно разделить на категории. Gartner предлагает пять широких категорий графиков:
Начало с Статья Эдгара Ф. Кодда 1970 года о реляционной модели, реляционных базах данных был де-факто отраслевым стандартом для крупномасштабных систем хранения данных. Однако реляционные модели требуют строгой, и нормализации данных накладывает ограничения на то, как схемы можно запрашивать отношения.
Традиционно базы данных разработаны с использованием реляционной модели, данные которой нормализованы для поддержки транзакций ACID. В процессе нормализации данных удаляются все повторяющиеся данные в базе данных. Цель нормализации данных - сохранить согласованность данных. Реляционная модель применяет транзакции ACID, разделяя данные на множество таблиц.
Реляционные модели требуют стабилизации больших данных, чтобы согласованность. Одним из мотивов проектирования реляционной модели было достижение быстрого построчного доступа. Проблемы возникают тогда, когда возникает необходимость сформировать сложные отношения между хранимыми данными. Хотя отношения можно анализировать с помощью реляционной модели, требуются сложные запросы, выполняемые операции множества различных атрибутов в нескольких таблицах. При работе с реляционными моделями ограничения внешнего ключа также следует учитывать при извлечении отношений.
По сравнению реляционными базами данных графовые базы данных часто работают быстрее для ассоциативных наборов данных и более точно в структуре объектно-ориентированных приложений. Они могут более естественно масштабироваться до больших наборов данных, поскольку обычно не требуются операции join, которые часто могут быть дорогостоящими. Они меньше зависят от жесткой схемы, они продаются как более подходящие для управления специальными и изменяемыми данными с помощью системы схем.
И наоборот, системы управления реляционными базами данных обычно быстрее выполняют ту же операцию с большим количеством элементов данных, что позволяет манипулировать данными в их естественной структуре. Несмотря на преимущества графической базы данных, рекомендуется, чтобы сама графовая модель не была единственной причиной замены существующей реляционной базы данных. База данных графов может стать актуальной, если есть свидетельства повышения производительности на порядки и более низкой задержки.
Реляционная модель собирает данные вместе, используя информацию в данных. Например, можно искать всех «пользователей», номер телефона которого содержит код города «311». Это можно сделать путем поиска в выбранных хранилищах данных или таблицах, ища в полях выбранных номера телефона строку «311». В больших таблицах это может занять много времени, поэтому реляционные базы данных индексы, которые позволяют хранить данные в меньших подтаблице, содержащих только выбранные данные и уникальный ключ (или первичный ключ) записи. Если номера телефонов проиндексированы, такой же поиск будет произведен в меньшей индексной таблице, собирая ключи совпадающих записей, а затем ища в основной таблице данных с этими ключами. Обычно таблица хранится таким образом, чтобы поиск по ключу происходил очень быстро.
Реляционные данные по своей сути не содержат идеи базы данных между основными отношениями. Вместо этого связываются данные друг с другом путем уникального ключа одной записи в другую запись. Например, таблица, содержащая адрес электронной почты для пользователей, может содержать элемент данных с именем userpk, который содержит первичный ключ записи пользователя, с которым он связан. Чтобы связать пользователей и их адреса электронной почты, система сначала ищет первичные ключи записей выбранных пользователей, ищет эти ключи в столбце userpkв таблице электронной почты (или, что более вероятно, их индекс.), Извлекает данные электронной почты, а затем связывает записи пользователя и электронную почту для создания составных записей, все выбранные данные. Эта операция, называемая соединением, может быть дорогостоящей в вычислительном отношении. В зависимости от сложности запроса, количества объединений и индексации различных ключей системе может потребоваться выполнить поиск по нескольким таблицам и индексам, а затем сортировать все это, чтобы сопоставить их вместе.
В отличие от графических баз данных напрямую хранят отношения между записями. Вместо того, чтобы найти адрес электронной почты путем поиска ключа пользователя в столбце userpk, запись пользователя содержит указатель, который напрямую ссылается на запись адреса электронной почты. То есть, выбрав пользователя, можно переходить по указателю прямо к записям электронной почты, нет необходимости искать в таблице электронной почты соответствующие записи. Это может устранить дорогостоящие операции соединения. Например, если кто-то ищет все адреса электронной почты для пользователей с кодом области «311», машина сначала выполнит обычный поиск, чтобы найти пользователей в «311», но затем получит адреса электронной почты, перейдя по ссылкам, найденным в те записи. Реляционная база данных сначала найдет всех пользователей в «311», извлечет список первичных ключей, выполнит еще один поиск любых записей в таблице электронной почты с этими первичными ключами и свяжет соответствующие записи вместе. Для этих типов общих операций графические базы данных теоретически были бы быстрее.
Истинная ценность графового подхода становится очевидной, когда выполняется поиск, глубина которого превышает один уровень. Например, рассмотрим поиск пользователей, у которых есть «подписчики» (таблица, связывающая пользователей с другими пользователями) в коде зоны «311». В этом случае реляционная база данных должна сначала выполнить поиск всех пользователей с кодом области в «311», затем выполнить поиск в таблице подписчиков для любого из этих пользователей, а затем, наконец, выполнить поиск в таблице пользователей, чтобы найти подходящих пользователей. Напротив, графическая база данных будет искать всех пользователей в «311», а затем следовать по обратным ссылкам через отношения подписчика, чтобы найти пользователей-подписчиков. Это позволяет избежать нескольких поисков, просмотров и использования памяти, связанного с хранением всех временных данных из нескольких записей, необходимых для построения вывода. В терминах нотации большого O этот запрос будет иметь вид 
Относительное преимущество извлечения графа растет с увеличением сложности запроса. Например, кто-то может захотеть узнать «этот фильм о подводных лодках с актером, который был в этом фильме, с другим актером, который играл главную роль в Унесенные ветром ». Сначала система должна найти актеров в «Унесенных ветром», найти все фильмы, в которых они были, найти всех актеров во всех тех фильмах, которые не были главными в «Унесенных ветром», а затем найти все фильмы. они были в, наконец отфильтровали этот список до тех, в описании которых было слово «подводная лодка». В реляционной базе данных это потребует нескольких отдельных поисков по таблицам фильмов и актеров, выполнения еще одного поиска по фильмам о подводных лодках, поиска всех актеров в этих фильмах и последующего сравнения (больших) собранных результатов. В отличие от этого, графическая база данных будет переходить от «Унесенных ветром» к Кларку Гейблу, собирать ссылки на фильмы, в которых он был, собирать ссылки из этих фильмов на других актеров, а затем переходить по ссылкам. из этих актеров обратно в список фильмов. Затем в полученном списке фильмов можно выполнить поиск по запросу «подводная лодка». Все это можно сделать с помощью одного поиска.
Свойства добавляют к этой структуре еще один уровень абстракции, который также улучшает многие общие запросы. По сути, свойства - это метки, которые можно применить к любой записи, а в некоторых случаях и к краям. Например, можно обозначить Кларка Гейбла «актером», что позволит системе быстро находить все записи с актерами, а не с режиссером или оператором. Если метки на краях разрешены, можно также обозначить отношения между Унесенными ветром и Кларком Гейблом как «ведущие», и, выполнив поиск людей, которые являются «ведущими» «актерами» в фильме «Унесенные ветром», база данных создала бы Вивьен Ли, Оливию де Хэвилленд и Кларк Гейбл. Эквивалентный запрос SQL должен полагаться на добавленные данные в таблице, связывающей людей и фильмы, что усложняет синтаксис запроса. Эти виды меток могут улучшить производительность поиска при определенных обстоятельствах, но, как правило, они более полезны при предоставлении дополнительных семантических данных для конечных пользователей.
Реляционные базы данных очень хорошо подходят для плоских макетов данных, где взаимосвязь между данными является одной или два уровня в глубину. Например, в базе данных бухгалтерского учета может потребоваться поиск всех позиций для всех счетов-фактур для данного клиента, запрос с тремя соединениями. Базы данных 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) WHERE p1.person_name = 'Jack';
Тот же запрос может быть переведен на -
MATCH (p1: person) - [: FRIEND-WITH] - (p2: person) WHERE p1.name = "Jack" RETURN p2.name
