PostgreSQL *

Postgresql, без сомнения, великолепная СУБД. Она обладает обширнейшими возможностями, отличной документации, и при всем при этом является бесплатной. Однако, всегда найдется что-то, чего пользователю не будет хватать. И в postgresql это легко исправляется, ведь он позволяет создавать функции на языках на любой вкус, будь то Plpgsql, Perl или даже Java.

Приведу пример. Мне всегда не хватало функции, получающей DDL выбранной таблицы. В oracle, например, вы можете воспользоваться для этого средствами пакета dbms_metadata. А вот в postgresql аналога почему-то нет. То есть можно конечно использовать pgdump, но это уже немного не то, мне хотелось бы иметь функцию бд. И так далее, думаю у каждого найдется несколько таких небольших «хотелок».

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

В этом топике я хочу рассказать о задаче, очень часто встречающейся в веб-проектах — определение местоположения по ip-адресу. Начну с того, что для того, чтобы определить местоположение пользователя — нужна некая geoip база. Приведу здесь два популярных бесплатных варианта:
IpGeoBase — очень хорошая бесплатная база, но, к сожалению, только по российским ip-адресам.
MaxMind — огромная база по ip-адресам всех стран. Предоставляют бесплатную lite-версию базы. Точность базы по российским ip-адресам не настолько хороша, как у IpGeoBase. Также предоставляют некое API для работы со своей базой, которое позволяет производить выборки очень быстро.

Допустим вы скачали эти базы и залили их в таблицы вашей БД Postgresql (сама закачка — несколько out of scope, если у кого-то возникнет желание — я могу в будущем рассказать о том, что такое команда COPY и с чем ее едят). В общем случае вы получите таблицу такой структуры:

startip	endip	location_id
2130706433	2130706433	1

Здесь:
startip — это начало блока ip-адресов в формате long
endip — конец блока ip-адресов в формате long
location_id — идентификатор локации (город, регион, страна и т.д., maxmind даже координаты содержит).

Задача

Как удобно делать выборки из деревьев типа 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

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

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

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

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

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

Недавно у меня возникла интересная задача по хранению некоторых данных в рамках сессии работы с БД 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! Чем с вами и делюсь…

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

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

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

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

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 (адрес и подробности доступны на сайте после регистрации). На встрече планируется участие ведущего администратора баз данных компании «Рамблер» Максима Богука.

Встала задача переноса сайта на новый сервер. Из проблем ожидалась несовместимость с 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 как и самой производительной СУБД из систем с открытым исходным кодом. Среди новшеств, касающихся производительности, стоит выделить:

Вышла новая версия краткого справочника по работе с PostgreSQL 8.3.

скачать в формате PDF/A4

скачать в формате HTML

---

оригинал материала

Новости Web 2.0, Веб сервисы, Социальные сети, Мэшап, AJAX, Теги

Джош Беркус (Josh Berkus) объявил о выходе PostgreSQL 8.3beta1 (см. официальный Changelog). Более полугода потребовалось разработчикам для того, чтобы завершить работу по обработке патчей (напомним, feature freeze состоялся 1-го апреля 2007 года). Так что самое время рассказать, чем же порадует нас в этом году самая развитая из открытых СУБД в мире.

Я разобью весь список на четыре части. В первой, для многих самой важной, части я перечислю изменения, которые так или иначе касаются производительности. Во второй — приведу список новых возможностей для программистов баз данных, призванных ещё более расширить и без того неслабый набор «фич» PostgreSQL. Третья часть посвящена нововведениям, предназначенным для администраторов баз данных. И, наконец, в конце я упомяну некоторые Open Source проекты, которые являются проектами-спутниками Постгреса (другими словами, имеют свой собственный цикл разработки).

Многие пользователи СУБД PostgreSQL знают, что сервер во время своей работы собирает разнообразную статистику, но не все знают, что ее полезно анализировать и как ее извлекать для этого. В этом небольшом тулките собраны несколько полезных запросов, дающих некоторое представление о том, как использовать это «скрытое знание», которое постоянно копится. Эти запросы можно использовать для мониторинга состояния PostgreSQL (ручного или с помощью плагинов для систем мониторинга вроде Nagios, Cacti или Zabbix), для поиска узких мест в работе сервера и многих других подобных задач. Помните, что это лишь верхушка айсберга; в документации можно найти описания нескольких десятков системных представлений, которые также могут быть полезны администратору PostgreSQL.