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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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