хм. полезная штука

Система хорошая, но русский словарь пока не доделан. Например,
ищу по слову "перелом", а мне вместе с ним выдаёт "перелив",
"перелить". И ещё вложенные скобки в языке запросов не работают.
А в остальном всё очень хорошо. Быстро и качественно.

а если бы не заморачивались на gpl, можно было бы превертеть mystem

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

"Сфинкс" - это на 90% swish (swish++ etc.)

Русский "автор" взял систему swish и добавил своих добавок для того, чтобы брать текст из базы данных (очень неуклюжих, громоздких и очевидных) - которые затем проиндексируются swish-ем.

Насколько я помню документацию, в ней нет прямого указания на автора/ов первоначальной программы.

Более того, я совершенно не понимаю, зачем нужен какой-то отдельный "сфинкс", если простые скрипты могут сделать dump любых текстов из любых баз данных - которые проиндексируют любые существующие поисковики!

Я не вижу смысла в этой программе, а как сисадмин, я не вижу в ней даже удобства, т.е. экономии сил. Конфигурацию все равно надо писать SQL-текстами, и разницы с вызовом данных обычным скриптом из shell или perl -- нет, экономии сил нет.

Ты абсолютно не ориентируешься в вопросе.
Возьми исходники и найди хоть одно пересечение со swish.
Можешь использовать супер систему немецких товарищей по нахождению плагиата про которую тут недавно писали.

Тебе как сисадмину весьма далеки проблемы поиска ифнормации в гигабайтах данных.

> Более того, я совершенно не понимаю, зачем нужен какой-то отдельный "сфинкс", если простые скрипты могут сделать dump любых текстов из любых баз данных - которые проиндексируют любые существующие поисковики!

Например? Яндекс что ль? Или GDS? А поиск по персональной информации ты как организуешь - тоже через яндекс? :D

> Я не вижу смысла в этой программе, а как сисадмин, я не вижу в ней даже удобства, т.е. экономии сил.

А как разработчик? Нам вот очень надо.

> Более того, я совершенно не понимаю, зачем нужен какой-то отдельный "сфинкс", если простые скрипты могут сделать dump любых текстов из любых баз данных - которые проиндексируют любые существующие поисковики!

С этого места поробнее, плиз. Опишите технологию и замерьте скорость работы таких скриптов, с учётом, что (к примеру) многогигабайтные данные обновляются каждые 15 минут. Я могу сказать про свой опыт. Форум в помиллиона постов индексируется за 30 секунд на стареньком сервере. Поиск с морфологией и языком запросов. Никакие известные мне на сегодняшние день технологии не дают такой скорости и такого качества поиска.

> Конфигурацию все равно надо писать SQL-текстами

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

> проблемы поиска ифнормации в гигабайтах данных

для этого IMHO лучше подходит lucene (http://lucene.apache.org) от апача + hadoop (http://lucene.apache.org/hadoop) с hdfs (http://lucene.apache.org/hadoop/hdfs_design.html), очень все шоколадно и с русскими словарями проблем нет.

P.S. вру, была единственная пролема а русским словарем, не искались цифры, решается маааленьким патчиком в RussianAnalyzer.

> проблемы поиска ифнормации в гигабайтах данных

правда у нас уже террабайты пошли ;-)

по ссылке не ходил, но в чём плюс по сравнению с tsearch2 ?
если применительно к постгресу ?

> если применительно к постгресу ?

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

> для этого IMHO лучше подходит lucene (http://lucene.apache.org) от апача

Из пушки по воробьям. Совершенно другого класса продукт.

А разве select * from table where someRow like '%search%' уже не работает?

> А разве select * from table where someRow like '%search%' уже не работает?

для ста гигабайт можно сказать - не работает :)

Я сначала подумал, что речь идёт про поиск по голосовым запросам с помощью одноимённой программы распознавания речи...

> правда у нас уже террабайты пошли ;-)

земельные байты?

>> проблемы поиска ифнормации в гигабайтах данных

>для этого IMHO лучше подходит lucene (http://lucene.apache.org) от апача + hadoop (http://lucene.apache.org/hadoop) с hdfs (http://lucene.apache.org/hadoop/hdfs_design.html), очень все шоколадно и с русскими словарями проблем нет.

http://jayant7k.blogspot.com/2006/06/benchmarking-results-of-mysql-lucene.html

http://www.mysqlperformanceblog.com/files/presentations/RIT2007-Sphinx.pdf

s/террабайты/терабайты/g ;)

Troop, спасибо за линки!

+1 ты не дождешь окончания работы этого запроса. на 6 миллионах записей проверял ради прикола. ждать устал :-) ЗЫ залогинься ;)

Люди добрые, а подскажите плиз вот в таком вопросе. Есть MySQL база > 100 миллионов строк, в каждой ячейке записаны текстовые строки длиной от 2 до 50 символов. Обычный SQL-запрос SELECT ... LIKE '%слово%' занимает от 4 до 5 минут и грузит сервер по полной программе. Насколько может ускорить процесс эта или какая-нибудь другая прога?

Думаю sphinx по твоей базе будет выдавать результат меньше чем за секунду. Ну или в этом районе - зависит от множества параметров как-то - железо, нагрузка на сервере в момент поиска и прочие подобные вещи.

(Не в тему)

Йо, я на главной!

> > проблемы поиска ифнормации в гигабайтах данных > для этого IMHO лучше подходит lucene

Чем лучше? :-)

> > > проблемы поиска ифнормации в гигабайтах данных > для этого IMHO лучше подходит lucene

> Чем лучше? :-)

А вы попользуйте и то и то.
Скорость индексации у них одинакова (если Lucene выставить нормальный буффер и не делать flush после каждой записи).
Скорость поиска соизмерима
+ У Lucene обновляющийся "на лету" индекс.
+ У Lucene возможность одновременного доступа на чтение и изменение индекса.
+ У Lucene Возможность конкуретного (из разных потоков или приложений даже если они на разных языках писаны) изменения индекса.
+ У Lucene возможность merge разных ветвей индекса.
+ У Lucene wildcard, fuzzy поиск. Использование regexp, скобок. Поиска по диапазону дат.
+ У Lucene есть имплементации на Java, .NET, C, C++

А что есть у Sphinx? Одно "монолитный" индекс просто не подходит под многие задачи.

У Lucene в N раз медленнее индексация
У Lucene в N раз медленнее поиск
Распределение и распараллеливание поиска в Lucene делается очень мучительно, с Сфинксе - одним изменением конфига
У Сфинка поиск не только по диапазону дат, а по диапазону любого аттрибута.
У Сфинкса есть встроенная сортировка по любому аттрибуту.
Релевантность результатов поиска у Lucene сосет по полной
У Сфинкса встроенная группировка результатов по любому аттрибуту.

> У Lucene в N раз медленнее индексация
Просто не умеете его использовать. По умолчанию да, медленная, но все настраивается.

> У Lucene в N раз медленнее поиск
Ложь.

> Распределение и распараллеливание поиска в Lucene делается очень
> мучительно, с Сфинксе - одним изменением конфига
Не правда ваша.

> У Сфинка поиск не только по диапазону дат, а по диапазону любого аттрибута.
У Lucene тоже.

> У Сфинкса есть встроенная сортировка по любому аттрибуту.
Удивили :)

> Релевантность результатов поиска у Lucene сосет по полной
Ага. Очень убедительно.

> У Сфинкса встроенная группировка результатов по любому аттрибуту.
Не пробовал в Lucene, не задавался целью.

> У Lucene в N раз медленнее индексация > У Lucene в N раз медленнее поиск

причем N отрицательное число ;-)

> Распределение и распараллеливание поиска в Lucene делается очень мучительно, с Сфинксе - одним изменением конфига

Там отлично все раcпараллеливается (см код), можно строить кластеризацию индексов на раз (каждый из кластеров лежит либо на серевом доступном месте, либо по hdfs разается.

> Релевантность результатов поиска у Lucene сосет по полной

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

....

далее надоело

P.S. я не юзал и не хаю его, но с таким непониманием говорить о lucene ... которую вы по хоже просто попробовали чуток и не доразобрались что и как.

P.P.S. + mysql вообще на базу данных слабо похоже ;-)))

s/серевом/сетевом/g

> > У Lucene в N раз медленнее поиск > Ложь.

Бенчмарк Зайцева показывает, что таки медленнее (хотя и не в разы, конечно). Это несмотря, что у Sphinx ранжирование по умолчанию сложнее. Есть другие бенчмарки?

> > Распределение и распараллеливание поиска в Lucene делаетс > > очень мучительно > Не правда ваша.

Извиняюсь, но там просто для индексации базы надо код дописывать. Потому как Lucene это вчистую библиотека.

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

> > У Сфинка поиск не только по диапазону дат, а по диапазону любого аттрибута. > У Lucene тоже.

Говорят, на "больших" (100K-1M) result sets скорость тоскливая очень.

> > Релевантность результатов поиска у Lucene сосет по полной > Ага. Очень убедительно.

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

>> Так в этом и есть главный минус tsearch2, что он применим только к постгресу.
это то понятно :)
вопрос в том дает ли Sphinx какие либо преимущества по сравнению с tsearch2 в случае с посгресом.

> Бенчмарк Зайцева показывает, что таки медленнее (хотя и не в разы, конечно)
На заборе тоже много чего пишут ;)

> Потому как Lucene это вчистую библиотека.
Верно. Среди "frontend" есть, к примеру, Compas.
http://www.opensymphony.com/compass/

Другие быстро можно через Google найти.

> Говорят, на "больших" (100K-1M) result sets скорость тоскливая очень.
В одном проекте проиндексированно более 10Gb файлов. Поиск ведется без нареканий. К скорости поиска и обновления индекса у заказчика нареканий нет.

>В одном проекте проиндексированно более 10Gb файлов. Поиск ведется без нареканий. К скорости поиска и обновления индекса у заказчика нареканий нет.
О невероятно!
У заказчика нареканий нету это самая офигительно глубокая оченка для сравнения производительности.
А то что у заказчика поиск по документам идет 3 раза в день, и если оно ищет 1 сек, вместо 0.1 сек, то это мало кого волнует.

> У заказчика нареканий нету это самая офигительно глубокая оченка для сравнения производительности.

Эта оценка применимости данного продукта для комерческого использования не более.

> А то что у заказчика поиск по документам идет 3 раза в день, и если оно ищет 1 сек, ...
Вы знаете этот проект лучше меня? Занятно :)

Что бы было написано не на заборе
предлагаю сравнить для начала скорость индексации базы
данных Wikipedia, которая доступна для скачивания и хранится в MySQL.
Как такой вариант ?

> Как такой вариант ?
Можно попробовать. Только у меня нет MySQL. Если вы готовы предоставить ее в удобоваримом формате вне MySQL, то я готов написать на Lucene консольный индексатор.

> > Бенчмарк Зайцева показывает, что таки медленнее > На заборе тоже много чего пишут ;)

Очевидно, доклад на EuroOSCON теперь считается забором.

Повторюсь, у вас таки есть какие-то другие результаты сравнения Sphinx vs. Lucene по скорости? Уже приведите ссылки, всем будет интересно.

> Верно. Среди "frontend" есть, к примеру, Compas. Другие быстро можно через Google найти.

Напомню, мы говорили о распределенном поиске.

Вы утверждали, что при помощи Lucene он делается легко и непринужденно. Это не совсем так: при помощи самой Lucene (библиотеки) легко не делается вообще ничего, действительно нужен frontend.

Вы очевидно лучше знаете мир Lucene. Приведите, пожалуйста, ссылку на frontend для Lucene - который позволяет легко сделать распределенный поиск по *базе*?

> В одном проекте проиндексированно более 10Gb файлов.

10 GB файлов doc/pdf или 10 GB текста? Это принципиально разные объемы.

> Поиск ведется без нареканий. К скорости поиска и обновления индекса у заказчика нареканий нет.

В проекте Boardreader при помощи Sphinx проиндексировано 1500 GB текста. К скорости поиска и обновления индекса у заказчика тоже нареканий нет.

> Можно попробовать. Только у меня нет MySQL. Если вы готовы предоставить ее в удобоваримом формате вне MySQL, то я готов написать на Lucene консольный индексатор.

Мой ICQ - 369 510 335
Давайте обсудим.
нам интересно какие у lucene результаты.

> Это не совсем так: при помощи самой Lucene (библиотеки) легко не делается вообще ничего,
Ага. Ага. А с помощью библиотеки по работе с изображениями ничего с изображениями нельзя сделать.

> Приведите, пожалуйста, ссылку на frontend для Lucene - который позволяет легко сделать распределенный поиск по *базе*?
Compass? Руки + Java/.NET/C/C++ ? Ах да, голова еще нужна.

> 10 GB файлов doc/pdf или 10 GB текста? Это принципиально разные объемы.
DOC / PDF / Plain Text. Всего по маленьку. В основном чистый текст. Нормативная документация за туеву кучу лет.

> К скорости поиска и обновления индекса у заказчика тоже нареканий нет.
Я рад за них.

В треде ни разу не сказал, что Sphinx г*но. Только указывал на не знание возможностей Lucene. Не нужно читать между строк.

> Давайте обсудим.
> нам интересно какие у lucene результаты.
Мне тоже интересно. Вечером свяжусь.

Если вас не затруднит, то не могли бы вы потом опубликовать результаты ваших тестов?

Сам я lucene не использовал, зато использовал sphinx. К скорости работы сфинкса претензий нет, но, как я понял, возможностей у lucene больше и результаты тестов производительности были бы весьма интересны.

> > при помощи самой Lucene (библиотеки) легко не делается вообще ничего, > Ага. Ага. А с помощью библиотеки по работе с изображениями ничего с изображениями нельзя сделать.

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

Вы зачем-то убрали слово "ЛЕГКО", а оно ключевое.

Дописать ВРУЧНУЮ энное количества кода, которое вынет данные из базы и сунет в Lucene или там размажет поиск на кластер всегда можно, никто с этим спорит. Более того, никто даже не спорит, что это легче, чем с нуля.

Только речь не о том, что же ТЕОРЕТИЧЕСКИ возможно РУЧКАМИ дописать к продукту - а о том, что и как продукт УЖЕ УМЕЕТ делать из коробки.

Кстати, вы удивитесь, но с помощью только лишь (!) библиотеки по работе с изображениями вам с теми изображениями сделать действительно ничего не удастся.

DLL-ки плагина к Фотошопу для получения из файла с картинкой A файла с обработанной плагином картинки B обычно недостаточно - многим для этого требуется еще и сам Фотошоп.

> > Приведите, пожалуйста, ссылку на frontend для Lucene - который позволяет легко сделать распределенный поиск по *базе*? > Compass?

Compass умеет *распределенный* поиск?

http://www.google.com/search?hl=en&q=site%3Awww.opensymphony.com+distribu...

> В треде ни разу не сказал, что Sphinx г*но. Только указывал на не знание возможностей Lucene.

Ну разве вас в огульных наездах на Sphinx кто-то обвиняет? :)

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

Конкретно, про сравнительную скорость поиска Sphinx vs. Lucene - и про легкость организации того распределенного поиска (пусть с помощью frontend, а не одной лишь Lucene).

> Вы зачем-то убрали слово "ЛЕГКО", а оно ключевое.
Вашу бы энергию да в мирные русла.

Согласен с вами по всем пунктам. Убедили, спасибо.

> возможностей у lucene больше

Я бы сказал, наборы возможностей разные.

Чего-то нет в Sphinx, чего-то нет в Lucene.

> Вашу бы энергию да в мирные русла.

Про якобы ложные бенчмарки понятно, спасибо ;)

А вот про Lucene-фронтэнд для распределенного поиска все еще интересно, кстати.

Знаю только Nutch, но вроде (вроде) не совсем то.

> Про якобы ложные бенчмарки понятно, спасибо ;)
:) у меня нет нужных для вас цифр.

> А вот про Lucene-фронтэнд для распределенного поиска все еще интересно, кстати.
Какое понятие (функционал) в "распределенное" вы вкладываете?

> Какое понятие (функционал) в "распределенное" вы вкладываете?

Распределенный на несколько серверов поиск по отдельным частям большого индекса.

>> Какое понятие (функционал) в "распределенное" вы вкладываете?

> Распределенный на несколько серверов поиск по отдельным частям большого индекса.

индекс размером 140 гигов (на каждой машине под hdfs такой размер), квери весьма непростые (размером до 4096 байт), с использованием логических операндов, операндов близости слов, группировка скобками и бустинг скоринга, время отклика не превышает 200 мсек. Самих данных за терабайт, помаленьку подливаются и индексируются на лету новые данные (не много).

> индекс размером 140 гигов (на каждой машине под hdfs такой размер),

Интересно.

Вот эти 140 GB, которые на каждой машине, это полная реплика индекса или кусок?

Если кусок, то сколько всего машин в кластере?

> время отклика не превышает 200 мсек

А сколько документов находит типичный запрос?