Выбор автономного сервера полнотекстового поиска: Sphinx или SOLR? [закрыто]


192

Я ищу автономный сервер полнотекстового поиска со следующими свойствами:

  • Должен работать как отдельный сервер, который может обслуживать поисковые запросы от нескольких клиентов
  • Должен иметь возможность выполнять «массовую индексацию» путем индексации результата запроса SQL: скажем «SELECT id, text_to_index FROM Documents;»
  • Должно быть свободным программным обеспечением и должно работать на Linux с MySQL в качестве базы данных
  • Должно быть быстрым (исключает внутренний полнотекстовый поиск MySQL)

Я нашел альтернативы, которые имеют эти свойства:

  • Solr (по материалам Lucene)
  • ElasticSearch (также основанный на Lucene)
  • сфинкс

Мои вопросы:

  • Как они сравниваются?
  • Я пропустил какие-либо альтернативы?
  • Я знаю, что каждый случай использования отличается, но есть ли определенные случаи, когда я определенно не хотел бы использовать определенный пакет?

1
Вы исключили использование прямой Lucene? Solr - это сервис на вершине Lucene, так что прямая Lucene может быть возможной.
Дейв

Есть ли у Lucene режим автономного сервера? Я думал, что это была одна из вещей, добавленных SOLR? Я ничего не исключаю - так что не стесняйтесь защищать Lucene, если это лучший выбор с учетом требований :-)
knorv

mausch: в основном Java, но также и другие языки.
knorv

Лично мне нравится сфинкс. Однако недавно во время «большого» проекта последний кандидат на выпуск (0.9.9-rc2) обнаружил ошибки при использовании многозначных массивов (MVA). Это было бы случайным результатом! Поэтому мы перешли в SOLR, чтобы обойти это. Как только SOLR был запущен и запущен, производительность была в порядке, и без ошибки шоу-пробки.
pchap10k

2
Вы смотрели наasticsearch.com?
FYA

Ответы:


327

Я успешно использую Solr уже почти 2 года, и никогда не использовал Sphinx, поэтому я явно предвзят. Однако я постараюсь сохранить объективность, цитируя документы или других людей. Я также приму патчи к моему ответу :-)

сходства:

  • И Solr, и Sphinx удовлетворяют всем вашим требованиям. Они быстрые и предназначены для эффективного индексирования и поиска больших массивов данных.
  • У обоих есть длинный список сайтов с высоким трафиком, использующих их ( Solr , Sphinx )
  • Оба предлагают коммерческую поддержку. ( Solr , Sphinx )
  • Оба предлагают привязки клиентского API для нескольких платформ / языков ( Sphinx , Solr )
  • Оба могут быть распределены для увеличения скорости и емкости ( Sphinx , Solr )

Вот некоторые отличия:

Смежные вопросы:


4
Говоря о разработчиках, работающих с Solr и Lucene, кажется, что они объединили два продукта, делая дальнейшую разработку проще и быстрее - lucidimagination.com/blog/2010/03/26/… .
jimmystormig

3
@Stann: как так? Я использовал Solr почти 5 лет назад и никогда не нуждался в написании ни одной строки Java.
Маурисио Шеффер

@MauricioScheffer Вы действительно думаете, что Java-код будет быстрее, чем C ++. Вот сравнение, сделанное Биллом Карвином и Сфинксом, в котором запросы запрашиваются в 10 раз быстрее, чем люцен (а solr должен быть даже медленнее, чем.) Slideshare.net/billkarwin/…
Stann

3
@Stann: вы действительно думаете, что вам нужно больше производительности, чем whitehouse.gov, Netflix, The Guardian, digg, просто чтобы назвать несколько веб-сайтов, использующих Solr? wiki.apache.org/solr/PublicServers
Маурисио Шеффер

3
Вот ответ на Sphinx, который является хорошей парой для этого ответа на Solr
Новая Александрия

48

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

Преимущества сфинкса:

  1. Разработка и настройка быстрее
  2. Намного лучше (и быстрее) агрегация. Это была убийственная особенность для нас.
  3. Не XML. Это то, что в конечном итоге исключило Solr для нас. Нам пришлось возвращать довольно большие наборы результатов (например, сотни результатов), а затем агрегировать их самостоятельно, поскольку агрегация Solr отсутствовала. Количество времени для сериализации в и из XML просто убивает производительность. Для небольших наборов результатов, тем не менее, это было прекрасно.
  4. Лучшая документация, которую я видел в приложении с открытым исходным кодом

Преимущества Solr:

  1. Может быть продлен.
  2. Можно выполнить поиск прямо из веб-приложения, т. Е. Можно выполнить поиск, подобный автозаполнению, непосредственно на сервере Solr через AJAX.

29
У Solr есть много авторов ответов, кроме xml, включая JSON, PHP, Ruby, Python и двоичный формат java: lucene.apache.org/solr/api/org/apache/solr/request/…
Маурисио Шеффер

24
Я упоминал, насколько ужасна документация Solr / Lucene? Необходимость рутирования через Javadocs для выяснения функциональности не является моей идеей документации.
larf311


2
Я провожу целый день, исправляя некоторые ошибки установки sphinx 0.9.9 на моем Mac. Пока что это все еще не работает. Это так глючит. Я использовал очень предложенные способы. Я даю действительно разочарование ...
lkahtz

Документация Solr не так хороша, как сфинкс. но сообщество большое. И я всегда могу все выяснить, прочитав исходный код Solr.
Тайлер Лонг

21

Примечание: есть много пользователей с таким же вопросом.

Итак, чтобы ответить на вопрос:

Который и почему?

  • Используйте Solr, если вы собираетесь использовать его в своем веб-приложении (пример поисковой системы сайта). Это определенно получится здорово благодаря его API. Вам определенно понадобится эта сила для веб-приложения.

  • Используйте Sphinx, если вы хотите быстро найти тонны документов / файлов. Он тоже очень быстро индексирует. Я бы порекомендовал не использовать его в приложении, которое использует JSON или синтаксический анализ XML для получения результатов поиска. Используйте его для прямого поиска в дБ. Отлично работает на MySQL.

альтернативы

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


13
тот неловкий момент, когда я читаю этот ответ через полтора года, нажимаю на upvote и вижу, что сам написал этот ответ. ржунимагу. : DA небольшое дополнение к этому, хотя: После 18 месяцев ,asticsearch оказался отличной альтернативой и имеет достойное сообщество тоже. Круто, бонсай круто!
Augiwan

Огастес! Этот неловкий момент: D. Так что для веб-приложения на Python, что вы думаете, лучше сейчас? Solr или эластичный поиск, основанный на производительности, использовании памяти и простоте настройки любой идеи?
Мевин Бабу

Неважно, на каком языке написано веб-приложение. Выберите в зависимости от вашего варианта использования!
Augiwan

19

Я использую Sphinx уже почти год, и это было удивительно. Я могу проиндексировать 1,5 миллиона документов примерно за минуту на моем MacBook, и даже быстрее на сервере. Я также использую Sphinx, чтобы ограничить поиск местами в определенных широтах и ​​долготах, и это очень быстро. Кроме того, то, как ранжируются результаты, очень легко настраивается. Простота установки и настройки, если вы прочитали учебник или два. Почти 1.0 статус, но их Кандидаты в Релиз были твердыми.


3
Географический поиск можно выполнить в Solr с помощью плагина LocalSolr
Маурисио Шеффер

1
Вы можете INDEX 1,5 миллиона документов в минуту? Я даже не могу приблизиться к ЧТЕНИЮ такого количества - прямо из 7zip (не записывая, не выводя на консоль) файлов на моем SSD! И это 2017! Что это за документы? Это довольно невероятно. Примечание: надеюсь, вы не имели в виду поиск по индексу 1,5 миллиона в минуту. Поиск по индексу с 1,5 миллионами документов должен все же вернуться в считанные секунды (даже в 2009 году).
FastAl

2

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


Сообщество пользователей является важным моментом. На форумах Sphinx есть пара ОЧЕНЬ, ОЧЕНЬ полезных людей, но в противном случае нет сильного сообщества.
mlissner
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.