LINUX.ORG.RU

Полнотекстовый поиск включён в ядро PostgreSQL


0

0

Том Лейн (Tom Lane) сообщил, что патч, интегрирующий полнотекстовый поиск (ранее выполненный в виде отдельного модуля, contrib/tsearch2) в ядро PostgreSQL, успешно внесён в CVS. Безусловно, это ключевой момент в сложнейшем процессе принятия патчей для версии 8.3 (напомним, feature freeze был объявлен ещё 1-го апреля, т.е. с тех пор идеи по развитию функционала Постгреса не принимались и всё внимание разработчиков было поглощено процессом обработки уже предложенных патчей).

Ещё неделю назад принятие патча полнотекстового поиска в ветку 8.3 ставилось под сомнение. Теперь же можно уверенно заявить, что PostgreSQL 8.3 будет содержать одно из самых ожидаемых изменений: полнотекстовый поиск (поддержку и развитие которого осуществляют наши разработчики, Олег Бартунов и Фёдор Сигаев) будет теперь доступен в PostgreSQL по умолчанию. Кроме того, SQL-подобный синтаксис упростит работу пользователей (черновик документации находится тут: http://www.sai.msu.su/~megera/postgre...).

В CVS HEAD была принята 58-я (!) версия патча. Как утверждает Том, это самый большой патч за всю историю PostgreSQL:

This is, by a wide margin, the largest single patch ever to hit the Postgres CVS tree. Congratulations to Oleg and Teodor on seeing it through!

regards, tom lane

Присоединяемся к поздравлениям!

>>> Полнотекстовый поиск включён в ядро PostgreSQL

Ответ на: комментарий от Evgueni

>дублировать надоело

Какое нафиг "дублировать", если ты пока кроме цитаты про ispell ничего дельного не ответил? Или ты хочешь сказать, что будучи привешенным к СУБД сбоку на веревочке он даст индескные чтения при поиске? Интересно как ты это себе представляешь? Для каждого содержащегося в поле слова запихнутся в индекс ссылки на все его возможные словоформы? Боюсь тогда индекс будет весить раз этак в несколько побольше самой таблицы, со всем вытекающими для скорости работы последствиями.

anonymous
()
Ответ на: комментарий от anonymous

> Для каждого содержащегося в поле слова запихнутся в индекс ссылки на все его возможные словоформы?

Почитай ман на ispell, aspell

Korwin ★★★
()

УРА!!! PostgreSQL руит!!! Самамя лучшая опен сорс СУБД!!!

sdbrother
()
Ответ на: комментарий от anonymous

> Какое нафиг "дублировать", если ты пока кроме цитаты про ispell ничего дельного не ответил? Или ты хочешь сказать, что будучи привешенным к СУБД сбоку на веревочке он даст индескные чтения при поиске? Интересно как ты это себе представляешь? Для каждого содержащегося в поле слова запихнутся в индекс ссылки на все его возможные словоформы? Боюсь тогда индекс будет весить раз этак в несколько побольше самой таблицы, со всем вытекающими для скорости работы последствиями.

Кури документацию, а не выдумывай.

teodor
()
Ответ на: комментарий от teodor

>Кури документацию, а не выдумывай.

Ты сам-то ее курил, умник? Там именно словарный поиск и отображение найденных слов на биты индекса.

anonymous
()
Ответ на: комментарий от anonymous

> Ты сам-то ее курил, умник? Там именно словарный поиск и отображение найденных слов на биты индекса.

Я его разрабатывал :)))). Ты ошибаешься в определении места, где работают словари.

teodor
()
Ответ на: комментарий от teodor

>Я его разрабатывал

Ну и слава богу - по крайней мере появляется надежда на компетентное мнение

>Ты ошибаешься в определении места, где работают словари.

Возможно, не настаиваю - не суть важно сбоку оно болтается, подключается как модуль или намертво вкомпилено в ядро. Вопрос не в этом - в остальном я прав или нет? Индекс строится по известным словарю корням слов, содержащихся в поле, а при поиске проверяется его схожесть с тем, что построено по искомой фразе? Если да, то при чем тут морфология? Как, например, с помощью такого индекса будет различаться поиск по словам "образный" и "безобразный", если в словаре будет только корень "образ"?

anonymous
()
Ответ на: комментарий от teodor

А вот скажи, насколько абстрактен тамошний механизм подключения морфологии? Если я вместо (убогого крайне для русского языка) ispell-а решу подключить AOT или яндексный mystem - придется все переписывать, или можно модуль собрать рядом?

anonymous
()

FullText в базе данных не нужен.
Для этого есть sphinxsearch.com
и морфология и сложный язык запросов и параллельная обработка

anonymous
()
Ответ на: комментарий от anonymous

А есть ли возможность поискового запроса на наличие 2 слов с условием что между ними не более N слов ?

szh ★★★★
()
Ответ на: комментарий от anonymous

Индекс строится по номализованным словам - смысл слова "нормализуется" целиком и полностью определяется используемыми словарями и конфигурацией полнотекста.

Слово перед индексированием нормализуется словарем. Как словарь нормализует - это его дело. Стеммер вернет в твоем примере образ и безобраз, ispell - "образный" и "безобразный", но для слова "образного" вернет "образный", т.е. инфинитив.

Можно написать словарь возвращающий корень слова - но мы таких не разрабатывали.

teodor
()
Ответ на: комментарий от anonymous

Абсолютно абстрактен - парсер веделяет лексемы, лексемы классифицируются по типу (целое число, число, слово, URL и т.д.), далее лексемы передаются словарям (список словарей индивидуален для каждого типа лексем). Типовой словарь получает слово и волен принять одно из трех решений: 1) вернуть нормальную форму лексемы (это его и только его мнение о нормальности) 2) сказать, что ему это лексема известно, но индексировать его не надо (стоп-слово) 3) растеряться. В этом случае будет вызван следующий словарь из списка

Есть более сложные словари - они могут попросить следующую лексему. Таков, например, тезаурус.

Есть API к парсерам и словарям.

teodor
()
Ответ на: комментарий от teodor

> Индекс строится по номализованным словам - смысл слова "нормализуется" целиком и полностью определяется используемыми словарями и конфигурацией полнотекста.

Понял, спасибо

anonymous
()
Ответ на: комментарий от szh

Это в планах - когда найден спонсора или финансирование

teodor
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.