Sphinx/Solr/Lucene/Elastic Relevancy

Question

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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