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

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

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

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

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

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

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

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

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

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

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

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

1. Графические базы данных намного быстрее, чем реляционные базы данных для связанных данных - это сильная сторона базовой модели. Следствием этого является то, что задержка запроса в базе данных графа пропорциональна тому, какую часть графа вы выбираете для исследования в запросе, и не пропорциональна количеству хранимых данных, тем самым обезвреживая бомбу соединения .
2. Графические базы данных делают моделирование и выполнение запросов намного более приятными, что означает более быструю разработку и меньшее количество WTF-моментов. Например, выражение друга-друга для типичной социальной сети на языке запросов Neo4j Cypher - это просто MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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