Сравнение полнотекстового поискового движка - Lucene, Sphinx, Postgresql, MySQL?

Я создаю сайт Django и ищу поисковик.

Несколько кандидатов:

  • Люцен / Люцен с Компасом / Солр

  • сфинкс

  • Postgresql встроенный полнотекстовый поиск

  • MySQl встроенный полнотекстовый поиск

Критерий выбора:

  • релевантность результата и рейтинг
  • скорость поиска и индексации
  • простота использования и простота интеграции с Django
  • требования к ресурсам - сайт будет размещен на VPS, поэтому в идеале поисковой системе не потребуется много оперативной памяти и процессора
  • масштабируемость
  • дополнительные функции, такие как "Вы имели в виду?", связанные поиски и т. д.

Любой, кто имел опыт работы с поисковыми системами выше или другими двигателями, которых нет в списке - я хотел бы услышать ваше мнение.

РЕДАКТИРОВАТЬ: Что касается потребностей в индексации, так как пользователи продолжают вводить данные на сайт, эти данные должны быть проиндексированы непрерывно. Это не должно быть в режиме реального времени, но в идеале новые данные должны отображаться в индексе с задержкой не более 15 - 30 минут.

10 ответов

Решение

Приятно видеть, что кто-то говорит о Lucene - потому что я понятия не имею об этом.

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

  • Результат релевантности рейтинга по умолчанию. Вы можете настроить собственную сортировку, если хотите, и придать конкретным полям более высокий вес.
  • Скорость индексации очень высокая, потому что она напрямую обращается к базе данных. Любая медлительность будет вызвана сложными запросами SQL, неиндексированными внешними ключами и другими подобными проблемами. Я никогда не замечал никакой медлительности в поиске.
  • Я парень из Rails, поэтому я понятия не имею, насколько легко это реализовать с помощью Django. Тем не менее, есть Python API, который поставляется с исходным кодом Sphinx.
  • Демон службы поиска (searchd) довольно мало использует память - и вы можете установить ограничения на объем памяти, используемый процессом индексатора.
  • Масштабируемость - это то, где мои знания более поверхностны, но достаточно просто скопировать индексные файлы на несколько машин и запустить несколько демонов searchd. Общее впечатление, которое я получаю от других, заключается в том, что он очень хорош при высокой нагрузке, поэтому его масштабирование на нескольких машинах не является проблемой, с которой нужно иметь дело.
  • Поддержка "сделал-ты-имеешь" и т. Д. Отсутствует, хотя это можно сделать с помощью других инструментов достаточно легко. Sphinx использует слова, хотя и использует словари, поэтому "поиск" и "движение" (например) будут считаться одинаковыми при поиске.
  • Sphinx не допускает частичного обновления индекса для полевых данных. Обычный подход к этому состоит в том, чтобы поддерживать дельта-индекс со всеми последними изменениями и повторно индексировать его после каждого изменения (и эти новые результаты появляются в течение секунды или двух). Из-за небольшого объема данных это может занять несколько секунд. Тем не менее, вам все равно придется регулярно переиндексировать основной набор данных (хотя как часто это зависит от изменчивости ваших данных - каждый день, каждый час?). Высокая скорость индексации делает все это довольно безболезненным.

Я понятия не имею, насколько это применимо к вашей ситуации, но Эван Уивер сравнил несколько общих параметров поиска Rails (Sphinx, Ferret (порт Lucene для Ruby) и Solr), выполняя некоторые тесты. Может быть полезным, я думаю.

Я не изучил глубины полнотекстового поиска MySQL, но я знаю, что он не конкурирует ни по скорости, ни по характеристикам со Sphinx, Lucene или Solr.

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

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

Что касается требований к ЦП и ОЗУ, выполнение поиска в Lucene не требует слишком больших нагрузок на ваш ЦП, хотя индексация данных выполняется, хотя вы делаете это не слишком часто (возможно, один или два раза в день), так что это не так. большая часть препятствия.

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

Apache Solr


Помимо ответов на вопросы OP, позвольте мне рассказать немного об Apache Solr, от простого ознакомления с подробным описанием установки и реализации.

Простое введение


Любой, кто имел опыт работы с поисковыми системами выше или другими двигателями, которых нет в списке - я хотел бы услышать ваше мнение.

Solr не должен использоваться для решения проблем в реальном времени. Для поисковых систем Solr в значительной степени игра и работает без нареканий.

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

  • релевантность результата и рейтинг

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

http://localhost:8983/solr/collection1/select?q=firstname:john^2&lastname:john

Как видите, поле имени увеличено со счетом 2.

Подробнее о SolrRelevancy

  • скорость поиска и индексации

Скорость невероятно высока и без компромиссов. Причина, по которой я перешел на Solr.

Что касается скорости индексации, Solr также может обрабатывать JOINS из таблиц вашей базы данных. Более высокое и сложное JOIN влияет на скорость индексации. Тем не менее, огромная конфигурация оперативной памяти может легко справиться с этой ситуацией.

Чем выше оперативная память, тем выше скорость индексации Solr.

  • простота использования и простота интеграции с Django

Никогда не пытался интегрировать Solr и Django, однако вы можете добиться этого с Haystack. Я нашел несколько интересных статей на эту же тему, и вот вам github.

  • требования к ресурсам - сайт будет размещен на VPS, поэтому в идеале поисковой системе не потребуется много оперативной памяти и процессора

Solr размножается на RAM, поэтому, если RAM высокая, вам не нужно беспокоиться о Solr.

Использование Solr в ОЗУ возрастает при полной индексации, если у вас есть несколько миллиардов записей, вы можете разумно использовать импорт Delta для решения этой ситуации. Как уже говорилось, Solr - это решение, которое можно использовать только в реальном времени.

  • масштабируемость

Solr отлично масштабируется. Посмотрите на SolrCloud. Некоторые ключевые особенности этого.

  • Осколки (или осколок - это концепция распределения индекса по нескольким машинам, например, если ваш индекс слишком велик)
  • Балансировка нагрузки (если Solrj используется с облаком Solr, он автоматически заботится о балансировке нагрузки с помощью механизма Round-Robin)
  • Распределенный поиск
  • Высокая доступность
  • дополнительные функции, такие как "Вы имели в виду?", связанные поиски и т. д.

Для вышеупомянутого сценария вы можете использовать SpellCheckComponent, который упакован с Solr. Есть много других функций, SnowballPorterFilterFactory помогает извлекать записи, например, если вы печатаете, книги вместо книги, вам будут представлены результаты, связанные с книгой.


Этот ответ в основном сфокусирован на Apache Solr и MySQL. Джанго выходит за рамки.

Предполагая, что вы находитесь в среде LINUX, вы можете перейти к этой статье дальше. (у меня была версия Ubuntu 14.04)

Детальная установка

Начиная

Загрузите Apache Solr отсюда. Это будет версия 4.8.1. Вы можете скачать новые версии, я нашел эту стабильную.

После загрузки архива распакуйте его в папку по вашему выбору. Сказать.. Downloads или как угодно.. Так это будет выглядеть Downloads/solr-4.8.1/

По вашему запросу. Перейдите в каталог

shankar@shankar-lenovo: cd Downloads/solr-4.8.1

Так что теперь вы здесь..

shankar@shankar-lenovo: ~/Downloads/solr-4.8.1$

Запустите сервер приложений Jetty

Причал доступен в папке примеров solr-4.8.1 каталог, поэтому перейдите в него и запустите Jetty Application Server.

shankar@shankar-lenovo:~/Downloads/solr-4.8.1/example$ java -jar start.jar

Теперь не закрывайте терминал, сверните его и оставьте в стороне.

(СОВЕТ: используйте & after start.jar, чтобы Jetty Server работал в фоновом режиме)

Чтобы проверить, работает ли Apache Solr успешно, посетите этот URL в браузере. HTTP: // локальный: 8983 / Solr

Запуск Jetty на пользовательском порту

Он работает на порту 8983 по умолчанию. Вы можете изменить порт либо здесь, либо непосредственно внутри jetty.xml файл.

java -Djetty.port=9091 -jar start.jar

Загрузите JConnector

Этот файл JAR действует как мост между MySQL и JDBC. Загрузите независимую от платформы версию здесь

После загрузки извлеките папку и скопируйте mysql-connector-java-5.1.31-bin.jar и вставьте его в каталог lib.

shankar@shankar-lenovo:~/Downloads/solr-4.8.1/contrib/dataimporthandler/lib

Создание таблицы MySQL для связи с Apache Solr

Чтобы использовать Solr, вам нужно иметь несколько таблиц и данных для поиска. Для этого мы будем использовать MySQL для создания таблицы и отправки некоторых случайных имен, а затем мы можем использовать Solr для подключения к MySQL и индексирования этой таблицы и ее записей.

Структура 1.Table

CREATE TABLE test_solr_mysql
 (
  id INT UNSIGNED NOT NULL AUTO_INCREMENT,
  name VARCHAR(45) NULL,
  created TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (id)
 );

2. Заполните приведенную выше таблицу

INSERT INTO `test_solr_mysql` (`name`) VALUES ('Jean');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Jack');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Jason');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Vego');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Grunt');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Jasper');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Fred');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Jenna');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Rebecca');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Roland');

Попасть внутрь ядра и добавить директивы lib

1. Перейдите к

shankar@shankar-lenovo: ~/Downloads/solr-4.8.1/example/solr/collection1/conf

2. Модификация solrconfig.xml

Добавьте эти две директивы в этот файл..

  <lib dir="../../../contrib/dataimporthandler/lib/" regex=".*\.jar" />
  <lib dir="../../../dist/" regex="solr-dataimporthandler-\d.*\.jar" />

Теперь добавьте DIH (обработчик импорта данных)

<requestHandler name="/dataimport" 
  class="org.apache.solr.handler.dataimport.DataImportHandler" >
    <lst name="defaults">
      <str name="config">db-data-config.xml</str>
    </lst>
</requestHandler>

3. Создайте файл db-data-config.xml

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

<dataConfig>
    <dataSource type="JdbcDataSource" driver="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost/yourdbname" user="dbuser" password="dbpass"/>
    <document>
   <entity name="test_solr" query="select CONCAT('test_solr-',id) as rid,name from test_solr_mysql WHERE '${dataimporter.request.clean}' != 'false'
      OR `created` > '${dataimporter.last_index_time}'" >
    <field name="id" column="rid" />
    <field name="solr_name" column="name" />
    </entity>
   </document>
</dataConfig>

(СОВЕТ: Вы можете иметь любое количество объектов, но следите за полем идентификатора, если они одинаковые, тогда индексирование будет пропущено.)

4. Изменить файл schema.xml.

Добавьте это в свой schema.xml, как показано..

<uniqueKey>id</uniqueKey>
<field name="solr_name" type="string" indexed="true" stored="true" />

Реализация

индексирование

Вот где настоящая сделка. Вам нужно выполнить индексацию данных из MySQL в порядок Solr, чтобы использовать Solr Queries.

Шаг 1: Зайдите в админ панель Solr

Нажмите на http://localhost:8983/solr в своем браузере. Экран открывается так.

Это основная панель администрирования Apache Solr

Как показывает маркер, перейдите в раздел " Ведение журнала", чтобы проверить, не привела ли какая-либо из вышеуказанных конфигураций к ошибкам.

Шаг 2: Проверьте свои журналы

Итак, теперь вы здесь, как вы можете есть много желтых сообщений (ПРЕДУПРЕЖДЕНИЯ). Убедитесь, что у вас нет сообщений об ошибках, отмеченных красным. Ранее в нашу конфигурацию мы добавили запрос select в наш db-data-config.xml, скажем, если бы в этом запросе были какие-либо ошибки, он бы появился здесь.

Это раздел регистрации вашего движка Apache Solr

Хорошо, без ошибок. Мы готовы идти. Давайте выберем collection1 из списка, как изображено, и выберите Dataimport

Шаг 3: DIH (обработчик импорта данных)

Используя DIH, вы будете подключаться к MySQL из Solr через файл конфигурации db-data-config.xml из интерфейса Solr и извлекать 10 записей из базы данных, которая индексируется в Solr.

Для этого выберите " Полный импорт" и установите флажки " Очистить и зафиксировать". Теперь нажмите Выполнить, как показано.

В качестве альтернативы, вы также можете использовать прямой запрос полного импорта, как этот..

http://localhost:8983/solr/collection1/dataimport?command=full-import&commit=true

Обработчик импорта данных

После того, как вы нажали " Выполнить", Solr начнет индексировать записи. Если возникнут какие-либо ошибки, появится сообщение " Ошибка индексации", и вам придется вернуться в раздел " Ведение журнала ", чтобы узнать, что пошло не так.

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

Успешное индексирование

Шаг 4: Запуск Solr запросов

Похоже, все прошло хорошо, теперь вы можете использовать Solr Queries для запроса данных, которые были проиндексированы. Нажмите " Запрос" слева, а затем нажмите кнопку " Выполнить" внизу.

Вы увидите проиндексированные записи, как показано.

Соответствующий запрос Solr для перечисления всех записей

http://localhost:8983/solr/collection1/select?q=*:*&wt=json&indent=true

Индексированные данные

Ну, там идет все 10 проиндексированных записей. Скажем, нам нужны только имена, начинающиеся с Ja, в этом случае вам нужно указать имя столбца solr_name Следовательно, ваш запрос выглядит следующим образом.

http://localhost:8983/solr/collection1/select?q=solr_name:Ja*&wt=json&indent=true

Данные JSON, начинающиеся с Ja

Вот как вы пишете Solr Queries. Чтобы узнать больше об этом, проверьте эту прекрасную статью.

Я удивлен, что больше нет информации о Solr. Solr очень похож на Sphinx, но имеет более продвинутые функции (AFAIK, так как я не использовал Sphinx - только читал об этом).

В ответе по ссылке ниже подробно рассказывается о Сфинксе, который также относится к Solr. Сравнение полнотекстового поискового движка - Lucene, Sphinx, Postgresql, MySQL?

Solr также предоставляет следующие дополнительные функции:

  1. Поддерживает репликацию
  2. Несколько ядер (представьте их как отдельные базы данных со своей конфигурацией и собственными индексами)
  3. Булевы поиски
  4. Выделение ключевых слов (довольно легко сделать в коде приложения, если у вас есть regex-fu; однако, почему бы не позволить специализированному инструменту сделать вашу работу лучше)
  5. Обновить индекс через XML или файл с разделителями
  6. Связь с поисковым сервером через HTTP (он может даже вернуть Json, Native PHP/Ruby/Python)
  7. Индексирование документов PDF, Word
  8. Динамические поля
  9. Грани
  10. Агрегатные поля
  11. Стоп слова, синонимы и т. Д.
  12. Больше как это...
  13. Индексировать напрямую из базы данных с помощью пользовательских запросов
  14. Авто-предложить
  15. Автосогрев кеша
  16. Быстрая индексация (сравните со временем индексации полнотекстового поиска в MySQL) - Lucene использует формат двоичного инвертированного индекса.
  17. Повышение (пользовательские правила для повышения релевантности определенного ключевого слова или фразы и т. Д.)
  18. Поиск по полям (если пользователь поиска знает поле, которое он / она хочет найти, они сужают свой поиск, набирая поле, затем значение, и ТОЛЬКО это поле ищется, а не все - гораздо лучший опыт для пользователя)

Кстати, есть еще множество функций; Тем не менее, я перечислил только те функции, которые я фактически использовал в производстве. Кстати, из коробки MySQL поддерживает # 1, # 3 и # 11 (ограничено) в приведенном выше списке. Для функций, которые вы ищете, реляционная база данных не собирается сокращать ее. Я бы сразу их ликвидировал.

Кроме того, еще одним преимуществом является то, что Solr (ну, на самом деле, Lucene) является базой данных документов (например, NoSQL), поэтому многие преимущества любой другой базы данных документов могут быть реализованы с помощью Solr. Другими словами, вы можете использовать его не только для поиска (например, производительности). Проявите творческий подход с этим:)

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

Но у него нет удобных операторов поиска, таких как + или AND (использует & |!), И я не в восторге от того, как это работает на их сайте документации. Несмотря на то, что он содержит выделение терминов соответствия в фрагментах результатов, алгоритм по умолчанию, для которого термины соответствия не являются хорошими. Кроме того, если вы хотите индексировать RTF, PDF, MS Office, вы должны найти и интегрировать конвертер форматов файлов.

OTOH, это намного лучше, чем текстовый поиск MySQL, который даже не индексирует слова из трех букв или меньше. По умолчанию это поиск в MediaWiki, и я действительно думаю, что он не подходит для конечных пользователей: http://www.searchtools.com/analysis/mediawiki-search/

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

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

Просто мои два цента на этот очень старый вопрос. Я очень рекомендую взглянуть на ElasticSearch.

Elasticsearch - это поисковый сервер на основе Lucene. Он предоставляет распределенную полнотекстовую поисковую систему с поддержкой нескольких арендаторов с веб-интерфейсом RESTful и JSON-документами без схемы. Elasticsearch разработан на Java и выпущен как открытый исходный код в соответствии с условиями лицензии Apache.

Преимущества перед другими FTS (полнотекстовым поиском) двигателями являются:

  • RESTful интерфейс
  • Лучшая масштабируемость
  • Большое сообщество
  • Создано разработчиками Lucene
  • Обширная документация
  • Есть много доступных библиотек с открытым исходным кодом (включая Django)

Мы используем эту поисковую систему в нашем проекте и очень довольны ею.

SearchTools-Avi сказал: "Текстовый поиск MySQL, который даже не индексирует слова из трех букв или меньше".

К сведению, минимальная длина слова в полнотексте MySQL регулируется, по крайней мере, с MySQL 5.0. Google 'mysql fulltext min length' для простых инструкций.

Тем не менее, полный текст MySQL имеет ограничения: например, он медленно обновляется, когда вы достигаете миллиона записей или около того,...

Мы только что перешли с Elasticsearch на Postgres Full Text. Поскольку мы уже использовали Postgres, теперь мы избавляем себя от хлопот по обновлению индекса. Но это влияет только на полнотекстовый поиск. Однако есть случаи, когда Elasicsearch значительно лучше. Может быть, грани или что-то в этом роде.

Я бы добавил mnoGoSearch в список. Чрезвычайно эффективное и гибкое решение, которое работает как Google: индексатор извлекает данные с нескольких сайтов, вы можете использовать базовые критерии или придумывать свои собственные хуки для обеспечения максимального качества поиска. Также он может получать данные непосредственно из базы данных.

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

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

Поскольку вы используете фреймворк Django, вы можете использовать или PHP-клиент посередине, или найти решение на Python, я видел несколько статей.

И, конечно, mnoGoSearch является открытым исходным кодом, GNU GPL.

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

Другие вопросы по тегам