Сравнение полнотекстовой поисковой системы – Lucene, Sphinx, Postgresql, MySQL?

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

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

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

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

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

EDIT. Что касается потребностей индексирования, поскольку пользователи продолжают вводить данные на сайт, эти данные необходимо индексировать непрерывно. Это не обязательно в реальном времени, но в идеале новые данные будут отображаться в индексе с задержкой не более 15-30 минут

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

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

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

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

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

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

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

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

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

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

Ответ на ссылку ниже дает несколько подробностей о 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. Кэширование Autowarming
  16. Быстрая индексация (сравните с временем индексирования полнотекстового поиска MySQL) – Lucene использует двоичный инвертированный индексный формат.
  17. Boosting (настраиваемые правила для повышения релевантности определенного ключевого слова или фразы и т. Д.)
  18. Полевые поиски (если поисковый пользователь знает поле, которое он / она хочет выполнить, они сужают свой поиск, вводя поле, затем значение, и ТОЛЬКО это поле ищет, а не все – намного лучше, чем пользователь)

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

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

Apache Solr


Помимо ответов на запросы OP, позвольте мне рассказать о Apache Solr о простейшем вступлении к детальной установке и внедрению .

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


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

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

Solr отлично работает в веб-приложениях High Traffic ( я где-то читал, что он не подходит для этого, но я поддерживаю это заявление ). Он использует ОЗУ, а не ЦП.

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

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

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

Как вы можете видеть, поле firstname увеличивается со счетом 2.

Подробнее о SolrRelevancy

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

Скорость невероятно быстро и без компромиссов. Я переехал в Солр .

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

Чем выше ОЗУ, тем быстрее скорость индексирования Solr.

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

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

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

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

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

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

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

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

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


Этот ответ в основном посвящен Apache Solr & MySQL . Django выходит за frameworks.

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

Подробная установка

Начиная

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

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

В командной строке .. Перейдите в каталог

[email protected]: cd Downloads/solr-4.8.1

Итак, теперь вы здесь.

[email protected]: ~/Downloads/solr-4.8.1$

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

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

[email protected]:~/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 .

[email protected]:~/Downloads/solr-4.8.1/contrib/dataimporthandler/lib

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

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

1.Табличная структура

 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. Начать

 [email protected]: ~/Downloads/solr-4.8.1/example/solr/collection1/conf 

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

Добавьте эти два указателя в этот файл.

    

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

   db-data-config.xml   

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

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

          

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

4. Модифицируйте файл schema.xml

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

 id  

Реализация

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

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

Шаг 1: Перейдите в панель администрирования Solr

Удалите URL-адрес http: // localhost: 8983 / solr в своем браузере. Экран открывается таким образом.

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

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

Шаг 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 для enums всех записей

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

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

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

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

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

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

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

Но у него нет удобных поисковых операторов, таких как + или AND (использует & |!), И я не в восторге от того, как он работает на сайте документации. Несмотря на то, что в fragmentах результатов он содержит смещение совпадений, алгоритм по умолчанию, для которого условия соответствия невелики. Кроме того, если вы хотите индексировать 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, который даже не индексирует слова из трех букв или меньше».

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

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

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

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

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

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

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

Давайте будем гением компьютера.