Алгоритмы поиска графа, который представляет релевантность для определенного ключевого слова - PullRequest
1 голос
/ 17 июня 2011

У меня есть график (и это график, поскольку у одного узла может быть много родителей), который содержит узлы со следующими данными:

  • Идентификатор ключевого слова
  • Метка ключевого слова
  • Количество предыдущих поисков
  • Глубина продвижения по ключевым словам

Релевантность оценивается числом, начинающимся с 1.
Релевантность дочернего узла определяетсяНа расстоянии от родительского узла дочерний узел минус глубина продвижения ключевого слова.
Порядок отображения дочерних узлов с той же глубиной определяется числом предыдущих поисков.
Существует ли алгоритм, которыйМожно ли искать такую ​​структуру данных?
Есть ли у меня проблема с эффективностью, если мне нужно пересечь все узлы, кэшировать сгенерированный результат и отобразить их по страницам, учитывая, что это должно хорошо масштабироваться для большого количества пользователей?Если у меня есть проблема, как это можно решить?
Какую базу данных мне нужно использовать?NoSQL, реляционная или графическая база данных?
Как будет выглядеть схема?
Можно ли это сделать с помощью django-haystack ?

1 Ответ

3 голосов
/ 17 июня 2011

Кажется, вы пытаетесь вычислить запрос top-k по графику. Существует множество алгоритмов, подходящих для решения этой проблемы, и я полагаю, что самый простой из них поможет вам решить вашу проблему - это Пороговый алгоритм (TA) , когда обход по графику выполняется в режиме BFS , Некоторые другие алгоритмы top-k: Процедура Лоулера-Мёрти , и существуют другие варианты TA.

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

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

Последнее, но не менее важное - стог сена. Поскольку стог сена будет работать со всем, с чем будет работать выбранная вами поисковая система, должен быть хотя бы один из возможных способов сделать это (объединение Apache Solr для поиска и Neo4j или GoldenOrb для базы данных) и, возможно, больше (поскольку я не очень знаком с Haystack или поисковыми системами, которые он поддерживает, кроме Solr).

...