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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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