Какой лучший вариант для поиска в Ruby on Rails?

Существует несколько вариантов плагинов для создания поисковой системы в вашем приложении Ruby on Rails. Какой из них лучше?

Ответ 1

Мышление Sphinx имеет более сжатый синтаксис, чтобы определить, какие поля и какие модели индексируются.

Оба UltraSphinx и Thinking Sphinx (недавно) имеют ультра-крутую функцию, которая учитывает географическую близость объектов.

У UltraSphinx есть досадные проблемы с тем, как он загружает модели (он не загружает весь стек Rails, поэтому вы можете получить странную и трудную диагностику ошибок, которые обрабатываются путем добавления явных инструкций require).

Мы используем Thinking Sphinx для новых проектов, а UltraSphinx - для проектов, которые используют геоконтент.

Ответ 2

Этот вопрос был задан ранее здесь с более подробными ответами.

Ответ 3

Твердая опция, используемая одним из моих друзей, - это Solr, поисковая система, использующая оригинальный Lucene на основе Java. Чтобы использовать его с Rails, есть, конечно, плагин act_as, acts_as_solr.

Недавно он представил комбо в Montreal on Rails и дает хороший и тщательный обзор как использовать act_as_solr в своем блоге.

Он также хорошо подходит к французским акцентам.

Ответ 4

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

* Sphinx - хорошая репутация скорости и функциональности, но Sphinx нужны целые ключи, а моя модель использует GUID; Недавно ThinkingSphinx объявила о поддержке GeoSpatial
Acts_As_Solr - рекомендуется другом с большим объемом сайта; оригинальные создатели перестали работать над этим, и документация трудно найти; требуется сервлет Java
Acts_As_Ferret - выглядит прост в использовании, но много хулителей, которые говорят, что он нестабилен
Два других с ограниченной информацией: Acts_As_Indexed и Acts_As_Searchable

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

Моя рекомендация - попробовать UltraSphinx или Thinking Sphinx, если у вас есть обычные первичные ключи. Я собираюсь попробовать Acts_As_Xapian на основе хорошей документации, набора функций и насколько активен проект.

Ответ 5

Я использовал только компилятор Ferret/actions_as_ferret (устаревшее решение) в клиентском проекте. Я настоятельно рекомендую сначала взглянуть на другие.

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

В таком случае, вместо того, чтобы просто выполнять функцию поиска, любое действие контроллера, касающееся индексированной модели, полностью завершится сбоем и вызовет исключение. Что такое baaad, hmkay?

Ответ 6

Я использую плагин act_as_xapian. Я последовал этому руководству:

http://locomotivation.com/2008/07/23/simple-ruby-on-rails-full-text-search-using-xapian

Хорошо работает.

Ответ 7

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

В отличие от sphinx, вам не нужно повторно индексировать ВСЕ ваши записи при добавлении новых данных. Появляются перехваты after_save и after_update, которые вставляют вашу новую запись в хорек db. Это был один из больших торговых точек для меня.

Когда вам приходится массово индексировать свои данные, хорек определенно медленнее, чем act_as_sphinx (в 3 раза). Я закончил тем, что написал свой собственный метод для переопределения моделей, которые работают так же быстро, как sphinx - он в основном предварительно загружает все данные из БД, а не собирается запись по записи, чтобы создать новый индекс.

Документация хорька хороша для основ, но она немного разрежена, когда вы начинаете более сложные поиски, сортируете и используете сервер dRb для размещения удаленного индекса. Говоря это, он чувствует себя гораздо более зрелым продуктом, чем act_as_sphinx, хотя у меня ограниченный опыт работы с sphinx.

Ответ 8

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

Поэтому я пошел с Ксапианом, и он работал хорошо для меня. Есть 2 плагина для рельсов, которые я исследовал: act_as_xapian и xapian_fu. Первая заставит вас идти быстро, но, похоже, она больше не поддерживается. Я только начал работать с xapian_fu.

Ответ 9

Если кому-то все еще интересно, последнее, что нужно использовать сейчас, - elasticsearch. Для него есть драгоценные камни как шина или elasticsearch-rails. Он также основан на Lucene, как Solr, на основе Java. Solr фактически интегрирован с этим проектом сейчас...

Ответ 10

Я использовал Thinking Sphinx, и это кажется очень хорошим, но у меня не было времени оценить все варианты.

Ответ 11

Я рекомендую мыслящий сфинкс. Это самый быстрый вариант, на мой взгляд.

Ответ 12

Я использовал Ferret, и он хорошо работал для моих целей, но я не оценил другие варианты.

Ответ 13

Опция, которую я не пробовал, - это Xapian

Ответ 14

Мы используем http://hyperestraier.sourceforge.net/, который был унаследован. Не заглядывали в другие двигатели, но hyperestraier предоставляет все необходимые крючки. Однако настройка индекса поиска сложна. Вероятно, есть более простые варианты.

Ответ 15

Это зависит от того, какую базу данных вы используете. Я бы рекомендовал использовать Solr, поскольку он предлагает множество хороших вариантов для нечеткого поиска и имеет отличный синтаксический анализатор запросов. Недостатком является то, что вам нужно запустить отдельный процесс для этого. Я также использовал Ferret, но обнаружил, что он менее стабилен с точки зрения многопоточного доступа к индексу. Я не пробовал Sphinx, потому что он работает только с MySQL и Postgres.

Ответ 16

Я использую другую опцию, которая была разработана удивительно хорошо. Я использую jruby и напрямую разговариваю с lucene.

Я использовал act_as_solr в прошлом и сталкивался с некоторыми проблемами. в основном это делает синхронный вызов для каждого сохранения AR. Это не так уж плохо, но в моей ситуации сохранение иногда вызывало много синхронных вызовов для solr и иногда занимало бы больше времени, чем позволял бы mongrel, и я получал бы исключение тайм-аула mongrel (или что-то в этом роде)

Ответ 17

Мышление Sphinx - лучшая альтернатива Ultrasphinx, которая кажется заброшенной, но, в общем, Xapian имеет более мощный движок, чем Sphinx, и проще реализовать поиск в реальном времени.

Ответ 18

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

Ответ 19

Я искал идеальное решение. Сначала я пошел с Thinking Sphinx, который отлично работал. Но поскольку я намерен разместить мой webapp на Heroku, единственный вариант - использовать Solr. Однако самый большой недостаток заключается в том, что развитие майора acts_as_solr, похоже, прекратилось после мая 2008 года. Так что это слишком старое для моего вкус. Я только что нашел Sunspot в качестве передовой альтернативы и с недавними обновлениями, так что я буду рассматривать.

Другой вариант, предлагаемый Heroku, заключается в том, чтобы пойти на размещенный сервер индексирования на основе Solr, названный Websolr. Необходимый драгоценный камень websolr-acts_as_solr также, к счастью, очень актуальен.