PostgreSQL *

Задача

Как удобно делать выборки из деревьев типа Nested Sets, и как не удобно им управлять. Как удобноуправлять деревьями типа id->parent_id, но как не удобно и накладно использовать рекурсии при выборках. Понятно, что прииспользовании модулей для управления деревьями часть проблемы снимается, но при этом процесс работы с базой данных несовсем прозрачен т.е. для изменения данных мы используем одни методы, для изменения расположения узла в дереве — другие,плюс еще транзакции не помешали бы. Эту нестыковку можно решить двумя способами:

• Использовать для работы с таблицей хранимые процедуры, в которой объединить оба метода обновления (вставки, удаления);
• Использовать триггеры, для исключения вообще каких-либо нестандартных методов работы;

Первый способ неудобен тем, что при изменении структуры таблицы, нам потребуется еще изменять процедуру, а так же бытьмаксимально внимательным, при работе с таблицей, что бы все изменения данных проходили через наши процедуры, а не прямымизапросами. Второй способ несколько утяжеляет тяблицу введением дополнительных булевых полей, а так же приходится делатьнекоторые «финты ушами», хотя позволяет добиться максимальной прозрачности работы.Первый способ — в топку, тем более где-то интернетах уже есть подобное решение.База данных — PostgreSQL, как актуальная мне на данный момент, дополнения для MySQL напишу позже.

Сегодня вышел PostgreSQL 8.4

Основные изменения:
* Windowing Functions
* Common Table Expressions and Recursive Queries
* Default and variadic parameters for functions
* Parallel Restore
* Column Permissions
* Per-database locale settings
* Improved hash indexes
* Improved join performance for EXISTS and NOT EXISTS queries
* Easier-to-use Warm Standby
* Automatic sizing of the Free Space Map
* Visibility Map (greatly reduces vacuum overhead for slowly-changing tables)
* Version-aware psql (backslash commands work against older servers)
* Support SSL certificates for user authentication
* Per-function runtime statistics
* Easy editing of functions in psql
* New contrib modules: pg_stat_statements, auto_explain, citext, btree_gin

8.4 Release Notes, PostgreSQL 8.4 Feature List

UPD: русскоязычный обзор на opennet.ru

DB_Pgsql_Type — это фреймворк для преобразования сложных типов PostgreSQL 8.3+ в их аналоги на PHP и обратно. С ее помощью вы можете работать с полями сложного типа (к примеру, двумерным массивом композитных типов) так же просто, как с привычными массивами PHP.

Поддерживаются следующие типы данных и любые их вложенные комбинации:

• Массивы элементов произвольного типа (в том числе многомерные).
• Композитные типы и ROWTYPE (в частности, сами содержащие композитные поля или поля-массивы).
• Hstore (в том числе содержащие сложные элементы).
• Прочие типы: TIMESTAMP (преобразуется в Unix time), DATE, TIME, BOOLEAN и т. д.

Предмет описываемой проблемы

При работе с базой данных в PostgreSQL необходимо не забывать, в какой локали (locale) был инициализирован кластер БД — так в постгре называется директория (обычно /var/lib/pgsql/data), в которой хранятся данные всех баз этой установки PostgreSQL.

Очень тяжело начать писать статью. Т.е очень тяжело придумать вступительное слово. Хочется рассказать обо всём и сразу :) Но нет. Будем последовательны.
Начну с того что совсем недавно проходил Highload++ 2008 на котором мне удалось побывать.
Скажу сразу — мероприятие было проведено по высшему клаcсу, докладов было много и все были очень интересными.
Одной из самых запомнившихся презентаций была лекция Аско Ойя об инфраструктуре серверов баз данных в Skype. Лекция в большей степени касалась различных средств с помощью которых достигается такая производительность серверов.
По словам Аско, база данных Skype выдержит даже если все жители Земли захотят подключится к скайп в один момент.

Приехав домой очень захотелось это всё попробовать в живую. О чём я сейчас и расскажу. Сразу оговорюсь — структура базы данных для теста, взята из примера на сайте самих разработчиков и естественно не имеет ничего общего с реальной загрузкой.
В статье будет описано что распределением нагрузки надо заниматься после того как уже припекло и база падает, но это не совсем так. С помощью данной статьи я как раз хочу подготовить начинающих и не опытных разработчиков и заодно заставить их задуматься о том, что предусматривать возможность распределения нагрузки между серверами надо ещё при проектировании системы. И это не будет считаться той самой «преждевременной оптимизацией» о которой так много пишут и которой так боятся.

UPD: Как правильно заметил хабраюзер descentspb в статье присутствует досаднейшая ошибка. В следствие своей невнимательности я подумал что PgBouncer надо устанавливать между прокси и клиентом. Но, как оказалось, та проблема которую я решал с помощью PgBouncer не решится если установить его именно так. Правильнее надо устанавливать боунсер между нодами и прокси. Мало того, именно так и рекомендуется делать в оффициальном мануале на сайте PL/Proxy.
В любом случае использование PgBouncer так как указано на моей схеме также даст прирост производительности. (Разгрузит Proxy).

Возникла задача построения полнотекстового индекса. В индексируемой таблице было создано поле fts типа ts_vector. При вставке и обновлении триггер, при необходимости, должен обновлять поле fts. Чтобы полнотекстовый индекс не обновлялся при обновлении полей не связанных с ним было установлено условие:

IF (TG_OP = 'UPDATE') AND (NEW."name" = OLD."name")
    THEN RETURN NEW;
END IF;

Т.е. если имя не обновилось мы ничего не трогаем и просто завершаем выполнение триггера. Но при обновлении данный триггер сваливался с ошибкой «record „old“ is not assigned yet». Однако ошибки не возникает при такой конструкции:

IF (TG_OP = 'UPDATE') THEN 
    	IF (NEW."name" = OLD."name") THEN
	       	RETURN NEW;
        END IF;
END IF;

Следовательно, при вычисленнии логического выражения, вычисляется каждая его составляющая. И даже если TG_OP != 'UPDATE' (а это значит выполняется INSERT ) проверяется второе условие где OLD не определён. Отсюда и возникает ошибка.

Недавно у меня возникла интересная задача по хранению некоторых данных в рамках сессии работы с БД PostgreSQL (TTL = время жизни единичного коннекта к базе). Изначальный вопрос был таков…
А можно ли вместо вот такой конструкции:

some_procedure1(user_id, param1, ... , paramN);
...
some_procedureX(user_id, param1, ... , paramN);

использовать такую:

set_user(id);
some_procedure1(param1, ... , paramN);
....
some_procedureX(param1, ... , paramN);

т.е. использовать некую глобальную переменную в рамках сессии для хранения значение идентификатора пользователя, которое будет доступно всем процедурам внутри базы.
Порывшись в гугле, поспрашивав на форуме, я нашел даже не одно решение, а целых 3! Чем с вами и делюсь…

Компания «Постгресмен» и организационный комитет конференции Highload++ рады представить вашему вниманию мастер-класс «Как спроектировать масштабируемую архитектуру PostgreSQL», который проведут эксперты компании Skype Аско Оя (Asko Oja) и Марко Креэн (Marko Kreen). Мероприятие пройдёт 8 октября 2008 года в Москве в конференц-центре «Инфопространство».

После летнего перерыва рады объявить о том, что 16-го сентября (вторник) в Москве планируется очередная, сентябрьская встреча всех тех, кто использует, начинает использовать или просто интересуется PostgreSQL. На этот раз мы поговорим о полнотекстовом поиске PostgreSQL, о том, как правильно его настраивать (прежде всего, при работе с русским и английским языками), о всех многочисленных возможностях FTS в PostgreSQL версии 8.3. С докладом-демонстрацией «Возможности полнотекстового поиска PostgreSQL» выступят Фёдор Сигаев (разработчик FTS в PostgreSQL) и Иван Золотухин. А об интересных новых разработках движка полнотекстового поиска и о планах расскажет Олег Бартунов (также разработчик FTS).

Как всегда, вход свободный, но из-за пропускного режима и ограниченного количества мест требуется предварительная регистрация: http://blog.styleru.net/register/.

Чуть больше подробностей доступно на странице http://postgresmen.ru/news/view/113.

Приглашаем всех желающих!

Многим при реализации поиска по сайту приходится делать запрос к базе данных, использующий оператор LIKE или регулярные выражения.
С выходом PostgreSQL 8.3 модуль полнотекстового поиска tsearch2 был встроен в ядро системы (об этом ранее уже писалось на Хабре), и с его помощью можно реализовать поиск по базе данных, который будет более функционален. В принципе, в статье, указанной выше, приведен пример использования этого модуля, но хотелось бы поделиться опытом реализации полнотекстового поиска в реальном проекте.

30 июня мы провели онлайн-сессию «Вопросы к ведущим мировым экспертам PostgreSQL». В течение трёх часов любой желающий мог задать вопрос одному из приглашённых гостей и получить исчерпывающий ответ. В результате было получено более 40 вопросов, ни один из которых не остался без внимания.

Участники: Брюс Момджан (Bruce Momjian) (PGDG, EnterpriseDB), Максим Богук (Rambler, Мастерхост), Фёдор Сигаев (PGDG), Марко Креэн (Marko Kreen) (Skype).

Вот избранные вопросы и ответы:

Вопрос №3

kaikai:
Одна из досадных штук в работе — это отсутствие конструкции «INSERT OR UPDATE». В MySQL можно сделать так: «INSERT INTO users (username, email) VALUES ('Jo', 'jo@email.com') ON DUPLICATE KEY UPDATE email = 'jo@email.com'». Появится ли что-нибудь похожее в PostgreSQL?

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Стандартный (ANSI) способ для таких вещей — это MERGE или UPSERT. Оба способа находятся у нас в TODO-листе и, насколько я знаю, кто-то работает над этой функциональностью для PostgreSQL 8.4, хотя лично я ещё не видел этого патча. Мы, вне всяких сомнений, нуждаемся в таком синтаксисе.

Начался предварительный приём вопросов для Q&A-сессии с ведущими
экспертами PostgreSQL. Начало основного времени: 15:00.

Участники:

* Брюс Момджан (Bruce Momjian), координатор разработки PostgreSQL,
лидер сообщества PostgreSQL, эксперт компании EnterpriseDB.
* Максим Богук, ведущий администратор баз данных компаний Rambler и
Мастерхост, известный специалист по PostgreSQL.
* Фёдор Сигаев, разработчик подсистемы полнотекстового поиска, систем
индексации GiST, GIN и множества дополнительных модулей, один из
основных членов PostgreSQL Global Development Group.
* Олег Бартунов, один из основных членов PostgreSQL Global Development
Group, разработчик подсистемы полнотекстового поиска, систем
индексации GiST, GIN, разработчик многотерабайтных научных баз данных.
* Марко Крин (Marko Kreen), один из основных архитекторов баз данных
компании Skype, разработчик и мантейнер таких проектов как PL/Proxy,
Skytools, PgBouncer и pgcrypto.

Вопросы принимаются в jabber-канале postgresmen@conference.jabber.org
(основной способ) и в skype:postgresmen.

Если вы по каким-либо причинам не можете воспользоваться jabber или
skype, оставляйте вопросы в виде комментариев к этой новости.

Как задавать вопросы:

30 июля компания «Постгресмен» организует онлайн-конференцию «Вопросы к ведущим экспертам PostgreSQL». Любой желающий сможет задать свой вопрос, связанный с внедрением, эксплуатацией, развитием PostgreSQL, всемирно известным экспертам PostgreSQL, ведущим разработчикам и лидерам сообщества PostgreSQL.

Участники конференции:

* Брюс Момджан (Bruce Momjian), координатор разработки PostgreSQL, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB.
* Максим Богук, ведущий администратор баз данных компаний Rambler и Мастерхост, известный специалист по PostgreSQL.
* Фёдор Сигаев, разработчик подсистемы полнотекстового поиска, систем индексации GiST, GIN и множества дополнительных модулей, один из основных членов PostgreSQL Global Development Group.
* Олег Бартунов, один из основных членов PostgreSQL Global Development Group, разработчик подсистемы полнотекстового поиска, систем индексации GiST, GIN, разработчик многотерабайтных научных баз данных.

Начало конференции:

На работе в новом проекте используется СУБД PostgreSQL. Так как до сих пор я работал с MySQL, сейчас приходится изучать и открывать для себя Постгри. Первая проблема, которая меня заинтересовала — замена мускулевского SQL_CALC_FOUND_ROWS. При использовании этой константы в MySQL можно получить количество всех найденных по запросу записей, даже если запрос с limit'ом — это незаменимо при постраничном выводе поисковых результатов, когда используются «тяжелые» запросы.
Сходу готового решения найти не удалось. На форумах просто констатировали, что SQL_CALC_FOUND_ROWS в Постгри нет. Некоторые писали, что надо юзать count(*). И больше никакой информации. Но еще из MySQL мне было известно, что поиск с count()-запросом работает почти в 2 раза медленнее, чем с SQL_CALC_FOUND_ROWS. Я консультировался у тех, кто пользуется PostgreSQL, день мучал google и в результате получил 4 варианта замены SQL_CALC_FOUND_ROWS в PostgreSQL, один из которых вполне приемлимый по скорости.

Компания Yahoo утверждает, что ей удалось побить мировой рекорд, создав самую большую и нагруженную базу данных в мире!

Объём запущенной год назад базы данных достиг 2 петабайт. Система создана для аналитических целей, в ней хранится история поведения веб-пользователей (утверждается, что в месяц сохраняются данные о полумиллиарде пользователей). Помимо прочего, интернет-гигант заявляет, что это не только самая большая БД в мире, но ещё и самая нагруженная — в сутки в ней регистрируются данные о 24 млрд событиях.

13-го мая в Москве состоится вторая встреча Российского PostgreSQL-сообщества!

Мы обсудим проблемы производительности PostgreSQL в web-приложениях (с докладом выступят Николай Самохвалов и Иван Золотухин), пообщаемся в свободной форме. Приглашаются все желающие, участие бесплатное. Количество мест ограничено, поэтому требуется предварительная регистрация: http://blog.styleru.net/register/.

Встреча состоится 13-го мая во вторник, в 19:00 в здании ГУ-ВШЭ на ул. Мясницкая, в клубе «Бизнес в стиле .RU», ауд. 125 (адрес и подробности доступны на сайте после регистрации). На встрече планируется участие ведущего администратора баз данных компании «Рамблер» Максима Богука.

Забавная ошибка обнаружилась в некоторых консольных утилитах постгреса, запрашивающих ввод с клавиатуры.

Так pg_dump, к примеру, вместо ожидаемого запроса пароля и последующего выполнения своих непосредственных обязанностей сразу обругал меня FATAL'ом и сказал, что password authentication failed. Даже не смотря на ключ --password, который в принудительном порядке производит запрос пароля. А т.к. эта же утилита используется pgAdmin'ом, похожее ругательство иногда возникает и там.

Ошибка возникает под виндой и только при наличии папки «dev», находящейся в корне текущего диска.
Это дают о себе знать юниксовые корни постгреса. Они (корни) пытаются работать с терминалом через /dev/tty, которого в винде разумеется нет. Но при наличии папки /dev, утилиты заботливо его создают после первого вызова.

Лечится просто — перед запуском утилиты сотрите файл /dev/tty
оригинал в жж

Встала задача переноса сайта на новый сервер. Из проблем ожидалась несовместимость с PHP5, которая в итоге очень быстро решилась, а сайт все равно не поднимался. Выяснилось, что не отрабатывают простейшие запросы к БД. При ближайшем рассмотрении оказалось, что не происходит автоматическое преобразование типов.

В четверг 14-го февраля вечером в Москве состоится первая долгожданная встреча российского PostgreSQL сообщества! Анонс об этом событии уже опубликован на сайте «Постгресмена», от себя могу добавить только то, что участие в мероприятии бесплатное, для участия требуется предварительная регистрация по адресу http://blog.styleru.net/register/.

Встреча пройдет в свободной форме, на повестке — обсуждение целей создания российского сообщества PostgreSQL и расписания дальнейших встреч, выступление Николая Самохвалова с обзором нашумевших новинок свежей версии 8.3, общение с Олегом Бартуновым, Федором Сигаевым (авторами полнотекстового поиска, ставшего недавно крупнейшим патчем за всю историю PostgreSQL) и другими PostgreSQL-экспертами.

Приходите, будет интересно!

Более 200 разработчиков, более 300 патчей, 15 месяцев напряжённой работы разработчиков и тестировщиков… И вот — новейшая версия лучшей СУБД в мире готова к использованию в промышленных условиях!

4 февраля 2008-го года Глобальная группа разработчиков PostgreSQL (PostgreSQL Global Development Group) анонсировала долгожданный релиз версии 8.3 самой развитой открытой СУБД, факт выхода которой ещё более укрепляет позиции PostgreSQL как и самой производительной СУБД из систем с открытым исходным кодом. Среди новшеств, касающихся производительности, стоит выделить: