Сравнение реляционных баз данных и графовых баз данных
Может ли кто-нибудь объяснить мне преимущества и недостатки реляционной базы данных, такой как MySQL, по сравнению с графовой базой данных, такой как Neo4j?
В SQL у вас есть несколько таблиц с различными идентификаторами, связывающими их. Затем вы должны присоединиться, чтобы соединить таблицы. С точки зрения новичка, зачем вам проектировать базу данных так, чтобы она требовала объединения, а не того, чтобы с самого начала соединения были явными как ребра, как с базой данных графа. Концептуально это не было бы смысла для новичка. Предположительно, есть очень техническая, но не концептуальная причина для этого?
8 ответов
Там на самом деле есть концептуальное обоснование обоих стилей. Википедия по реляционным моделям и графовым базам данных дает хороший обзор этого.
Основное отличие состоит в том, что в графической базе данных отношения хранятся на уровне отдельных записей, тогда как в реляционной базе данных структура определяется на более высоком уровне (определения таблиц).
Это имеет важные последствия:
- Реляционная база данных намного быстрее при работе с огромным количеством записей. В графической базе данных каждая запись должна проверяться индивидуально во время запроса, чтобы определить структуру данных, в то время как это известно заранее в реляционной базе данных.
- Реляционные базы данных используют меньше места для хранения, потому что им не нужно хранить все эти отношения.
Хранение всех отношений на уровне отдельных записей имеет смысл только в том случае, если в отношениях будет много вариаций; в противном случае вы просто дублируете одни и те же вещи снова и снова. Это означает, что графовые базы данных хорошо подходят для нерегулярных, сложных структур. Но в реальном мире большинство баз данных требуют регулярных, относительно простых структур. Вот почему реляционные базы данных преобладают.
Основное различие между графом и реляционной базой данных состоит в том, что реляционные базы данных работают с наборами, в то время как графовые базы данных работают с путями.
Это проявляется неожиданным и бесполезным образом для пользователя СУБД. Например, при попытке эмулировать операции пути (например, друзей друзей) путем рекурсивного присоединения к реляционной базе данных задержка запроса растет непредсказуемо и массово, так же как и использование памяти, не говоря уже о том, что он мучает SQL для выражения операций такого рода. Чем больше данных, тем медленнее в базе данных, основанной на множествах, даже если вы можете отложить боль за счет разумной индексации.
Как намекнул Dan1111, большинство графовых баз данных не испытывают такого рода боли соединения, потому что они выражают отношения на фундаментальном уровне. То есть отношения физически существуют на диске, и они именуются, направляются и сами могут быть украшены свойствами (это называется моделью графа свойств, см.: https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model). Это означает, что если вы захотите, вы можете посмотреть на отношения на диске и посмотреть, как они "объединяют" сущности. Следовательно, отношения являются первоклассными объектами в базе данных графа и семантически намного сильнее, чем те подразумеваемые отношения, реализованные во время выполнения в реляционном хранилище.
Так почему тебя это должно волновать? По двум причинам:
- Графовые базы данных намного быстрее, чем реляционные базы данных для связанных данных - сильная сторона базовой модели. Следствием этого является то, что задержка запроса в базе данных графа пропорциональна тому, сколько графов вы выбираете для исследования в запросе, и не пропорциональна количеству хранимых данных, тем самым обезвреживая бомбу объединения.
- Графические базы данных делают моделирование и запросы намного более приятными, что означает более быструю разработку и меньшее количество моментов WTF. Например, выражение друга друга для типичной социальной сети на языке запросов Neo4j Cypher просто
MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf,
Dan1111 уже дал ответ, помеченный как правильный. Пара дополнительных моментов стоит отметить мимоходом.
Во-первых, почти во всех реализациях графовых баз данных записи "закреплены", поскольку существует неизвестное количество указателей, указывающих на запись в ее текущем местоположении. Это означает, что запись не может быть перенесена в новое местоположение, не оставив адрес пересылки в старом местоположении или не нарушив неизвестное количество указателей.
Теоретически можно перетасовать все записи одновременно и найти способ найти и исправить все указатели. На практике это операция, которая может занять несколько недель в большой графической базе данных, в течение которой база данных должна быть отключена. Это просто неосуществимо.
Напротив, в реляционной базе данных записи можно переставлять в довольно больших масштабах, и единственное, что нужно сделать, - это перестроить все индексы, которые были затронуты. Это довольно большая операция, но далеко не такая большая, как эквивалент для графической базы данных.
Второй момент, который стоит отметить, заключается в том, что всемирную паутину можно рассматривать как гигантскую базу графов. Веб-страницы содержат гиперссылки, а гиперссылки ссылаются, помимо прочего, на другие веб-страницы. Ссылка через URL, которые функционируют как указатели.
Когда веб-страница перемещается на другой URL, не оставляя адрес пересылки на старом URL, неизвестное количество гиперссылок будет прервано. Эти неработающие ссылки порождают страшное сообщение "Ошибка 404: страница не найдена", которое прерывает удовольствие многих серферов.
С помощью реляционной базы данных мы можем моделировать и запрашивать граф, используя внешние ключи и самостоятельные соединения. То, что СУБД содержат слово "реляционный", не означает, что они хорошо справляются с отношениями. Слово реляционный в СУРБД происходит от реляционной алгебры, а не от отношения. В СУБД сама связь не существует как отдельный объект. Он либо должен быть представлен явно в виде внешнего ключа, либо неявно как значение в таблице ссылок (при использовании универсального / универсального подхода к моделированию). Связи между наборами данных хранятся в самих данных.
Чем больше мы увеличиваем глубину поиска в реляционной базе данных, тем больше самообъединений нам нужно выполнить и тем больше страдает производительность нашего запроса. Чем глубже мы углубляемся в нашу иерархию, тем больше таблиц нам нужно объединить и тем медленнее становится наш запрос. Математически стоимость растет экспоненциально в реляционной базе данных. Другими словами, чем сложнее наши запросы и отношения, тем больше мы выигрываем от графика по сравнению с реляционной базой данных. У нас нет проблем с производительностью в базе данных графа при навигации по графику. Это потому, что база данных графа хранит отношения как отдельные объекты. Тем не менее, превосходная производительность чтения достигается за счет более медленной записи.
В определенных ситуациях проще изменить модель данных в базе данных графа, чем в СУБД, например, в СУБД, если я изменю отношение таблицы с 1:n на m:n. Мне нужно применить DDL с возможным временем простоя.
СУБД имеет, с другой стороны, преимущества в других областях, например, при агрегировании данных или выполнении контроля версий данных с метками времени.
Я обсуждаю некоторые другие плюсы и минусы в своем блоге о графовых базах данных для хранилищ данных
Хотя реляционная модель может легко представлять данные, содержащиеся в графовой модели, на практике мы сталкиваемся с двумя существенными проблемами:
- В SQL отсутствует синтаксис, позволяющий легко выполнять обход графов, особенно обходы, когда глубина неизвестна или не ограничена. Например, использовать SQL для определения друзей ваших друзей достаточно просто, но трудно решить проблему "степеней разделения".
- Производительность быстро падает, когда мы пересекаем график. Каждый уровень обхода значительно увеличивает время ответа на запрос.
Справка: Базы данных следующего поколения
Графические базы данных заслуживают изучения на предмет примеров использования, в которых они преуспевают, но у меня были причины подвергнуть сомнению некоторые утверждения в ответах выше. Особенно:
Реляционная база данных работает намного быстрее при работе с огромным количеством записей (первый пункт списка dan1111)
Графические базы данных намного быстрее, чем реляционные базы данных для связанных данных - сильная сторона базовой модели. Следствием этого является то, что задержка запроса в базе данных графа пропорциональна тому, какую часть графа вы выбираете для исследования в запросе, и не пропорциональна количеству хранимых данных, таким образом обезвреживая бомбу соединения. (Первый пункт Джима Уэббера)
Другими словами, чем сложнее наши запросы и отношения, тем больше пользы мы получаем от графа по сравнению с реляционной базой данных. (2-й абзац Ули Бетке)
Хотя эти утверждения вполне могут иметь свои достоинства, мне еще предстоит найти способ согласовать с ними мой конкретный вариант использования. Ссылка: База данных графиков или Расширения общих таблиц реляционной базы данных: Сравнение производительности запросов ациклических графов
Реляционные базы данных намного эффективнее хранят табличные данные. Несмотря на слово "реляционные" в их названии, реляционные базы данных гораздо менее эффективны при хранении или выражении отношений между хранимыми элементами данных. Термин "реляционный" в реляционных базах данных больше относится к взаимосвязанным столбцам в таблице, а не к информации в разных таблицах. Связи между столбцами существуют для поддержки операций над наборами. Таким образом, по мере роста базы данных до миллионов или миллиардов записей получение данных из реляционных баз данных становится чрезвычайно медленным.
В отличие от реляционной базы данных, база данных графа полностью построена на отношениях данных. Базы данных Graph обрабатывают отношения не как структуру схемы, а как данные, как и другие значения. Получать данные из графовых баз данных очень быстро. С точки зрения реляционной базы данных это можно рассматривать как предварительную материализацию соединений JOIN один раз во время вставки, а не вычислять их для каждого запроса. Поскольку данные полностью структурированы вокруг взаимосвязей данных, производительность запросов в реальном времени может быть достигнута независимо от того, насколько велик или связан набор данных. Базы данных графа занимают больше места для хранения по сравнению с реляционной базой данных.
Реляционные базы данных, такие как MySQL, используют соединения и нормализацию для обеспечения согласованности данных и оптимизации хранения. Базы данных графов, такие как Neo4j, представляют отношения в виде ребер, обеспечивая более естественный и эффективный способ обработки взаимосвязанных данных, что делает их подходящими для сценариев со сложными отношениями.