Браузерные игры, реалтайм, финансы, стартапы
0,0
рейтинг
4 августа 2008 в 22:16

Разработка → Полнотекстовый поиск в веб-проектах: Sphinx, Apache Lucene, Xapian

Полная авторская верcия из моего блога. Оригинал материала написан специально для Developers.org.ua

Наверное любой современный веб-проект сложно себе представить без… без контента! Да, именно контент в разных его проявлениях сегодня «правит бал» в различных веб-проектах. Не так важно — создаваемый пользователями или получаемый из других источников автоматически — информация является основной любого (ну, или почти любого) проекта. А раз так — то вопрос поиска необходимой информации стоит очень остро. И острее с каждым днем, ввиду стремительного расширения количества этого самого контента, в основном за счёт создаваемого пользователями (это и форумы, и блоги и модные нынче сообщества, вроде Habrahabr.ru). Таким образом, любой разработчик, реализующий сегодня какой-либо проект, сталкивается с потребностью реализовать поиск в своём веб-приложении. При этом требования к такому поиску уже намного сложнее и шире, чем даже год-два назад. Конечно, для каких-то проектов вполне подойдёт и простое решение, к примеру, вполне можно использовать Custom Google Search. Но чем более сложное приложение, и чем сложнее структура контента, если требуются особые виды поиска и обработки результата, или же просто количество или формат данных в вашем проекте особый, вам потребуется собственная поисковая система. Именно своя система, собственный поисковый сервер или сервис, а не сторонний, пусть даже гибкий и настраиваемый. Но что же выбрать, и вообще — какие сейчас на рынке есть поисковые проекты, которые готовы для использования в реальных проектах, не исследовательских или научных, а реальных бизнес-приложениях? Далее мы кратко рассмотрим различные варианты поисковых решений, пригодных для встраивания в ваше веб-приложение или развёртывания на собственном сервере.

Общая архитектура и термины

И так, для более глубокого понимания сути поиска мы попробуем кратко ознакомится с используемыми понятиями и терминами. Под поисковым сервером (или просто «поисковик») мы понимаем библиотеку или компонент, вообще, программное решение, которое самостоятельно ведёт свою базу данных (на самом деле это может быть и СУБД, и просто файлы и распределённая платформа хранения) документов, в которых, собственно, и происходит поиск, предоставляет сторонним приложениям добавлять, удалять и обновлять документы в этой базе. Этот процесс называется индексированием, и может быть реализовано отдельным компонентом или сервером (индексатором). Другой компонент, именно поисковый механизм, принимает запрос на поиск и обрабатывая созданную индексатором базу производит выборку данных, которые соответствуют запросу. Кроме этого, он может вычислять дополнительные параметры для результатов поиска (ранжировать документы, вычислять степень соответствия поисковому запросу и т.п.). Это самые важные системы поисковика, и они могут быть как монолитно реализованы в одной библиотеке, так и быть самостоятельными серверами, доступ к которым реализуется через различные прикладные протоколы и API. Дополнительно, в поисковом сервере может быть реализована предварительная обработка документов перед индексацией (например, извлечение текста с файлов различных форматов или баз данных), различные API также могут реализоваться дополнительными компонентами. Сам сервер может хранить свои индексные данные в базе данных (как встроенной, так и используя внешний сервер, например, MySQL), в виде файлов собственного оптимизированного формата или даже использовать специальную распределённую файловую систему.

Отдельно я бы выделил наличие модуля реализации веб-поиска. То есть, в поисковом сервере может быть реализована встроенная возможность получать документы с веб-сайтов по протоколу НТТР и заносить их в индекс. Этот модуль называется обычно «паук» или «crawler», и таким образом, поисковый сервер уже может быть похож на «настоящий» и привычный всем поиск вроде Google или Yandex. Так можно реализовать собственный поисковик по нужным вам сайтам, например, посвящённым одной теме — достаточно просто создать список адресов и настроить их периодических обход. Однако это уже задача гораздо более сложная и серьёзная, как технически, так и организационно, поэтому мы не останавливаемся на деталях её реализации. Среди проектов, которые мы рассмотрим, присутствует один сервер, именно реализующий веб-поисковик, то есть содержит все необходимое для создания «убийцы Яндекса». Интересно?

Какие параметры важны?

При выборе поискового механизма следует учитывать следующие параметры:
  • скорость индексирования — то есть, как быстро поисковый сервер «перемалывает» документы и заносит их в свой индекс, делая доступным поиск по ним. Обычно измеряется в мегабайтах чистого текста в секунду.
  • скорость переиндексации — в процессе работы документы изменяются или добавляются новые, поэтому приходится переиндексировать информацию. Если сервер поддерживает инкрементное индексирование, то мы обрабатываем только новые документы, а обновление всего индекса оставляем на потом или даже вообще не делать. Другие сервера требуют полной перестройки индекса при добавлении новой информации, либо используют дополнительные индексы (дельта-индекс), в который включается только новая информация
  • поддерживаемые API — если вы используете поисковик в связке с веб-приложением, обратите внимание на наличие встроенного API к вашему языку или платформе. Большинство поисковиков имеют API для всех популярных платформ — Java, PHP, Ruby, Phyton
  • поддерживаемые протоколы — кроме API важны и протоколы доступа, в частности, если вы захотите получить доступ с другого сервера или приложения, к которому нет родного API. Обычно поддерживаются XML-RPC (или разновидности, вроде JSON-RPC), SOAP или доступ через http/socket.
  • размер базы и скорость поиска — эти параметры очень взаимосвязаны и если вы реализуете что-то уникальное и предусматриваете, что у вас могут быть миллионы и больше документов в базе, по которым нужно производить мгновенный поиск, то посмотрите на известные реализации выбранной платформы. Хотя никто не заявляет явно про ограничения на количество документов в базах, и на небольших коллекциях (например, несколько тысяч или десятков тысяч документов) все поисковики будут примерно одинаковые, но если речь идёт о миллионах документов — это может стать проблемой. Кстати говоря, сам по себе этот параметр не всегда имеет значение, нужно смотреть на особенности каждой системы и алгоритмы работы с поиском, а также на другие параметры, например, скорость переиндексации или возможные типы индексов и системы их хранения.
  • поддерживаемые типы документов — конечно, любой сервер поддерживает обычный текст (хотя следует смотреть на возможность работы с многоязычными документами и кодировкой UTF-8), но если вам необходимо индексировать разные типы файлов, например, HTML, XML, DOC или PDF, то стоит посмотреть на те решения, где есть встроенный компонент для индексации различных форматов и извлечения из них текста. Конечно, все это можно сделать прямо в вашем приложении, но лучше поиска готовые решения. Сюда же относится и поддержка индексирования и поиска информации, которая хранится в СУБД — не секрет, что такое хранение самое распространённое для веб-приложений, и лучше, чтобы поисковый сервер работал напрямую с базой данных, без необходимости вручную извлекать и «скармливать» ему документы для индексирования.
  • работа с разными языками и стемминг — для корректного поиска с использованием разных языков необходима родная поддержка не только кодировок, но и работа с особенностями языка. Все поддерживают английский язык, который для поиска и обработки достаточно простой, но для русского и других аналогичных необходимо использовать автоматические средства для обеспечения морфологии. Модуль стемминга позволяет склонять и разбирать слова в поисковом запросе для более корректного поиска. Если для вас критичен поиск на русском языке, обратите внимание на присутствие этого модуля и его особенности (конечно, ручной стемминг лучше автоматического, но сложнее, хотя и автоматические есть очень разные).
  • поддержка дополнительных типов полей в документах — кроме самого текста, который индексируется и в котором производится поиск, необходимо наличие возможности хранить в документе неограниченное количество других полей, которые могут хранить мета-информацию о документе, что необходимо для дальнейшей работы с результатами поиска. Очень желательно, чтобы количество и типы полей не ограничивались, а индексируемость полей можно было настраивать. Например: в одном поле хранится название, во втором — аннотация, в третьем — ключевые слова, в четвёртом — идентификатор документа в вашей системе. Необходимо гибко настраивать область поиска (в каждом поле или в указанных), а также те поля, которые будут извлекаться с базы поисковика и выдаваться в результатах поиска.
  • платформа и язык — это так же важно, хотя и в меньшей степени. Если вы собираетесь выделять поиск в отдельный от приложения модуль или сервер, или даже выносите его на отдельный сервер (железо в смысле), то роль платформы не такая и большая. Обычно это или C++ или Java, хотя есть варианты и для других языков (обычно порты решений на java).
  • наличие встроенных механизмов ранжирования и сортировки — особенно хорошо, если поисковик можно расширять (и он написан на известном вам языке) и написать нужные вам реализации этих функций, ведь существует очень много разных алгоритмов, и не факт, что используемый по умолчанию в поисковике вам подойдёт.

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

Теперь кратко расскажем о тех поисковых решениях, на которые вам следует обратить внимание, только вы решите приступить к вопросу о поиске. Я намеренно не рассматриваю встроенные в вашу СУБД решение — FULLTEXT в MySQL и FTS в PostgreSQL (интегрирован в базу с версии, если не ошибаюсь, 8.3). В MySQL решение не может применяться для серьёзного поиска, особенно по большим объёмам данных, поиск в PostgreSQL намного лучше, но только если вы уже применяете эту базу. Хотя, как вариант — ставить отдельный сервер БД и там использовать только хранение данных и поиск тоже вариант. К сожалению, не имею на руках данных о реальных применениях на больших объёмах данных и сложных запросах (единицы и десятки Гб текста).


Sphinx search engine
  • Тип: отдельный сервер, MySQL storage engine
  • Платформа: С++/кросс-платформенный
  • Индекс: монолитный + дельта-индекс, возможность распределённого поиска
  • Поисковые возможности: булевый поиск, поиск по фразам и т.п. с возможностью группировки, ранжирования и сортировки результата
  • API и протоколы: SQL DB (а также встроенная поддержка MySQL и PostgreSQL), собственный XML-интерфейс, встроенные API для РНР, Ruby, Python, Java, Perl
  • Поддержка языков: встроенный английский и русский стемминг, soundex для реализации морфологии
  • Дополнительные поля: да, неограниченное количество
  • Типы документов: только текст или собственные XML-формат
  • Размер индекса и скорость поиска: очень быстрый, индексация около 10 Мб/сек (зависит от CPU), поиск около 0.1 сек/~2 — 4 Гб индексе, поддерживает размеры индекса в сотни Гб и сотни миллионов документов (это если не использовать кластеризацию), однако есть примеры работ на терабайтных базах данных.
  • Лицензия: open source, GPL 2 или коммерческая.
  • URL: http://sphinxsearch.com

Sphinx вероятно самый мощный и быстрый из всех открытых движков, которые мы рассмотрим. Особенно удобен тем, что имеет прямую интеграцию с популярными базами данных и поддерживает развитые возможности поиска, включая ранжирование и стемминг для русского и английского языка. Похоже, что отличную поддержку русского языка проект проект имеет из-за того, что автор — наш соотечественник, Андрей Аксенов. Поддерживаются и нетривиальные возможности вроде распределённого поиска и кластеризации, однако фирменной фичей является очень и очень высокая скорость индексации и поиска, а также способность отлично распараллеливаться и утилизировать ресурсы современных серверов. Известны очень серьёзные инсталляции, содержащие терабайты данных, поэтому Sphinx вполне можно рекомендовать как выделенный поисковый сервер для проектов любого уровня сложности и объёма данных. Прозрачная работа с самыми популярными базами данных MySQL и PostgreSQL позволяет его использовать в обычном для веб-разработки окружении, к тому же сразу «из коробки» есть API для разных языков, в первую очередь, для РНР без применения дополнительных модулей и библиотек расширения. Но сам поисковик необходимо компилировать и устанавливать отдельно, поэтому на обычном хостинге он неприменим — только VDS или собственный сервер, причём, желательно побольше памяти. Индекс у поисковика монолитный, поэтому придётся немного «извратиться», настраивая дельта-индекс для корректной работы в случае, когда очень много новых или изменённых документов, хотя огромная скорость индексации позволяет организовать перестройку индекса по расписанию и это не скажется на работе собственно поиска.

SphinxSE — это версия, функционирующая как движок хранения данных для MySQL (требует патча и перекомпиляции базы), Ultrasphinx — это конфигуратор и клиент для Ruby (кроме присутствующего в дистрибутиве API), кроме этого есть плагины для многих известных CMS b блог-платформ, вики, которые заменяют стандартный поиск (полный список смотрите здесь: http://www.sphinxsearch.com/contribs.html)


Семейство Apache Lucene
  • Тип: отдельный сервер или сервлет, встраиваемая библиотека
  • Платформа: Java/кросс-платформенный (есть порты на множество языков и платформ)
  • Индекс: инкрементный индекс, но требующий операции слияния сегментов (можно параллельно с поиском)
  • Поисковые возможности: булевый поиск, поиск по фразам, нечёткий поиск и т.п. с возможностью группировки, ранжирования и сортировки результата
  • API и протоколы: Java API
  • Поддержка языков: отсутствует морфология, есть стемминг (Snowball) и анализаторы для ряда языков (включая русский)
  • Дополнительные поля: да, неограниченное количество
  • Типы документов: текст, возможно индексация базы данных через JDBC
  • Размер индекса и скорость поиска: около 20 Мб/минута, размер индексных файлов ограничен 2 Гб (на 32-bit ОС). Есть возможности параллельного поиска по нескольким индексам и кластеризация (требует сторонних платформ)
  • Лицензия: open source, Apache License 2.0
  • URL: http://lucene.apache.org/

Lucene — самый известный из поисковых движков, изначально ориентированный именно на встраивание в другие программы. В частности, его широко используют в Eclipse (поиск по документации) и даже в IBM (продукты из серии OmniFind). В плюсах проекта — развитые возможности поиска, хорошая система построения и хранения индекса, который может одновременно пополнятся, удалятся документы и проводится оптимизация вместе с поиском, а также параллельный поиск по множеству индексов с объединением результатов. Сам индекс построен из сегментов, однако для улучшения скорости рекомендуется его оптимизировать, что часто означает почти те же затраты, что и на переиндексацию. Изначально присутствуют варианты анализаторов для разных языков, включая русский с поддержкой стемминга (приведения слов к нормальной форме). Однако минусом является все же низкая скорость индексации (особенно в сравнении с Sphinx), сложность работы с базами данных и отсутствие API (кроме родного Java). И хотя для достижения серьёзных показателей Lucene может кластеризироваться и хранить индексы в распределённой файловой системе или базе данных, для этого требуется сторонние решения, так же как и для всех остальных функций — например, изначально он умеет индексировать только обычный текст. Но именно в плане использования в составе сторонних продуктов Lucene «впереди планеты всей» — ни для какого другого движка нет столько портов на другие языки и использования. Одним из факторов такой популярности является и очень удачный формат файлов индексов, который используют сторонние решения, поэтому вполне можно строить решения, работающие с индексом и производящие поиск, но не имеющие собственного индексатора (это легче реализовать и требования намного ниже).

Solr — лучшее решение на базе Lucene, значительно расширяющее её возможности. Это самостоятельный сервер корпоративного уровня, предоставляющий широкие поисковые возможности в качестве веб-сервиса. Стандартно Solr принимает документы по протоколу HTTP в формате XML и возвращает результат также через HTTP (XML, JSON или другой формат). Полностью поддерживается кластеризация и репликация на несколько серверов, расширена поддержка дополнительных полей в документах (в отличие от Lucene, для них поддерживаются различные стандартные типы данных, что приближает индекс к базам данных), поддержка фасетного поиска и фильтрации, развитые средства конфигурирования и администрирования, а также возможности бекапа индекса в процессе работы. Встроенное кеширование также повышает скорость работы. С одной стороны, это самостоятельное решение на базе Lucene, с другой — её возможности очень существенно расширены относительно базовых, поэтому если вам необходим отдельный поисковый сервер, обратите сперва внимание на Solr.

Nutch — второй известнейший проект на базе Lucene. Это веб-поисковый движок (поисковый механизм + веб-паук для обхода сайтов) совмещённый с распределённой системой хранения данных Hadoop. Nutch «с коробки» может работать с удалёнными узлами в сети, индексирует не только HTML, но и MS Word, PDF, RSS, PowerPoint и даже MP3 файлы (мета-теги, конечно), по сути — это полноценный поисковик-убийца Google. Шучу, расплата за это — значительное урезание функционала, даже базового из Lucene, например не поддерживаются булевы операторы в поиске, не используется стемминг. Если стоит задача сделать небольшой локальный поисковик по местным ресурсам или заранее ограниченному набору сайтов, при этом нужен полный контроль над всеми аспектами поиска, или вы создаёте исследовательский проект для проверки новых алгоритмов, в таком случае Nutch станет вашим лучшим выбором. Однако учтите его требования к аппаратной части и широком канале — для реального web-поисковика счёт трафика идёт на террабайты.

Вы думаете, никто Nutch не использует «по-взрослому»? Ошибаетесь — из самых известных проектов, о которых вы могли слышать, его использует поисковая система по исходным кодам Krugle (http://krugle.com/).

Но не только за счёт проектов-надстроек известен и популярен Lucene. Будучи лидером среди открытых решений и воплотив в себя множество отличных решений, Lucene первый кандидат для портирования на другие платформы и языки. Сейчас имеются следующие порты (я имею ввиду те, что более-менее активно развиваются и максимально полные порты):
  • Lucene.Net — полный порт Lucene, полностью алгоритмически, по классах и API идентичный перенос на платформу MS.NET/Mono и язык C#. Пока проект находится в инкубаторе, а последний релиз датирован апрелем 2007 года (порт финальной 2.0 версии). Страница проекта.
  • Ferretпорт на язык Ruby
  • CLucene — версия на языке С++, что обещает дать существенный прирост производительности. По некоторым тестам, он быстрее оригинала в 3 — 5 раз, а иногда и более (на индексации, поиск сравним или быстрее на всего 5 — 10%). Оказалось, что эту версию использует большое количество проектов и компаний — ht://Dig, Flock, Kat (поисковик для KDE), BitWeaver CMS и даже такие компании, как Adobe (поиск по документации) и Nero. Страница проекта
  • Pluceneреализация на Perl
  • PyLuceneреализация для Python-приложений, однако не полная и требует частично Java
  • Zend_Search_Lucene — единственный порт на язык РНР, доступный в составе Zend Framework. Кстати, он вполне работоспособен и как самостоятельное решение, вне фреймворка, я проделал эксперименты и в результате выделения весь поисковый механизм теперь занимает всего 520 Кб в одном-единственном РНР файле. Домашняя страница проекта: http://framework.zend.com/manual/en/zend.search.lucene.htm

Xapian
  • Тип: встраиваемая библиотека
  • Платформа: C++
  • Индекс: инкрементный индекс, прозрачно обновляемый параллельно с поиском, работа с несколькими индексами, in-memory индексы для небольших баз.
  • Поисковые возможности: булевый поиск, поиск по фразам, поиск с ранжированием, поиск по маске, поиск по синонимам и т.п. с возможностью группировки, ранжирования и сортировки результата
  • API и протоколы: С++, Perl API, Java JINI, Python, PHP, TCL, C# и Ruby, CGI интерфейс с XML/CSV форматом
  • Поддержка языков: отсутствует морфология, есть стемминг для ряда языков (включая русский), реализована проверка правописания в поисковых запросах
  • Дополнительные поля: отсутствует
  • Типы документов: текст, HTML, PHP, PDF, PostScript, OpenOffice/StarOffice, OpenDocument, Microsoft Word/Excel/Powerpoint/Works, Word Perfect, AbiWord, RTF, DVI, индексация SQL баз через Perl DBI
  • Размер индекса и скорость поиска: известны работающие инсталляции на 1.5 Тб индекса и количество документов в сотни миллионов.
  • Лицензия: open source, GPL
  • URL: http://xapian.org

Пока это единственный претендент на конкуренцию с господством Lucene и Sphinx, выгодно отличается от них наличием «живого» индекса, не требующего перестройки при добавлении документов, очень мощным языком запросов, включая встроенный стемминг и даже проверку орфографии, а также поддержку синонимов. Эта библиотека будет лучшим выбором, если у вас система на perl или же вам требуется развитые возможности остроения поисковых запросов и у вас происходит очень частое обновление индекса, при этом новые документы должны быть сразу доступны для поиска. Однако я не нашёл никакой информации о возможности добавлять к документам произвольные дополнительные поля и получать их с результатами поиска, поэтому связь системы поиска с вашей собственной может представлять определённые трудности. В пакет входит Omega — надстройка над библиотекой, которая готова для использования в качестве самостоятельного поисковика и как раз она отвечает за возможности индексации разных типов документов и CGI интерфейс.

Наверное, на этом наш обзор можно завершить. Хотя существует ещё множество поисковых механизмов, на проверку часть из них является портами или надстройками над уже рассмотренными. Например, промышленного уровня поисковый сервер для собственной CMS компании eZ, ezFind на самом деле не отдельный поисковик, а интерфейс к стандартному Lucene Java и включает его в свою поставку. Это же касается и компонента Search из их пакета eZ Components — он предоставляет унифицированный интерфейс для доступа к внешним поисковым серверам, в частности взаимодействует с Lucene сервером. И даже такое интересное и мощное решение, как Carrot и SearchBox — это серьёзно модифицированные версии той же Lucene, значительно расширенные и дополненные новыми возможностями. Самостоятельных же поисковых решений, с открытым кодом, которые полностью реализуют индексацию и поиск по собственных алгоритмах на рынке не так и много. А какое решение выбрать — зависит от вас и особенностей, часто совсем не очевидных, вашего проекта.

Выводы

Хотя окончательно принять решение, подходит или нет конкретный поисковик вашему проекту сможете только вы и, часто, лишь после детального исследования и тестов, однако некоторые выводы можно сделать уже сейчас.

Sphinx подойдёт вам, если необходимо индексировать большие объёмы данных в базе MySQL и вам важна скорость индексации и поиска, однако не требуются специфические возможности поиска вроде “fuzzy search” и вы согласны выделить на это отдельный сервер или даже кластер.

Если необходимо встроить поисковый модуль в ваше приложение, то лучше всего поиска готовые порты для вашего языка к библиотеке Lucene — для всех распространённых языков они есть, однако могут реализовывать далеко не все возможности оригинала. Если же вы разрабатываете приложение на Java, то Lucene однозначно лучший выбор. Однако учтите достаточную медленную индексации и необходимость частой оптимизации индекса (и требовательность к CPU и скорости диска). Для РНР это, по всей видимости, единственный приемлемый вариант полной реализации поиска без дополнительных модулей и расширений.

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

Ссылки по теме
Александр Лозовюк @aleks_raiden
карма
1,0
рейтинг 0,0
Браузерные игры, реалтайм, финансы, стартапы
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (62)

  • +3
    А еще Аксенов весёлый и его доклады прикольные - это я про автора Сфинкса :).
    • 0
      Да, помню как он отжигал на презентации своего проекта в МГУ :)
  • 0
    Спасибо за статью очень полезно. Давно уже думал познакомиться с такими системами. Больше всего рекомендовали Sphinx. +5
  • 0
    А где, помимо оф. сайта, можно найти примеры внедрения Sphinx? Движок крайне интересный и многообещающий, но слабопопуляризирован. Или скорее широко известен в узких кругах.
    • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        А кто не пользовался — можно прокомментировать сравнение? Стою перед выбором.
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Это было тогда? На данный момент что-нибудь изменилось — не вкурсе?
            Кстати, сфинкс склоняет слова нормально?
            • 0
              встроенный английский и русский стемминг, soundex для реализации морфологии
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                да, на упомянутом сайте потестил — вообще ни склоняет.
                жаль.
                мож чего не настроено.
    • 0
  • –2
    Какой, однако, нескромный первый абзац...
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Использую Sphinx ужо с год. Совет: если есть возможность, то нужно СРАЗУ пересобирать mysql со Sphinx Storage Engine. Это намного быстрей будет работать чем API, ну и в плюс можно с поисковым запросом использовать JOIN.

    PS: Скорость сфинкса поражает, как при индексировании так и при поиске ;)
    • +1
      При использовании JOIN'ов на таблицу с ENGINE=Sphinx могут возникнуть определенные... мм, не то чтобы проблемы - скорее особенности, которые в общем объясняются следующей фразой из документации по сфинкс:

      One very important note that it is much more efficient to allow Sphinx to perform sorting, filtering and slicing the result set than to raise max matches count and use WHERE, ORDER BY and LIMIT clauses on MySQL side. This is for two reasons. First, Sphinx does a number of optimizations and performs better than MySQL on these tasks. Second, less data would need to be packed by searchd, transferred and unpacked by SphinxSE
  • –5
    Полный УГ!!!!111oneone
  • 0
    огромное спасибо за обзор. многа букав конечно, но все прочитал.
    У нас недавно как раз вопрос поиска вставал. Свой выбор остановили на Сфинксе.
  • 0
    А откуда данные, что дефрагментация индекса lucene занимает столько же времени, что и полная переиндексация? Я замеры не делал, но субъективно — дефрагментация намного быстрее.

    Еще, кстати, по поводу Солр: у меня из коробки не заработал русский стемминг, пришлось ковырять исходники. Оказалось, что там русские буквы были не в той кодировке (вроде кои8 вместо утф8). В итоге удалось все заставить работать как надо, но, честно говоря, качеством стемминга я очень не доволен.

    Выбирал для своего проекта между Солром и Сфинксом, тогда отпугнуло то, что возможно неудобно будет возится с дельта-индексом, плюс показалось, что Солр вещь более проверенная временем. Теперь, наверное, надо будет искать время перевести поиск на Сфинкс.
  • 0
    На 2net.info был изначально aspseek, потом nutch, потом bobikzdoh.
    Плюсы натча - масштабируется, минусы - тяжелый как слон. Впрочем минус можно убрать за счет плюса - сделать его на несколько серверов.
  • 0
    У меня на форуме тоже сфинкс стоит. :)
  • +1
    Как использующий Xapian могу добавить, что его возможности поиска очень развиты, подход к самому поиску основан на математической модели Information Retrieval (http://www.xapian.org/docs/intro_ir.html). Есть возможность к каждому документу добавлять произвольный набор "value" (значений), по которым в том числе можно осуществлять поиск. Поиск по таким значениям не самый эффективный (лучше по обычным термам - словам документа), но с помощью value можно осуществить дополнительную фильтрацию результатов поиска.

    Интеграция с PHP & Python (что мы сами пробовали) - без особых проблем, расширение на SWIG есть для обоих. Возможность поиска на одном сервере - пожалуйста, если надо делать распределенную систему (поисковый сервер и веб-морды клиенты) - есть вариант доступа к поисковой БД по TCP. В этом случае индексация идёт на поисковом сервере, обращения на чтения - со всех остальных серверов (в том числе "наживую", т.е. во время индексации (доиндексации)). Индексация выполняется через транзакции, т.е. можно обеспечить логическую целостность обновления индекса.

    Для создании read-only кластера поисковых серверов индекс можно в момент, когда нет обращений к поиску, растащить хоть rsyncом по произвольному количеству read-only Xapian-слейвов.
    • +1
      Да, Xapian также поддерживает работу одновременно с несколькими индексами. Т.е. данные можно разбить и хранить в нескольких индексах, а искать по выборочному подмножеству индексов. Например, если у вас есть модели "Книги", "Газеты", "Журналы", вы можете завести для каждой модели свой индекс, и управлять результатами поиска, просто сочетая нужные индексы. Например "Книги и Газеты" или "Журналы и Книги". Вообще, схема разбиения зависит только от вашей фантазии. Если надо, растаскиваете индексы по разным машинам, и получаете распределённый поиск.

      Много читал про Sphinx, но так и не смог преодолеть неприязнь ко всем этим дельта-индексам, как ни старался. А Xapian, благодаря инкрементному поиску, я успешно интегрировал с Django. Самописная библиотека реагирует на сигналы моделей о создании/изменении/удалении, и сама, прозрачно для программиста вносит изменения в поиск. Всё получается быстро и удобно.
      • 0
        Одним из минусов Xapian я бы назвал не самую удобную документацию. Фактически источником информации являются статьи на сайте (несколько разрозненные), различные примеры в блогах, а также документация (Doxygen) по С++ API (родному) от Xapian.

        Часто в PHP-варианте API Xapian надо поглядеть в PHP-код обертки, в C++ API, подумать, а потом написать очередной кусок кода. Зато когда всё уже написано, получается логично и хорошо ;)
        • 0
          Про документацию, согласен, есть такой грех. Но API весьма неплох, и позволяет делать много интересных выкрутасов, например, искать похожие документы. Не просто удовлетворяющие такому-то запросу, а именно похожие на указанный тобой документ (или несколько документов), с сортировкой по релевантности, или как захочется. А если полазить в сети — почитать, что народ ещё вытворяет, волосы на голове шевелиться начнут!
    • 0
      Я вообще не в теме, сам ищу систему для поиска. В описании Xapian понравился внушительный список типов индексируемых документов, инкрементный индекс ну и API с моим любимым PHP))
    • 0
      нету сборки и родных бинарных модулей для win32, насколько я разобрался все же нету дополнительных полей там. Интеграция с базой через костыль с перл. морфологии нет даже простой
      • 0
        Насчет win32 - не знаю, не смотрел, да и мне не нужно.

        Полей как таковых в смысле БД нет, но можно при индексации к документу добавить value: Xapian::Document::add_value, где ключом является число (не очень удобно, заводим константы в коде), а значением - произвольная строка. При поиске с помощью OP_VALUE_RANGE ищем по этим значением (писал об этом выше).

        Насчет морфологии - есть stemming, то есть по сути изменение окончания слов по "образцу". См., например: Xapian::QueryParser::set_stemmer, http://xapian.org/docs/stemming.html
        • 0
          а многим нужно, так как разработка все же на Win32 часто.

          Стемминг не до конца морфология - вот в этом обсуждении там есть опеределния (http://mastertalk.ru/lofiversion/index.p…)

          да по многим характеристикам Xapian мощнее, но гораздо менее дружелюбный и простой для нормальной работы с ним :( потому я себе выбрал что-то среднее - скорее всего PHP-порт Lucene от Zend
          • 0
            Не знаю заранее, но было бы интересно, какова скорость полнотекстового поиска на Lucene, переписанном на PHP? Насколько отличается от реализаций на C/C++/Java?

            У полнотекстового поиска какая-то часть работы уходит на ввод-вывод, это несомненно (и здесь язык реализации не играет существенной роли), но есть всё-таки операции и на процессоре, и их часть обычно существенна.

            Если будете тестировать, напишите, интересно :)
            • 0
              сравнения сложновато делать - я не особо разработчик на Java чтобы запустить в идентичных окружениях Lucene оригинальный, но тестировал немного РНР порт, хотя не для статьи, надо будет написать. Там долго идет оптимизация индекса, остальное приемлемо. Да, напишу статью-исследование.
      • 0
  • 0
    MoinMoin (написанный на Python), например, поддерживает Xapian "искаропки".
  • 0
    Есть такой вопрос (может автор или кто-то исследовал, чтобы самому по всем подробно не рыть) -
    что-то из упомянутых движков может переваривать pdf и форматы ms office (ну вот сайт такой специфичный с кучей технической документации)?

    Пока что пробую использовать mnogosearch, способный работать с консольными юниксовыми конверторами в текст или html (pdftotext и т.п.), но мне он кажется не слишком быстрым при большом количестве страниц/файлов.
    • 0
      ну вроде как тот самый Xapian Может - почитайте внимательно я описывал возможные типы документов для поиска
    • 0
      тотже nutch имеет фильтры для очень большого числа разных типов документов

      pdfbox прекрасно выгребает все что нужно из pdf и легко интегрируется с lucene (имеет вызов в API возвращающий готовый для индексации lucene Document)
      для офиса тоже можно найти готовые решения или довольно быстро сделать свои

      тут вопрос в платформе поисковика, методе встаривания в основное приложение...

      была потребность делать поисковик - пересмотрел довольно много готовых решений (Java).
      nutch отпал довольно быстро. regain тоже.
      solr в принципе рассматривался, но требовалось чтото более легковесное и встраивоемое.
      в итоге на основе lucene сделал свою систему индексации, которая хорошо учитывает структуру сайта, способы формирования ссылок и т.п.
      в частности наступил на грабли с некоторыми готовыми краулерами в том плане, что ссылки host/app/page&par1=val1 и host/app/page&par1=val2 многими воспринимались как одна и таже страница ;(
      • 0
        Nutch все же для инет-поисковика типа мини-яндекса/рамблера, а не для локальных поисковиков по своему сайту/проекту. Для него и инфраструктура нужна соответственную
  • –8
    ДАЙТЕ ИНВАЙТЕ НА УПЯЧК111!!
    ВОТ МОЙ ВНОС В СИЛУ УПЧК
    http://awas1952.livejournal.com/56283.html
    http://awas1952.livejournal.com/55961.html

    forlepra@i.ua
  • 0
    А как насчет MySQL fulltext поиска? Оно конечно не такое быстрое, но для небльших проектов - вполне достаточно и никаких дополнительных извращний не требует.
    • 0
      а вы его реально попробуйте и тогда обсудим :)
      материал написан для случаев когда нужно РЕАЛЬНО искать в БОЛЬШОМ количестве информации - гигабайты и десятки/сотни, в некоторых случаях - терабайты!
  • 0
    Забыли про Яндекс.Сервер. А этомежду прочим довольно приличный и гибкий продукт, который составит хорошую конкуренцию описанным в статье.
    • 0
      не рассматривался так как закрытое решение
      • 0
        Хоть и закрытое, но бесплатное. Мы, например, остановились пока именно на нем. В финал вышли как раз Sphinx и Яндекс.Сервер. А остановились потому, что у яндекса с морфологией получше (там не стемминг, а словарь).
  • 0
    Использую Lucene.Net (порт Lucene под .Net). Выбрал его в первую очередь из-за широких возможностей поиска: fuzzy search; гибкая настройка boost'ов релевантности для разных параметров; фильтрация, сортировка результатов.

    Интеграция в систему прошла гладко, а вот с глюками проблем хватало. Основной глюк перекочевал в порт из джававской версии Lucene: при инкрементном индексировании была небольшая вероятность того, что навернется весь индекс. Естественно, когда инкрементное индексирование происходит часто, индекс довольно быстро наворачивается. К счастью, в самой-последней-из-свн версии Lucene.Net (2.3.1) наконей-то портировали утилиту для проверки и "ремонта" индекса (CheckIndex), и жить сразу стало веселей :)
    • 0
      может можно параллельно использовать ещё внешние инструменты для работы с индексом? lucy вроде так называется, lucy toolbox
      • 0
        Lucy - это ж вроде С-шный порт Lucene. Собственно, внешние инструменты использовать можно, т.к. индекс Lucene.Net, как и любого другого порта, полностью эквивалентен индексу оригинального Lucene. Я даже думал заюзать джавовский Lucene для ремонта индекса, но пока и портированный CheckIndex с этим справляется.
        • 0
          прошу прощения, имел ввиду это: http://www.getopt.org/luke/
          • 0
            Интересно.. Спасибо, попробую
  • 0
    а посоветуйте, пожалуйста, БД/движок для индексации _имён_, размеров, дат (но не содержимого файлов) файлов с возможностью поиска по %query%. В данный момент используется mysql, но при базе в пару гигов скорость сильно падает (с 2-3 секунд до десятка). Пару раз пробовал lucene, но на паре млн документов на %query% запросах его скорость не выше mysql'я
    • 0
      не проблема использовать sphinx, возможно и xapian подойдет.
      Lucene немного другой, хотя и для него пара гиг не проблема просто машина и настройка нужна
      • 0
        проблема-то не в паре гигов, в количестве документов, как мне кажется...
        wildcard query - это весьма ресурсоёмкий запрос.
        • 0
          при нормальных условиях окружения (читай - железе) это совсем не проблема. конечно, если не стремиться поставить все это и чтобы летало на P2 + 128 Мб :)
          • 0
            ну понятно тчо на 2х гигах тормозов не будет скорее всего, однако ж в таких условиях и mysql работать будет неплохо.
            ну, или быть может вы подскажете правильные настройки для люсена, чтобы проиндексировать 5-10 млн файлов (имя, расширение, размер, дата) так, чтобы wildcard query с лимитом, скажем, 100, выполнялся быстрее секунды на "среднем" компьютере с гигом памяти?
            • 0
              тут файлы не при чем. 5 - 10 млн документов (из четырёх полей информационных по которым поиски + индексное) это нормальный объем - сфинкс должен просто справиться.

              а вы уверены, что такая задача с такими условиями по плечу этому "среднему комптютеру"? это же часто физически нельзя, потому зачем требовать то что может заранее невозможно. А сфинкс попробовать стоит, уверен что обгонит простой mysql (SphixSE который)
              • 0
                сфинкс в своё время я, к сожалению, просто неосилил :(
                что ж, пришло время попробовать его ещё раз, видимо
  • 0
    По поводу Сфинкса. Приходится не по своей воле работать с этим дебильным поисковым движком. Не знаю, может в плане производительности он действительности хорош, но в плане удобства в эксплуатации — редкостная ХУЙНЯ. Особенно быдлокодерный API для PHP.
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    А может кто-нибудь рассказать про поддержку языков стран СНГ этими движками?
  • 0
    спасибо, статья все еще актуальна.
    Особенно если с поисковиками раньше не сталкивался.
    • 0
      Спасибо.
      За это время проекты подросли, появилось несколько новичков, например, Elastic Search
  • 0
    Народ, а какие из этих либов для .NET поддерживают поиск с учетом транслитерации?
    Т.е. мне нужно найти по строке поиска «вебман» сущность с названием «WebMoney».
    Подскажите?

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