Сфинкс / Solr / Lucene / Упругая Актуальность - PullRequest
1 голос
/ 17 августа 2010

У нас очень большая база данных из 30 с лишним миллионов продуктов, и нам нужно запрашивать их, чтобы создавать результаты поиска и показывать объявления тысячи раз в секунду.Мы рассматривали Sphinx, Solr, Lucene и Elastic как варианты для выполнения этих постоянных массовых поисков.

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

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

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

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

Спасибо за ваши ответы!

Ответы [ 2 ]

3 голосов
/ 18 августа 2010

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

  1. Lucene / Solr использует модель векторного пространства,Я не уверен, что вы имеете в виду, когда используете свой «собственный» алгоритм, но если он слишком далеко уходит от понятия tf / idf (скажем, с помощью нейронной сети), у вас будут трудности с подгонкойэто в люцене.Если по вашему собственному алгоритму вы просто подразумеваете, что хотите взвешивать определенные термины более тяжело, чем другие, это будет соответствовать.По сути, lucene хранит информацию о важности термина для документа.Если вы хотите переопределить расчет важности термина, это легко сделать.Если вы хотите отойти от всего понятия важности термина для документа, это будет проблемой.
  2. Lucene (и, как следствие, Solr) хранит вещи в своем собственном формате.Вам не нужно использовать базу данных.30 миллионов записей - это не очень большой индекс люцена (в зависимости, конечно, от того, насколько велика каждая запись).Если вы хотите использовать БД, используйте hadoop.
  3. В общем, вы захотите использовать Solr вместо Lucene.

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

1 голос
/ 17 августа 2010

Я действительно сделал нечто подобное с Solr. Я не могу комментировать детали, но в основном шаг проприетарного анализа / релевантности сгенерировал ряд поисковых терминов со связанными бустами и отправил их в Solr. Я думаю, что это можно сделать с помощью любой поисковой системы (все они поддерживают какое-то повышение).

В конечном итоге все сводится к тому, что требует ваш конкретный анализ.

...