За этим, наверное, лучше не ко мне.
Те. C# я понимаю достаточно, чтобы суметь API портировать когда-нибудь.
Но еще не портировал во-1х плюс в бою не использую никак во-2х.
А в комментариях (к другим статьям) вроде как отмечались боевые .NET пользователи.
Вот как раз логика работа ранкеров такая.
Проблема в том, что если запрос встретился в том поле полностью, уже получается максимальный вес фразы.
Безотносительно длины самого поля, и факта полного совпадения поля (!) с запросом.
Так исторически сложилось вот.
В версии 0.9.8 факт совпадения всего поля (!) вообще нельзя установить, не хватает данных в индексе.
Технически можно только факт совпадение-в-начале установить и забустить.
Но нужно приписать новый ранкер.
В версии 0.9.9 (текущая бета) добавилось еще всякое.
Ранкеров не добавилось, зато добавились модификаторы ^ и $, и соотв-но флажок «конец поля» в индексе.
Но все еще нужно приписать новый ранкер.
В версии 0.9.10 (текущий транк) добавился (барабанная) дробь как раз такой ранкер.
Называется sph04 (полностью SPH_RANK_SPH04), бустит совпадения в начале поля и в конце поля.
Возможно, бэкпортнем в 0.9.9 тоже.
Без ранкера сделать что-то непросто, но в определенной мере тоже можно.
Убирать ручками пунктуацию и верхний регистр из поля и запроса, посчитать crc32 поля, сохранить атрибутом.
Затем ранжировать по @weight+if(fieldcrc==querycrc,1000,0)
Криво, знаю, но может и пригодится таки кому.
Про девушек — видимо стеммер не осиливает, можно пробовать добавить правило в словоформы, мапить форму «девушек» в стем (!) вручную.
Надо пытать Firmbook-овцев, я только
разместил...читаю доклад.Те. C# я понимаю достаточно, чтобы суметь API портировать когда-нибудь.
Но еще не портировал во-1х плюс в бою не использую никак во-2х.
А в комментариях (к другим статьям) вроде как отмечались боевые .NET пользователи.
В пределах индекса выбирать нельзя, словарь ровно один.
Соотв-но для перемешанных данных я бы делал несколько источников и индексов.
И к каждому привязывал свой словарь.
Я сам никогда не делал, существуют ли словари, не знаю :(
sphinxsearch.com/contacts.html
Поправил!!!
Причем вполне понятно, что это за случай, и почему у Сфинкса «из коробки» не все гладко :)
Кстати, если статью читать внимательно, несложно добиться всего того же самого и на Сфинксе, в общем-то.
Другое дело, что на крохотных коллекциях это и не нужно, ага.
:) Пока данные влазят в память, скорость не беспокоит, и поиск по уникальным словам — оно работает, да.
б) В длинных планах есть, в коротких нет. Если надо спешно, welcome to sphinxsearch.com/consulting.html
Нужно, чтобы кто-нибудь еще объяснил тогда.
> Если можно это сделать без изучения алгорима ранкера B52
:) Можно, наверное.
Статья таки скорее для тех, кому интересно изучить потроха.
Нужно, чтобы
Вот как раз логика работа ранкеров такая.
Проблема в том, что если запрос встретился в том поле полностью, уже получается максимальный вес фразы.
Безотносительно длины самого поля, и факта полного совпадения поля (!) с запросом.
Так исторически сложилось вот.
В версии 0.9.8 факт совпадения всего поля (!) вообще нельзя установить, не хватает данных в индексе.
Технически можно только факт совпадение-в-начале установить и забустить.
Но нужно приписать новый ранкер.
В версии 0.9.9 (текущая бета) добавилось еще всякое.
Ранкеров не добавилось, зато добавились модификаторы ^ и $, и соотв-но флажок «конец поля» в индексе.
Но все еще нужно приписать новый ранкер.
В версии 0.9.10 (текущий транк) добавился (барабанная) дробь как раз такой ранкер.
Называется sph04 (полностью SPH_RANK_SPH04), бустит совпадения в начале поля и в конце поля.
Возможно, бэкпортнем в 0.9.9 тоже.
Без ранкера сделать что-то непросто, но в определенной мере тоже можно.
Убирать ручками пунктуацию и верхний регистр из поля и запроса, посчитать crc32 поля, сохранить атрибутом.
Затем ранжировать по @weight+if(fieldcrc==querycrc,1000,0)
Криво, знаю, но может и пригодится таки кому.
Разве что в комментах МНОГО народу вдруг захочет про что-то другое.
:)
А вот нужные для исправлений плюшки типа SetSelect только в 0.9.9 появились.