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

92

Может ли кто-нибудь объяснить мне преимущества и недостатки базы данных отношений, такой как MySQL, по сравнению с базой данных графов, такой как Neo4j?

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

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

Ответы:

119

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

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

Это имеет важные последствия:

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

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

dan1111
источник
17
Хранение отношений на уровне записи имеет смысл и в других случаях, поскольку оно обеспечивает безиндексную смежность. То есть обход графа может выполняться без поиска по индексу, что приводит к гораздо большей производительности. И это не дублирование, поскольку вы храните фактические отношения, которые отличаются.
nawroth
4
Вы говорите: «В базе данных графа каждая запись должна быть исследована индивидуально во время запроса, чтобы определить структуру данных». Это универсальное свойство графовых баз данных или более-менее верно в целом? Как насчет OrientDb, который поддерживает полную схему для вершин и ребер?
Lodewijk Bogaards
@LodewijkBogaards некоторые базы данных графов, такие как Neo4j, допускают базовое индексирование. Если запрос попадает в индексы, я считаю, что нет необходимости определять структуру данных, стоящих за индексом. Но это зависит от запроса.
Vojtěch Vít
3
Я категорически не согласен с обоими пунктами. База данных Graph всегда работает быстрее, когда есть внешние ключи. Потому что нам не нужны операции соединения. Реляционные базы данных должны хранить внешний ключ во многих таблицах. Ребро и внешний ключ должны занимать одно и то же место для хранения.
cegprakash
3
@cegprakash У вас также есть документация, из которой мы можем сделать то же самое?
Виктор
100

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

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

Как намекнул Dan1111, большинство графовых баз данных не испытывают такой боли при соединении, потому что они выражают отношения на фундаментальном уровне. То есть отношения физически существуют на диске, и они именуются, направляются и сами могут быть украшены свойствами (это называется моделью графа свойств, см .: https://github.com/tinkerpop/blueprints/wiki/Property-Graph -Модель ). Это означает, что при желании вы можете посмотреть на отношения на диске и увидеть, как они «соединяются» с объектами. Следовательно, отношения являются первоклассными сущностями в базе данных графов и семантически намного сильнее, чем те подразумеваемые отношения, воплощенные во время выполнения в реляционном хранилище.

Так почему тебе это должно быть до По двум причинам:

  1. Графические базы данных намного быстрее, чем реляционные базы данных для связанных данных - это сильная сторона базовой модели. Следствием этого является то, что задержка запроса в базе данных графа пропорциональна тому, какую часть графа вы выбираете для исследования в запросе, и не пропорциональна количеству хранимых данных, тем самым обезвреживая бомбу соединения .
  2. Графические базы данных делают моделирование и выполнение запросов намного более приятными, что означает более быструю разработку и меньшее количество WTF-моментов. Например, выражение друга-друга для типичной социальной сети на языке запросов Neo4j Cypher - это просто MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.
Джим Уэббер
источник
3
«Следовательно, отношения - это первоклассные сущности в базе данных графа». То же самое обычно верно и в реляционной базе данных: сущности отображаются в кортежи в отношениях, как и отношения «многие-многие». Вы описываете различие между отношениями «один-много», которые часто объединяются в отношения сущностей?
beldaz
54
Это сравнение кажется немного необъективным. А как насчет недостатков?
Куррен
12
Маленький? Слишком пристрастен, по моему честному мнению. В лучшем случае мне кажется, что это реклама "Это хороший товар! Купите это"!
ilgaar
39
Это требует массивного нюанса: этот парень «главный ученый» в Neo технологии, которые делают базу данных Neo4j график.
Роб Грант
5
Как насчет произвольного поиска ... дайте мне всех пользователей в возрасте от 35 до 55 лет, которые делают покупки в Walmart за последние 90 дней.
Мэтью
21

Dan1111 уже дал ответ, помеченный как правильный. Попутно стоит отметить пару дополнительных моментов.

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

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

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

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

Когда веб-страница перемещается на другой URL-адрес, не оставляя адреса пересылки на старом URL-адресе, неизвестное количество гиперссылок становится неработающим. Эти неработающие ссылки затем вызывают ужасное сообщение «Ошибка 404: страница не найдена», которое мешает многим пользователям получать удовольствие.

Уолтер Митти
источник
4
Только в большинстве графовых баз данных есть правила целостности, не допускающие неработающих ссылок.
Michael Hunger
1
Если СУБД закрепляет цель, это, очевидно, предотвратит разрыв связи из-за перемещения цели ссылки. Я не знаю ни одной графической базы данных, в которой бы не закреплялись записи, которые могли бы быть объектами ссылок.
Уолтер Митти
Графовые базы данных обычно не содержат схемы, потому что изменение схемы было бы очень тяжелой операцией из-за необходимости переписывать все указатели? Можно ли обойти проблему перетасовки, просто сохранив виртуальные указатели, которые проходят через таблицу поиска? Это все равно будет работать на O (1), верно?
Lodewijk Bogaards
Я работаю в соответствии с определением графовых баз данных, которые будут включать в себя реляционные базы данных, такие как иерархические или сетевые. Некоторые из этих баз данных имели схемы, хотя и не реляционные. Я не уверен, согласуется ли мое рабочее определение со стандартным определением.
Уолтер Митти
Структура данных, которая обеспечивает отображение между виртуальными указателями и физическими указателями, по сути то же самое, что индекс, с примерно такими же затратами. Вы могли бы также пойти дальше и использовать реляционную базу данных.
Уолтер Митти
7

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

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

В определенных ситуациях легче изменить модель данных в базе данных графа, чем в РСУБД, например, в РСУБД, если я изменю отношение таблицы с 1: n на m: n, мне нужно применить DDL с возможным временем простоя.

С другой стороны, СУБД имеет преимущества в других областях, например, при агрегировании данных или управлении версиями данных с метками времени.

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

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

Хотя реляционная модель может легко представить данные, содержащиеся в модели графа, на практике мы сталкиваемся с двумя серьезными проблемами:

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

Ссылка: Базы данных следующего поколения

Мохаммад Акбари
источник
0

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

Реляционная база данных работает намного быстрее при работе с огромным количеством записей (первый пункт списка dan1111)

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

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

Хотя эти утверждения вполне могут иметь свои достоинства, мне еще предстоит найти способ согласовать с ними мой конкретный вариант использования. Ссылка: Graph Database или Relational Database Common Table Extensions: Сравнение производительности запросов ациклических графов

user3105510
источник
0

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

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

Раджендра V
источник