Полнотекстовый поиск в PostgreSQL

>PostgreSQL (произносится <<Пост-Грес-Кью-Эл>> или просто <<постгрес>>) - свободная объектно-реляционная система управления базами данных (СУБД).

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

Угу.. Спасибо..

Вот интересно, на какой таблице-миллионнике оно встанет раком?

> PostgreSQL - свободная **объектно-реляционная** система управления базами данных (СУБД)

какая-какая?

>> PostgreSQL - свободная **объектно-реляционная** система управления базами данных (СУБД) > какая-какая?

Объектно-реляционная!

> Вот интересно, на какой таблице-миллионнике оно встанет раком?

Мне тоже интересно. У нас несколько таблиц по 5 - 20 миллионов записей табличных данных. Таблицы связаны. Крутится всё без проблем на 2xXEON 3 ГГц, 4 ГБ ОЗУ, SCSI RAID 5, PostgreSQL 8.2, Ubuntu 6.06 Server. Нагрузка в среднем 1000 обращений на чтение-запись в минуту на таблицу.

При таких же параметрах MS SQL находится в постоянном режиме кашля.

даже миллионника не нужно :(
~50 тыщ записей, ~ 200мб индексируемых данных
3-4 одновременных запроса на поиск - и привет ромашки
искать по таблице комментариев (~5M записей) не указывая "глубину поиска" - лучше даже и не пытаться
впрочем, mysql у меня вообще просто тупо падал в кору без всякого поиска, не говоря уже о том что его полнотекстовый поиск не умеет морфологию :)

>При таких же параметрах MS SQL находится в постоянном режиме кашля.

MS SQL??? Вы его просто готовить не умеете, наверное.

> MS SQL??? Вы его просто готовить не умеете, наверное.

Да на Ubunty её даже установить не получится :) - то есть даже пищать не сможет.

> Мне тоже интересно. У нас несколько таблиц по 5 - 20 миллионов записей

> табличных данных.

MySQL 4.1.20:

mysql> select count(*) from traffic;

+----------+

| count(*) |

+----------+

| 62582568 |

+----------+

1 row in set (0.00 sec)

[root@XXXX ~]# du -hs /var/lib/mysql/UTM/

84.5G /var/lib/mysql/UTM/

Никаких проблем с MySQL. Вот уже 3 года как с такими нагрузочками :). А как дела у Postgre? :-)

>А как дела у Postgre? :-)

Смотрим сюда: http://www.linux.org.ru/profile/Evgueni/view-message.jsp?msgid=1919300#1920548

Любой сервер БД можно поставить раком. ЛЮБОЙ.

> Любой сервер БД можно поставить раком. ЛЮБОЙ.

вмурованный в стену сервер раком не поставишь !

Вот это уже замечательная статья!
Спасибо!

>Нагрузка в среднем 1000 обращений на чтение-запись в минуту на таблицу.

>При таких же параметрах MS SQL находится в постоянном режиме кашля.

Не скажу про MS SQL, и не скажу про связанные таблицы, но на простых таблицах в полтора миллиона записей у меня MySQL выдаёт по 1000 запросов в _секунду_ в _среднем за сутки_ (т.е. пиковую нагрузку можно только прикинуть). 60% чтение, 40% update. 2xXeon-1800 + MMORPG сервер на той же железке ;)

Не уверен, что Постгре в этих условиях не начнёт жрать 100% ресурсов системы :)

Очевидно, что всё зависит от задачи/запросов/структуры данных.

Индекс GiST? Если да - попробуй GIN. + По опыту знаю, очень часто люди забывают выставить правильно shared_buffers, еще чаще - work_mem, и почти никогда не ставят effective_cache_size - а оптимайзер из 8.2 очень чувствителен к этому параметру.

PostgreSQL - лучшая СУБД!

MySQL - фтопку!

>MS SQL??? Вы его просто готовить не умеете, наверное.

Да, чтобы научиться его готовить нужно не слабо побегать по форумам, поспрашивать, по документации, огромной помойке MSDN, тогда начнёт работать... гораздо быстрее, но при большой нагрузке... :-\ PostgreSQL по сравнению с ним просто реактивный.

А есть ли сравнение этого движка со Sphinx Search?
http://www.sphinxsearch.com

До тех пор, пока в PostgreSQL не будет нормальной репликации, его можно смело отправлять фтопку.

Нормальная репликация, это что?

Хотя бы аналог master-slave репликации в MySQL.

Изучаем Slony I до полного просветления http://slony.info/ и больше не говорим, что не знаем что это такое.

Что скажите насчет такой мысли: В силу развития ORM и иже с ними (Hibernate, SQLAlchemy) надобность в "умных" и фичастых БД отпадает? На передний план выходит скорость простейших операций чтений/вставки, а вся более-менее сложная логика пишется в прикладе через эти сымые Hibernate? Из плюсов - гораздо более простая отладка логики в нормальном ЯП, чем внутри SQL базы. Ну а также гибкость - SQL язык никогда не дотянет по возможностям описания логики до нормальных ЯП.

> Что скажите насчет такой мысли:

Для хранения данных ничего лучше и естественней таблиц пока не придумали.

Слоны: 1) Костыль 2) Не реплицируют изменения в схеме 3) Заметно влияют на быстродействие

Потому - фтопку. Поделия типа pgcluster так же не предлагать - это вообще тихий ужос, замедление в 40 раз на INSERT/UPDATE.

> надобность в "умных" и фичастых БД отпадает?

Hibernate и иже с ними - текущая и проходящая мода. Уже сейчас становится ясно, что постоянная конвертация "плоских" данных в объекты
чтобы они тут же стали "плоскими" в WEB-браузере, потом опять в объекты чтобы тут же стали "плоскими" в БД - избыточно и приводит к лишним
тратам процессорных и Memory ресурсов.

Кроме того, существуют сферы где логику из БД не перенести в Application-server - себе дороже и медленней выйдет.
Например:
1. Обработать большой массив данных по n различным формулам и сохранить в БД. Смысла гонять их в app, а потом обратно никакой.
2. БД с гетерогенным доступом.

1) - не понятно

2) автоматически не реплицируют. Любое изменение в схеме в любом случае делается человеком со всеми вытекающими.

3) естественно, так как любая система репликации влияет на быстродействие.

Кстати, если не секрет, а зачем Вам нужна репликация?

Это разные вещи. Сфинкс сосет из БД, т.е., является внешним поисковым движком. Таких много. Для многих задач этого почти хватает. Но есть задачи, где требуется интегрированный с ядром БД поиск, там сфинкс не поможет. Конечно, полная интеграция с БД накладывает свои ограничения на движок и приходится следовать внутреннему API и, как говорится, выше головы не прыгнешь, но это компенсируется такими фичами, как поддержка транзакционности, восстановление после сбоев, конкурентный доступ и многое другое.

Кроме того, наш поиск позволяет настраивать поиск под специализированные задачи - можно настраивать как нарезать документ на лексемы (парсер) и что с этими лексемами делать (словари).

Специально для тех, кто недоволен производительностью мы в статье предложили несколько советов ( помимо настройки постгреса ) - это сегментирование данных с помощью наследования таблиц+CE (constraint exclusion) и распределение данных по серверам с помощью contrib/dblink. Вообще, бесплатного сыра не бывает ! Если вы работаете над серъезным проектом придется вкладываться мозгами и железом. Никакой софт вот так сразу вам не поможет. А если у вас конкурентный доступ и вы хотите транзакционности, то PostgreSQL рулит и всем это известно. Недавно пробегало в архивах сообщение про юзера который нашим поиском индексировал почти террабайтную базу газет.

Вот недавнее сравнение производительности поиска MySQL и PostgreSQL http://peufeu.free.fr/ftsbench/bench1a.pdf Парень делал абсолютно независимо, с нами никак не связан.

Олег

Олег

круто ...

>Для хранения данных ничего лучше и естественней таблиц пока не придумали.

Я не про отмену таблиц, а про применение простых и быстрых баз навроде MySQL с MyISAM хранилищем.

Логику внутри базы же действительно сильно сложнее отлаживать/разрабатывать чем на нормальном языке.

SQL нормальный язык имеющий эквивалентные объекты в математике. Этим и силён.

ага, добавьте на myisam транзакции длинной в полчаса-час и сотню юзеров...

>Hibernate и иже с ними - текущая и проходящая мода.
+1
materialized view, Index organized tables, partitioning и прочая никак не запихнуть в хибер

>Логику внутри базы же действительно сильно сложнее отлаживать/разрабатывать чем на нормальном языке.

смотря что за язык, pl/sql пока покруче будет - где еще язык самостоятельно может помечать инвалидные объекты, а не натыкатся в процессе выполнения ? тут скорее ООП vs процедурный ...

Triffids.

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

>Не уверен, что Постгре в этих условиях не начнёт жрать 100% ресурсов системы :)

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

знаешь сколько "ест" cpu постгри при дефолтном конфиге? поставь и удивись

ЗЫ: только что вспомнил, это ж мы тебя "лечили" в теме когда ты опростоволосился на весь лор заявив что постгри "тормозииит". оказалось у тебя конфиг дефолтный был. лечение необходимо повторить похоже

> Что скажите насчет такой мысли: В силу развития ORM и иже с ними (Hibernate, SQLAlchemy) надобность в "умных" и фичастых БД отпадает?

Мысль очень правильная. Жаль, что понимают её 0.1% разработчиков. Ибо сильно оболванены рекламой той или иной "крутой" СУБД.

Да - да дад .... а эти 0.1% оболванены рекламой того или иного ORM'а :)

Просто мыслят нешаблонно. Что делать с тем же полнотекстовым поиском для Postgresql, если завтра понадобится перенести приложение на другую СУБД? В какое место его засунуть?

А его никуда сувать не надо. Надо просто его с собой перетащить, а не заниматься переносом песка из одной песочницы в другую.

>Надо просто его с собой перетащить

имелся ввиду Потсги???

>>Просто мыслят нешаблонно. Что делать с тем же полнотекстовым поиском для Postgresql, если завтра понадобится перенести приложение на другую СУБД? В какое место его засунуть?

Это просто песня :) А что делать если нужно добраться до информации из базы из _другого_ приложения? Скажем залабал ты Java/Hibernate а вот бизнес потребовал прилепить нечто на Django/Python/Cherrypy на те же данные ... __И__?!

Ф пелотку таких нешаблонно-мысляших! :)

Имея бизнес логику в базе ты хоть из жабы хоть их баша хоть из лиспа будешь работать с правильным черным ящиком. И данные будут белые и пушистые :)

> Просто мыслят нешаблонно. Что делать с тем же полнотекстовым поиском
> для Postgresql, если завтра понадобится перенести приложение на другую
> СУБД?

Участвовал во многих проектах в которых закладывалась возможность быстрого переползания на другую СУБД.
Итог: во всех них с развитием добавлялись ДБ зависимости препятствующие
переносу. Почему? Просто! Необходимо повышать быстродействие, а на
универсальном методе доступа, без тюнинга под конкретную БД достить
максимума производительности не возможно.

И только в одном проекте переползли с Oracle на PostgreSQL достаточно гладно и то, только по причине схожести pl/pgsql и pl/sql.