Шумиха вокруг графовых баз данных, почему?

Существует некоторая шумиха вокруг графовых баз данных. Интересно почему.

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

По теме: https://stackoverflow.com/questions/1000162/has-anyone-used-graph-based-databases-http-neo4j-org


neo4j graph-databases orientdb rexster
person amirouche    schedule 21.07.2009    source источник
comment
Некоторые ответы вы найдете в этих двух потоках stackoverflow: - Какие примеры проблем лучше всего решать с помощью графиков? - https://stackoverflow.com/questions/1000162/have-anyone-used-graph-based-databases-http-neo4j-org Что касается классических приложений, эта вики-страница Neo4j может представлять интерес: Галерея моделирования домена (это я написал).   -  person nawroth    schedule 22.07.2009

Ответы (2)


arrow_upward
21
arrow_downward

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

Например, если кто-то хочет связный набор всех узлов, где ребра удовлетворяют заданному предикату, начиная с заданного узла, в SQL нет естественного способа выразить это. Скорее всего, вы либо выполните запрос для ребер с предикатом, а затем локально исключаете отключенные ребра, либо будете вести очень подробный разговор с сервером базы данных, следуя одному набору ссылок на следующий в повторяющихся запросах.

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

person Barry Kelly    schedule 21.07.2009
comment
Транзитивное закрытие может не быть частью стандарта SQL (и, по-видимому, его сложно реализовать в общем случае, или это сделали бы другие поставщики), но его нетрудно реализовать для конкретного приложения с использованием хранимых процедур. - person finnw; 21.07.2009
comment
Точно; но необходимость писать специальные запросы в качестве хранимых процедур может помешать вашему стилю. - person Barry Kelly; 21.07.2009
comment
@finnw Проблема не в том, чтобы это сделать, проблема в эффективности и производительности. Чтобы получить хорошую производительность чтения, вам придется пожертвовать производительностью вставки и тратить много места на диске. Эта статья: codeproject.com/KB/database/Modeling_DAGs_on_SQL_DBs.aspx описывает, как это можно сделать с помощью хранимых процедур для вставки и обычного SQL для чтения. - person nawroth; 22.07.2009
comment
И еще я верю, насколько элегантно / естественно можно решать проблемы. Вот почему люди предпочитают разные языки программирования, и поэтому люди могут предпочесть разные хранилища данных. - person Eelco; 09.06.2011
comment
Вы можете выполнять транзитивное замыкание в стандартном SQL - вы можете использовать рекурсивные общие табличные выражения. Я использовал их в PostgreSQL и MS SQL Server, и я считаю, что они поддерживаются другими ведущими СУБД. Синтаксис немного неуклюжий, но он действительно интересен, если вы освоите его. Однако я подозреваю, что они не так быстры, как эквивалентные запросы в базе данных графов. - person Tom Anderson; 08.08.2012
comment
@TomAnderson совершенно верно, и я использовал их в Postgres. Но они, по сути, являются серверной итерацией запросов. Без конкретных индексов они не будут такими быстрыми, как что-то специально созданное. - person Barry Kelly; 27.02.2014

arrow_upward
4
arrow_downward

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

person empi    schedule 21.07.2009