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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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

Для более тщательной оценки сильных сторон баз данных графов и реляционных хранилищ существует (бесплатная!) книга O'Reilly под названием "Графические базы данных" (caveat: Я - один из авторов книги), доступный в http://graphdatabases.com. Он не будет свободен навсегда, поскольку он является надлежащей книгой О'Рейли, но у нас есть разрешение издателя отдать немало, поэтому получите его сейчас.

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

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

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

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