Как стать автором
Обновить

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

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

PS: Скорость сфинкса поражает, как при индексировании так и при поиске ;)
При использовании 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
Полный УГ!!!!111oneone
огромное спасибо за обзор. многа букав конечно, но все прочитал.
У нас недавно как раз вопрос поиска вставал. Свой выбор остановили на Сфинксе.
А откуда данные, что дефрагментация индекса lucene занимает столько же времени, что и полная переиндексация? Я замеры не делал, но субъективно — дефрагментация намного быстрее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Публикации

Истории