Графовые и реляционные модели данных

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

Поэтому, когда я слышу о таких вещах, как Neo4j и «графовые базы данных», мне трудно понять, чем они принципиально отличаются от реляционной модели, которая сама по себе является графом!

Самое главное, поскольку я не могу определить разницу между ними, мне трудно понять, какие проблемные области лучше всего решать с помощью графовой модели, а какие — с помощью реляционной модели. Я ищу набор рекомендаций, чтобы сказать: Эй, эта проблема определенно лучше всего представлена ​​графовой моделью, поэтому я буду использовать (скажем) Neo4j. Или, чтобы сказать: Эту проблему определенно лучше всего представляет реляционная модель, поэтому я буду использовать (скажем) MySQL.

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


mysql nosql relational-database neo4j graph-databases
person IAmYourFaja    schedule 17.07.2012    source источник
comment
Я понимаю ваше разочарование (у меня тоже было это с пониманием всех этих различных типов баз данных NoSQL), но, пожалуйста, отредактируйте этот пост в какой-то форме вопроса.   -  person JayC    schedule 17.07.2012

Ответы (4)


arrow_upward
0
arrow_downward

один из случаев, когда вы хотели бы использовать neo4j вместо реляционной БД:

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

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

если вы хотите узнать больше и углубиться в базу данных графов, я предлагаю вам прочитать что-нибудь о математических графах в целом (http://en.wikipedia.org/wiki/Graph), но это может быть слишком сложно понять в одиночку, если у вас нет сильной математической подготовки.

person ulkas    schedule 17.07.2012
comment
конечно, neo4j служит в первую очередь для больших наборов данных (~миллиардов примитивов), и поэтому бесполезно создавать на нем типичный веб-сайт. - person ulkas; 17.07.2012
comment
На самом деле он одинаково хорош для типичных веб-сайтов... Я не думаю, что он подходит только для больших наборов данных. - person Luanne; 17.07.2012
comment
В последнем абзаце вы могли бы смягчить покровительственное предположение, что ваш читатель не понимает и не может понять, что такое график. - person jameshfisher; 10.10.2014

arrow_upward
1
arrow_downward

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

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

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

Objectivity, Inc., компания, стоящая за InfiniteGraph, предлагает несколько хороших вариантов использования и интерактивные демонстрации, которые вы можете посмотреть (http://objectivity.com/resources). Размышление о том, как решить демонстрацию LinkHunter с реляционной базой данных в спорное время, может помочь понять базы данных графов.

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

С уважением, Тимо

person Timo Wagner    schedule 18.07.2012

arrow_upward
0
arrow_downward

Может быть, вы даже можете посмотреть на http://docs.neo4j.org/chunked/snapshot/what-is-a-graphdb.html и http://docs.neo4j.org/chunked/snapshot/data-modeling-examples.html, сравнение на http://docs.neo4j.org/chunked/snapshot/examples-from-sql-to-cypher.html

person Peter Neubauer    schedule 17.07.2012

arrow_upward
0
arrow_downward

Как вы сказали, Graph и Relational DB могут выглядеть одинаково по структуре, если вы сравниваете узел со строками и отношения с таблицей, а свойства со столбцами.

Но основное отличие заключается в том, как мы получаем доступ к данным.

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

Используйте Graph DB для поддержания отношений и дополнительной информации об этих узлах (связанных) в RDBMS. Вы можете использовать их оба в одном приложении, если у приложения есть требование.

person user2756260    schedule 03.01.2014