Вопрос, я думаю, слишком расплывчатый и широкий, чтобы дать точный ответ ...
По сути, существуют некоторые методы эффективного запроса данных графа в базе данных SQL, которые применяются к узкоспециализированным сценариям. Вы можете выбрать индекс GRIPP, например, если ваши интересы лежат в поиске кратчайших путей. (Он в основном работает немного как предварительно упорядоченный индекс дерева, применяемый к графикам.) Насколько мне известно, ни один из этих методов пока не стандартизирован.
С учетом сказанного и просмотра вашего комментария, в котором упоминаются социальные сети, шансы на то, что каждый из них будет излишним. Если ваш интерес заключается прежде всего в получении данных, относящихся к друзьям пользователя, или в чем-то эквивалентном в том смысле, что он представляет собой запрос к окрестности узла, количество узлов, которые вам нужно пересекать в соединениях, настолько мало, что нет необходимости в специализированные инструменты, структуры данных и т. д .: просто используйте рекурсивные CTE.
http://www.postgresql.org/docs/current/static/queries-with.html
Для достижения оптимальной производительности при использовании последнего, переложить как многие where
условия в with (...)
части запроса, таким образом, чтобы исключить узлы рано.
В настоящее время потребности очень просты. Возможность моделирования отношений между сущностями и возможность эффективного запроса по графику, избегая объединения. Мой запрос заключается в том, есть ли для этого готовое готовое решение. Я прочитал - [graphs-in-the-database-sql-meet-social-networks] (http://techportal.inviqa.com/2009/09/07/graphs-in-the-database-sql-meets- социальные сети /), но было просто интересно, не хватает ли я какого-то очевидного решения. – jethar
Обычная мудрость, что графические базы данных лучше всего подходят для моделирования данных графа, может быть ошибочной в соответствии с данными исследователями IBM и Google https://research.google.com/pubs/archive/43287.pdf Как это может быть неправильно? Я думаю, это сводится к тому, что postgres просто очень хорошо. Трудно сделать БД, которая может противостоять постгресам в любой категории, и большинство попыток сделать это не удастся, даже для специальных случаев использования. – mako
Привет всем и @mako! Я очень рад видеть вас всех здесь. Этот вопрос так важен для меня, потому что я потратил 3 года на тестирование TitanDB в качестве младшего разработчика с версии от 0.5 до 1.0. У меня очень плохой опыт (проблема во мне?) С этими вещами. Каждый раз, когда я получал некоторые результаты в графическом моделировании, некоторая ошибка происходила и блокировала мое развитие. Но за эти 3 года я создал много проектов на Django + postgres и они lilving. –