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

было бы интересно увидеть сравнение возможностей полнотекстового поиска в mysql и postgresql.

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

> Да, интересно Wikipedia на PostgreSQL не думает переходить?

Не планирует.

MySQL (кластер серверов) для быстрого чтения и быстрой записи куска текста в БД подходит замечательно. Сложной логики в БД там нет. (См. http://www.mediawiki.org/wiki/Image:Mediawiki-database-schema.png ) Полнотекстовый поиск всё равно работает с помощью внешних средств (которые можно заточить под свои задачи и которые поддерживают множественную интернационализацию, т. е. Apache Lucene).

Ну а самое главное - уже очень много сделано оптимизаций в движке под MySQL.

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

> Да, интересно Wikipedia на PostgreSQL не думает переходить?

Да, интересно, а зачем это википедии?

AndreyKl ★★★★★
()

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

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

> MySQL (кластер серверов) для быстрого чтения и быстрой записи куска текста в БД подходит замечательно. Сложной логики в БД там нет. (См. http://www.mediawiki.org/wiki/Image:Mediawiki-database-schema.png ) Полнотекстовый поиск всё равно работает с помощью внешних средств (которые можно заточить под свои задачи и которые поддерживают множественную интернационализацию, т. е. Apache Lucene).

Я с пол года назад разбирался с mediawiki - там прежде чем начать поиск в MySQL юникодный текст кодировался в восьмибитную строку, а PostgreSQL поиск сразу шёл через Unicode + всякие словари я думаю помогли бы быстрому поиску.

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

>Всё, мускуль с его закрыто-открытыми сорцами можно закапывать.

Такие как ты ничего не решают, посему сиди и бзди себе в лужи. MySQL наше фсе!

anonymous
()

Русскую морфологию оно поддерживает? И сколько времени займёт, скажем, поиск по двум миллионам записей по килобайту каждая?

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

> Я так понимаю этот поиск по природе а) неиндексный б) не поддерживающий морфологию?

А слабо сходить по первой ссылке и посмотреть главы про GIST и словари?

Evgueni ★★★★★
()

PostgreSQL рулёд! Уже давно на него перешел и не жалею..

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

Жжоте, да? Все жжоте и жжоте, и жжоте.. )

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

> Э... А что, ispell морфологию обеспечивает?

На сколько я понимаю да (искать russian.aff - дополнение к russian.hash). Есть (точнее был) словарь Книжника, а есть словарь Лебедева примерно одинаковые по качеству проверки, но первый был в десять раз объёмнее второго, так как набирался просто сканирование большого объёма текстов без всяких affixов, поэтому со временем умер.

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

Полнотекстовый поиск включённый в ядро PostgreSQL все поддерживает и морфологию тоже,и все что вы можете себе придумать в отличие от MySQL который не поддерживает морфологию вообще.

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

ЛОР на нем работает.

вроде неплохо ищет. сильно лучше mnogosearch

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

>>Всё, мускуль с его закрыто-открытыми сорцами можно закапывать.

>Такие как ты ничего не решают, посему сиди и бзди себе в лужи. MySQL наше фсе!

Сам себя пытаешься переубедить или просто обмануть?

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

> Я так понимаю этот поиск по природе а) неиндексный б) не поддерживающий морфологию? Если да, то хочется спросить - а нафиг оно вообще надо? ИМХО ничего полезного, кроме дополнительных тормозов, оно пользователю дать не может, а стало быть - и не нужно.

как всегда анонимус отжег, спросил, потом озадачи, а потом сделал вывод на основании своей же информации что все остой.

не позорь анонимусов, зарегистрируйся.

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

>Так и хочется сказать: респект и уважуха Олегу и Фёдору :)

Присоединяюсь. И не только им, но и всем авторам Постгреса.

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

>Сам себя пытаешься переубедить или просто обмануть?

Посмотри что хостеры в массе своей юзают, а потом говори. Web не хуй собачий однако.

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

> Посмотри что хостеры в массе своей юзают, а потом говори.
Ага. Хостеры для самых бедных теперь показатель крутости БД. Уморил.


> Web не хуй собачий однако.
Львиная доля WEB'a и этого не стоит, однако.

Korwin ★★★
()

по традиции ЛОРа по сцылке не ходил (да и спатки охота, утром поразбираюсь ;) ), потому возник вопрос (а вдруг кто уже разобрался): повлияет ли сабж на функциональность текущей версии медиавики, или придется ждать необходимых изменений и обновляться с репозитория? заранее спасибо ;)

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

> Так и хочется сказать: респект и уважуха Олегу и Фёдору :)

Да, уж. :)

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

> повлияет ли сабж на функциональность текущей версии медиавики, или придется ждать необходимых изменений и обновляться с репозитория? заранее спасибо ;)

На функциональность как мне кажется пока вряд-ли - там IMHO всё довольно тупо сделано, то есть куда дотачивать: но я думаю, что морфология это уже само по себе сразу даст преимущество в поиске.

А так mediawiki и рньше поддерживала PostgreSQL, но достаточно криво (p://www.inp.nsk.su/~baldin/Wiki/index.html). Может быть сейчас что-то поменяется.

Evgueni ★★★★★
()

Олегу и Теодору респект и уважуха !

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

>Ага. Хостеры для самых бедных теперь показатель крутости БД. Уморил.

Однако, Postgre даже "бесплатнее", чем MySQL. Что ж на него нет массового перехода? :)

KRoN73 ★★★★★
()

это однозначно позитивно. postgresql плюсик. надеюсь что tsearch2 так же функционален как sphinx sql

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

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

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

> А так mediawiki и рньше поддерживала PostgreSQL, но достаточно криво (p://www.inp.nsk.su/~baldin/Wiki/index.html). Может быть сейчас что-то поменяется.

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

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

А в чём разница? Просто руками теперь добавлять tsearch2 не надо. Но это естественно, просто мысли - не проверял.

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

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

> мускулу скора канец придет )

не дождетесь
конкуренция , панимаиш

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

> Про корявость - когда я в январе с этим разбирался, то поиск в PostgreSQL просто не работал из-за глупейшей баги - пришлось запостить баг репорт. Надо сказать отреагировали разработчики мгновенно.

Бага была в mediawiki, естественно.

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

> Алексея, однако.

Прошу прощения - оговорился :(

Evgueni ★★★★★
()

респект!

> Как утверждает Том, это самый большой патч за всю историю PostgreSQL

..и один из самых полезных

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

>>Всё, мускуль с его закрыто-открытыми сорцами можно закапывать.

>Такие как ты ничего не решают, посему сиди и бзди себе в лужи. MySQL наше фсе!

Так и хочется сказать SQLite наше фсе. Но не буду. Рад за PostgreSQL, чем в скором времени и воспользуюсь

anonymous
()

Из ветки обсуждения мы узнаем также, что Олег и Брюс совсем не пьют, а Том похоже может пить водку и комитить патчи в репозиторий одновременно, впрочем в том, что он супермен, сомнений не было. :-)

По сути - думаю что tsearch2 наряду с HOT и изменениями в работе autovacuum будут среди наиболее значительных усовершенствований 8.3

alexk_CMD
()

молодца постгрес. в етом поиске в отличии от мускуля морфологический анализ корней и простых форм автоматом идет. а с мускулем надо еще функций дописывать со словарями

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

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

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

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

>В каком виде? Перебор приставок и окончаний у заданного корня? Это в принципе несовместимо с индексным поиском, а следовательно медленно.

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

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

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

> В каком виде? Перебор приставок и окончаний у заданного корня? Это в принципе несовместимо с индексным поиском, а следовательно медленно.

А слабо сходить по первой ссылке и почитать?

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

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

Evgueni ★★★★★
()

Кто-нибудь замерял скорость работы этого поиска по сравнению со Sphinx ? Может где-то есть тесты? Что-то с лету не нагуглил.

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

Это не есть задача нашего движка ! Мы предоставляем возможность подключения любых словарей, а словарь - это просто программа. По умолчанию есть поддержка нескольких словарей-шаблонов, которых вполне достаточно для большого кол-ва задач. В частности, мы поддерживаем все словари ispell, myspell, hunspell, которые пользуются в openoffice. Если этого не хватает, то пишите свой словарь.

Олег

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