Thread: hstore - релевантность
Можно ли на основе текущего кода реализовать такой поиск hstore, который возвращал бы значения, отсортированные
по степени близости к искомому?
Т.е, например, при поиске хэша { ‘k1’=>’v1’, ‘k2’=>’v2’, ‘k3’=>’v3’ }, возвращались бы сначала точные совпадения,
потом – совпадения по 2м ключам, потом по 1му ключу..
Или использовалась бы какая-нибудь другая функция, определяющая релевантность.
При этом, естественно, хочется избежать варианта, когда выбираются все записи, считается релевантность и выдается результат..
Записей слишком много, порядка миллионов..
> Можно ли на основе текущего кода реализовать такой поиск hstore, который > возвращал бы значения, отсортированные > по степени близости к искомому? > > Т.е, например, при поиске хэша { ‘k1’=>’v1’, ‘k2’=>’v2’, ‘k3’=>’v3’ }, > возвращались бы сначала точные совпадения, > потом – совпадения по 2м ключам, потом по 1му ключу.. > > Или использовалась бы какая-нибудь другая функция, определяющая > релевантность. > > При этом, естественно, хочется избежать варианта, когда выбираются все > записи, считается релевантность и выдается результат.. Написать ф-цию ранжирования не сложно, но избежать выборки всего честным образом невозможно... Дело в том, что ф-ция ранжирования будет вызываться для всех найденных значений. Можно сделать так (образец есть в contrib/pg_trgm): Создать ф-цию "похожести" двух hstore, возвращающую float от 0(нет ничего общего) до 1 (тождественность) и операцию похожести, возвращающую true, если аргументы похожи и false в противном случае. Операция базируется на ф-ци измерения похожести и "уровне отсечения", хранимом в статической переменной в сошке. Т.е. если похожесть меньше уровня - возвращаем false. Индекс также можно обучить использовать этот уровень. Недостаток такого решения: априори не известна величина "уровня отсечения" - если он мал, находиться будет практически все и всегда, если велик - велика вероятность вообще не найти хотя бы сколько-нибудь похожих записей. -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
А что насчет tsearch2 ? Допустим, я хочу найти документы по словам "моя мама мыла раму". Хочу получить сначала точные совпадения, потом "мама мыла раму", "моя мыла раму",..., потому "мыла раму", отсортированные по релевантности. Скажем, первые 100 записей. Будет ли сделана 1) выборка всех сколько-нибудь релевантных документов (например 1000000), затем сортировка их всех (плохой вариант) 2) выборка наиболее релевантных документов (100) сразу, согласно индексу, без сортировки. Насколько, вообще, используемые tsearch2 алгоритмы близки современным поисковым движкам: yandex/google... ?
On Mon, 7 Nov 2005, Ilia Kantor wrote: > > А что насчет tsearch2 ? > > Допустим, я хочу найти документы по словам "моя мама мыла раму". > Хочу получить сначала точные совпадения, потом "мама мыла раму", "моя мыла > раму",..., потому "мыла раму", отсортированные по релевантности. > Скажем, первые 100 записей. ты определись с запросом сначала, а потом спрашивай. Судя по всему, ты хочешь "моя OR мама OR мыла OR раму" и релевировать документы ты хочешь по кол-ву попаданий слов. Сразу скажу, что порядо слов для нас не важен, так что если ты хочешь фразу поискать, то пользуй совет Mike Rylander http://www.sai.msu.su/~megera/oddmuse/index.cgi/Tsearch_V2_Notes В 8.1 уже новая фукнция релевантности для OR запросов, которая сильно лучше учитывает то, что ты хочешь. Но для 8.2 мы пишем сильно улучшенную функцию релевантности, так что наберитесь терпения или реально помогите. > > Будет ли сделана > 1) выборка всех сколько-нибудь релевантных документов (например 1000000), > затем сортировка их всех (плохой вариант) > 2) выборка наиболее релевантных документов (100) сразу, согласно индексу, > без сортировки. Посмотри план запроса :) Чудес не бывает, текущая реализация LIMIT в постгресе так написана, что все равно сортируются все результаты, а потом просто выдается необходимый кусок. > > Насколько, вообще, используемые tsearch2 алгоритмы близки современным > поисковым движкам: yandex/google... ? Кто их точно знает, что у них работает :) В статьях можно много чего написать. Уточни, какие алгоритмы ты имеешь ввиду ? Алгоритмы индексирования - точно разные из-за разного хранилища и разных целей. Лингвистика ? У нас есть поддержка морфологии,стеминга и стоп-слов. Язык запросов ? У нас весьма богатый ? Алгоритмы поиска ? У нас прямой индекс и реляционное хранилище, поэтому сравнивать нечего. Алгоритмы релевации ? У нас нет заточенного парсера для html документов, но есть поддержка классов лексем, есть нормировка на длину документа, есть координатная информация (proximity). Вы можете все это прочитать в документации и в Wiki http://www.sai.msu.su/~megera/oddmuse/index.cgi/Tsearch2 Хочу напомнить наш TODO http://www.sai.msu.su/~megera/oddmuse/index.cgi/todo Все остальное будет иметь низкуй приоритет, если только оно не будет подкреплено весомыми аргументами :) Мы сейчас работает над UTF-8 поддержкой, что есть само по себе серьезная задача. Ищем спонсора для "improving scalability". Если есть желание помочь, то в добрый путь - исходники перед вами. PS. В следущий раз постарайся быть поконкретнее. На просто ля-ля нет времени. Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83