Выбор автономного поискового сервера с настраиваемой функцией ранжирования, пространственный поиск

Question

Я рассматриваю различные варианты выбора поискового сервера для проекта, в котором я участвую. Этот поисковый сервер используется для отображения результатов на веб-сайте знакомств, построенном в Rails, в котором поиск предоставляет все возможности поиска совпадений. «-magic.

Типичные запросы включают ранжирование документов / результатов с использованием выражения (в псевдокоде):

• Сортировка по рейтингу:
  • + 50, если атрибут has_image имеет значение true
  • + 10, если атрибут has_boost имеет значение true
  • + 50, если широта / долгота находятся в пределах 40 миль от [точки]
  • + 20, если широта / долгота находятся в пределах 80 миль [точка]
  • - (расстояние от атрибута age до 30)
• Фильтровать по:
  • Атрибут «возраст» между 25 и 35
  • Атрибут «пол» равен «мужской»

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

Природа проекта дает поисковому серверу со следующими свойствами:

• Spartial рейтинга
• Ранжирование результатов на основе пользовательской функции
• Фильтры атрибутов
• Масштабируемый и быстрый
• Free

Я нашел Sphinx, Solr и ElasticSearch, но все они (насколько я вижу) построены и оптимизированы для полнотекстового поиска, причем ES и Solr построены на Lucene, и я не знаю, что лучше всего подойдет для интенсивного поиска по фильтру / атрибуту.

Мои вопросы:

• Какой из этих серверов вы бы предпочли и почему?
• Я пропустил какие-либо другие очевидные варианты?

Answer 1

Не знаю о других, но Солр может сделать все это:

Пространственный рейтинг

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

Ранжирование результатов на основе пользовательской функции

У Solr есть множество запросов функций для повышения.

Фильтры атрибутов

Это обычная функция поиска.

Масштабируемый и быстрый

Многие крупные сайты используют Solr, что свидетельствует о его масштабируемости и скорости.

Free

Solr является лицензией Apache , очень разрешительная лицензия.

Answer 2

ElasticSearch также имеет все эти функции.

Поддерживаются географические расстояния / ограничивающие рамки / полигоны и настраиваемые сценарии оценки на разных языках: http://www.elasticsearch.com/docs/elasticsearch/rest_api/query_dsl/

У вас не будет проблем с производительностью фильтров или других типов запросов, мы делаемтяжелая фильтрация по нашим запросам со 100+ атрибутами в некоторых случаях, и это быстро.

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

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

Надеюсь, это поможет.

Пол

Answer 3

Вы не говорите о поисковой системе. Вы говорите о базе данных. в SQL фильтрация - это стандартная вещь SELECT; ранжирование может быть выполнено с помощью довольно грубого выражения, включающего множество CASE, а затем ORDER BY.

Чтобы выполнить пространственные части запроса, вам потребуется база данных с геопространственными элементами.

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

Answer 4

Я думаю, что в то время как вы могли бы использовать поисковик, такой как Solr или ES, для этого, я думаю, что "бизнес-правила", которые вы определили, означают, что вы в конечном итоге будете делать постыобработка.

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