Что сложного в реляционной базе данных решает графовая база данных?

У меня есть клиент, который понимает, что его модель данных — это ориентированный ациклический граф. Мы работали с наборами узлов и промежуточной таблицей ребер, и производительность была довольно хорошей. В текущей реализации у нас менее 100 000 узлов данных, хотя это число может вырасти на один или два порядка. Недавно он убедился, что, поскольку у нас есть граф, база данных графов (например, Neo4J или Titan) была бы «лучше».

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


nosql relational-database graph-databases
person Elf Sternberg    schedule 20.11.2012    source источник
comment
Я считаю, что это не столько количество узлов, сколько глубина обхода, необходимая для различных запросов. Конечно, существуют подходы к реляционным базам данных, такие как вложенный набор и иерархические идентификаторы и соединения, но они часто предназначены для работы с деревьями и не обязательно имеют менее строгие ограничения DAG. Конечно, поскольку пост намекает на отдельные таблицы узлов/ребер, я подозреваю, что DAG уже используются, что затем возвращается к глубине обхода.   -  person    schedule 21.11.2012

Ответы (3)


arrow_upward
1
arrow_downward

В реляционной базе данных узлы и ребра будут связаны некоторым общим значением. Поиск узла или ребра обычно включает запрос индекса для этого значения.

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

person antlersoft    schedule 20.11.2012

arrow_upward
0
arrow_downward

на самом деле это правда, точно так же, как mongo имеет встроенные функции базы данных «геопространственные», поэтому ему не нужно обрабатывать столько, сколько если бы вы хотели сделать это с помощью mysql. Две упомянутые вами базы данных (я работал с титаном) просто лучше подходят для построения графиков, и они не будут такими суровыми для ваших операторов php или db.

person Dnaso    schedule 20.11.2012

arrow_upward
0
arrow_downward

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

Не имея опыта работы с вышеупомянутыми графовыми базами данных, я могу только предположить, что вы можете получить от таких баз данных более быструю разработку, поскольку ваша база данных будет лучше соответствовать типу данных, которые у вас есть. Я много работал с MongoDB, и вишенкой на торте для меня была скорость разработки из-за простоты запроса/записи в базу данных, сопровождаемой гораздо более богатыми структурами документов без необходимости определять какие-либо схемы. Вы также получаете некоторые замечательные функции, такие как сверхпростая репликация, автоматический переход на другой ресурс, автоматическое сегментирование и т. д., но в вашем случае всего со 100 000 документов вы вряд ли подумаете о таких проблемах в ближайшее время. Все основные реляционные базы данных могут работать на небольшом сервере и хорошо работать с таким объемом документации.

person snez    schedule 20.11.2012