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

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

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

66 голосов | спросил user782220 24 +04002012-10-24T13:31:26+04:00312012bEurope/MoscowWed, 24 Oct 2012 13:31:26 +0400 2012, 13:31:26

5 ответов


0

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

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

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

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

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

ответил dan1111 24 +04002012-10-24T13:51:51+04:00312012bEurope/MoscowWed, 24 Oct 2012 13:51:51 +0400 2012, 13:51:51
0

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

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

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

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

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

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

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

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

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

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

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

ответил Walter Mitty 26 +04002012-10-26T09:12:10+04:00312012bEurope/MoscowFri, 26 Oct 2012 09:12:10 +0400 2012, 09:12:10
0

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

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

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

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

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

ответил Uli Bethke 16 J0000006Europe/Moscow 2017, 21:48:12
0

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

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

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

ответил Mohammad Akbari 2 +03002018-10-02T11:18:12+03:00312018bEurope/MoscowTue, 02 Oct 2018 11:18:12 +0300 2018, 11:18:12

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132