Как стать автором
Обновить
402
0
Andrew Aksyonoff @shodan

Пользователь

Отправить сообщение
> Вы искажаете смысл моих слов.

Это нормально.
Тк. вы начали заход с того, что искажете смысл моих.

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

> tsearch встроен в мощную СУБД и поэтому вам вместе с его богатыми возможностями доступны еще и возможности СУБД.

(зевает) А встраиваемый в MySQL клиент SphinxSE предоставляет возможность "встроить" результаты поиска в мощную СУБД MySQL и вместе с богатыми возможностями Сфинкса сделать доступными еще и возможность СУБД. А это значит... ну и т.д

> Моя основная мысль проста

Пока что все ваши комментарии действительно сводятся к одной простой мысли - tsearch умеет вообще всё, что нужно прогрессивному человечеству; не то, что этот ваш Sphinx.

Sphinx действительно умеет далеко не все, но когда вы начинаете расхваливать tsearch, противопоставляя его Sphinx во-1х и упоминая про всякое, что у нас отлично делается во-2х - это выглядит довольно странно.

Видимо, Бартунов вам больше друг, чем объективность.
> мне интересно будет написать или перевести обзор бесплатных

(вздыхает)
Нет бы забенчмаркать!

Могу поучаствовать в части про Сфинкс.
Чисто во избежание :)
> в чем подразумевается учет позиций при ранжировании?

Я хочу, чтобы документ с точным совпадением с запросом - был отранжирован выше всех.

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

Можно такое?

> на больших базах xapian ищет быстрее Люцены.

Ваша исходная формулировка - "умеет все что sphinx ... и работает быстрее"

Извините, почему-то не догадался сразу, что речь была про lucene!!!

> Распределенный поиск что в вашем понимании?

Возможность разбить коллекцию на несколько машин и параллельно искать на каждой.
Затем агрегировать результаты.

Я краем глаза глянул в исходники, и этого не увидел.
Увидел страшное, похожее на доступ к данным удаленного индекса по сети... :)

> Поддержка атрибутов это site:habrahabr AND sphinx ?

Нет, это price>=100 and price<=200 and regionid=1234 and (1,3,5,7) in tags and fulltext-match('sphinx xapian benchmark')

В исходниках увидел только range и только по строкам.
Но, правда, смотрел пока невнимательно.

> бенчмарки где-то были, в mailing lists точно были.

Можете несколько уточнить ссылку? ;)
> Дело в том, что при низкой селективности пользователю в подавляющем большинстве случаев не важны уже даже десятки тысяч матчей.

Пользователю не нужны, факт.
Но это подмена понятий.
Поскольку обработать матчи-кандидаты все равно при этом нужно.

> Для таких любопытных и практически важных :)

Ирония неуместна.
Случай нередкий.

Ищем в базе пользователей на 10M человек тов. Иванова из Урюпинска.
Ивановых в базе 500K, Урюпинских 100K.

Ищем в базе на 20M предложений самый дешевый ipod nano в Москве.
Предложений ipod nano 20K, из них в Москве ровно половина, 10K.
Не обработаем хоть одно - рискуем показать неверный результат.

А в базе на 10K записей все отлично, факт.
Для нее не нужен Сфинкс.
Для нее прекрасно работают MySQL fulltext, tsearch, и даже LIKE '%keyword%'.

> в tsearch и для них есть фишки, все зависит от задачи.

С ваших слов, складывается впечатление, что tsearch умеет вообще все и вообще лучше всех.
Типа для всего есть "фишки", правда непонятно, какие ;)

Это очень круто, Sphinx не такой.
Впрочем, если фишки типа "будем резать result set", то можно спать спокойно ;)))
> Но почему именно Sphinx? Есть же ещё

Есть много чего еще.
Каждый волен выбирать наиболее удобный инструмент под свою задачу.

Сфинкс, очевидно, не серебряная пуля и (пока) не по всем параметрам лучше всех.
Мы над этим работаем ;)
> Xapian (xapian.org) умеет и всё то что умеет sphinx и еще много всего

;) Это, мягко говоря, неправда.
Учет позиций слов при ранжировании - в Xapian отсутствует.
Распределенный поиск - в Xapian отсутствует.
Поддержка атрибутов - в Xapian отсутствует.
Это то, что видно с ходу.

> и работает с очень большими базами быстрее,

Покажите результаты бенчмарков?
Мне опять-таки давно интересно, но времени нету.
> поиск осуществлять только в наборе документов, доступных для чтения данному юзеру?

Можно - причем есть несколько механизмов.

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

Ссылку можно?
По которой описывается подробнее, что это за морфология эдакая волшебная?
Потому что Гугл по запросу "tsearch2 morphology" находит токма - "Tsearch uses the dictionary words for morphology"

> словари синонимов и тезауруса (в том числе пользовательские),

Ну, эта.
Словари опять же отлично есть и в Сфинксе.

Можно для нормализации словоформ пользовать, можно для организации тезаурусов.
Можно скрещивать со стеммерами, для неизвестных словоформ.
И успешно используют.

Только мне наглости не хватает утверждать, что с их помощью можно сделать "идеальный" поиск ;)
Даром, что тоже бесплатный, и тоже с открытым кодом ;))
> Поэтому вы можете с его помощью сделать loose match по индексу, быстро вернув бОльшее кол-во результатов, чем вам нужно,

...и поиметь совершенно отвратительную производительность, если full-text запрос возвращает 10-100K совпадений, не говоря о миллионах.

Been there, done that, implemented attributes in Sphinx for this very reason.
> порога в несколько терабайт, как у Сфинкса, попросту нет.

Дяденька, про "порог" вы щаз сами придумали зачем-то.
Интересно, зачем?

2 TB это известная мне существущая БОЕВАЯ инсталляция, а не какой-то "порог".
Добавить побольше машин, будет урабатывать и побольше данных.

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

> с обратным индексом, который реализован в tsearch,

Забенчмаркайте, опубликуйте результаты.
Мне несколько бежавших с tsearch человек сообщало, что Сфинкс таки быстрее.
Но конкретных цифр нет.
Там написано, если дословно -

Final licensing price would depend on the application character, licensing volume, retail price, royalty policy, amount of required technical support, etc. Guideline price for small-volume (5-20 copies) royalty-free licensing is $100/copy.

Формально написано именно то, что я написал тут выше - соотв-но ценник $100/copy приведен скорее в порядке примера (см. guideline).

Но я согласен, что формулировка недостаточно четкая - глаз читатющего явно цепляется за $100/copy, мысль останавливается, написать мне письмо и уточнить уже сразу страшно :-) Изменю формулировку, да.
Ну до 2 териков скейлимся - думаю и 4-5 выдержим.
Скажем так - сильно больше половины. Дополнительные разработчики, кроме меня, появились относительно недавно.
Ыыы. Там вообще-то условия "пишите, договоримся" - но видимо все читают только цифирь $100/copy и не читают всё, что вокруг нее написано. 8-)

Если нужно 10 лицензий для распространения в составе программно-аппаратного комплекса с ретейл ценой $15000 - да, ценник будет $100 за копию.

Если нужно 10000 копий для энциклопедии с ретейл ценой $10 - ценник будет куда меньше.
Не родня! (c)
Они появились неколько месяцев назад, в одном из снапшотов 0.9.8 - в предыдущей "release" версии их не было. Плюс не все сразу заработало. ;)
Обязательно продолжать :-) Больше полезного - не меньше полезного!
Увы. Я только за, но - тупо и прозаично не хватает времени на всё. :(
В посте вроде написано - что можно в трех!!!

Best Project + Best Project for the Enterprise + Best New Project

Спасибо :)

Информация

В рейтинге
Не участвует
Работает в
Зарегистрирован
Активность