PostgreSQL *

Незаметно промелькнул пост о юбилейном GSoC 2014, и наш проект PostgreSQL снова оказался в числе участников. Надо сказать, что если на многие другие проекты есть большой конкурс, то мы похвастаться этим не можем. Будь тому виной высокий порог вхождения и сложность проекта или недостаточно активно проводимая кампания, но нам приходилось даже возвращать неиспользованные slot'ы, так как на них не нашлось достойных претендентов. Как mentor, я не могу выдавать информацию о числе и составе заявок, скажу только, что ситуация меня печалит ещё больше, чем в прошлые годы.

Всем кому приходилось сталкиваться с процедурой failover при работе с потоковой репликацией в PostgreSQL, наверняка озадачивались вопросом: «А как бы мне ничего заново не копировать, а по-быстрому завести старый мастер в качестве stand-by». Так вот к сожалению, встроенной такой функциональности в PostgreSQL, увы нет. Да, нельзя так просто взять и подключить старый мастер к новому и чтобы все заработало. Для этого нужно повторить процесс настройки потоковой репликации заново, т.е. скопировать весь кластер и запустить postgres в режиме hot-standby.
К счастью работы в этом направлении ведутся, причем результаты довольно не плохие. Называется же проект pg_rewind.
Сразу предупреждаю это еще не production-ready и пост носит характер how-to + technology preview.

Чуть более года назад, стояла задача написания web приложения работающая с БД Postgresql. К моему сожалению, стандартного адаптера для работы с БД PostgreSQL не было, а с тем, что был найден на просторах интернета ( бесплатный ) работать было не возможно.
В итоге было решено обойтись библиотекой Npgsql.
Как работать с этой библиотекой, есть документация и множество примеров в интернете. Сразу же после начала работы с ней, мне не понравилось, что нужно много писать однотипного кода. Для облегчения работы была создана дополнительная прослойка в виде отдельного класса, для работы с БД через данную библиотеку.

Особенности:
1. данные для подключения берутся с файла web.config
2. есть возможность для работы с несколькими подключениями. ( например если у проекта модульная система, и каждый модуль работает только со своей схемой )

При разработке проектов используем БД PostgreSQL, благодаря ее открытости, бесплатности и довольно большого функционала. По принятой архитектуре, для таблиц создаем вьюшки (представления) и приложения работают уже с ними. Во многих случаях вьюшки один в один копируют таблицы, но каждую из них надо создавать и писать правила для обновления, удаления и вставки записи, что занимает время.
И вот в один из прекрасных дней, мне это надоело и я решил автоматизировать этот процесс. Вот так появилась следующая функция:

Здравствуйте!

Базы данных — это не просто, да. Но это всем очевидно, и об этом написано 100500 толстых книг. Поэтому могут вызывать особенное удивление и озабоченность появляющиеся в данном разделе тексты на пять абзацев, авторы которых пытаются делать выводы относительно предельно развитой opensource СУБД.

Прочитав статью Базы данных в онлайн играх и особенно комменты к ней, я в очередной расстроился от мысли, что многие разработчики меняют БД в своём проекте, пытаясь этой сменой решить свои проблемы, не исчерпав, однако, всех возможностей, предоставляемой заменяемой БД. Я принимаю участие в работе над проектом, БД которого характеризуется:

• Количеством транзакций порядка 5'000 — 10'000 в секунду
• Объемом примерно в 100ГБ (который бодро растёт)
• Примерно равным количеством операций на чтение/запись
• Преимущественно мелкими транзакциями

В силу, как говорится, исторических причин, вся база представляет из себя, гхм, одну базу, пока без шардинга, который мог бы решить ряд проблем. Тем острее стоит вопрос о поиске решений, заключённых именно в особенностях PostgreSQL. Решений, которые можно реализовать малой кровью.

Я опишу некоторые проблемы, с которыми мы сталкиваемся, и применённые решения. Если кто-то сочтёт это полезным — ради Бога. Если кто-то поправит — я буду только рад обнаружить уязвимость в используемых подходах и увеличить эффективность работы БД. Описанное может быть применено без вмешательства в логику приложения, исключительно путём модификации схемы БД.

Всем привет!
Решил описать основные моменты настройки отказоустойчивого (HA) кластера БД PostgreSQL в IaaS среде от Amazon — AWS.

Про настройку указанной связки с момента появления в свет 9й версии с нативной репликацией уже написано достаточно много статей, поэтому подробно останавливаться на настройке самого PostgreSQL и pgpool не буду, тут все относительно стандартно. Приводимые куски конфигов непригодны к бездумному копипасту, в любом случае придётся открывать свои конфиги и править необходимые параметры. Не хочу поощрять процесс конфигурации по методу копипаста.

Добрый день!

В этой статье я покажу как легко и просто мигрировать (перенести данные) с PostgreSQL на облачную базу данных Windows Azure SQL Database.

Основные шаги:

1. Создание новой базы данных в панели управления Windows Azure
2. Установка ODBC-драйвера для PostgreSQL
3. Создание проекта в SQL Server Data Tool
4. Импорт данных

Недавно я выложил статью со «скелетом» схемы данных, который можно использовать для создания своих схем PostgreSQL.
Помимо собственно скриптов разворачивания схемы, создания объектов, там были примеры хранимых функций и Unit-тесты на них.



В этой статье я хочу на примере pg_skeleton подробней остановиться на том, как писать тесты для хранимых функций PostgreSQL при помощи pgTAP.

Здравствуйте, хабрачеловеки! Вы, вероятно, уже пощупали материализованные представления, появившиеся в PostgreSQL 9.3. Одним из недостатков есть то, что в процессе обновления представления используется эксклюзивная (ACCESS EXCLUSIVE) блокировка, делающая невозможным запросы к представлению. В PostgreSQL 9.4 планируется добавить возможность чтения из представления во время его обновления. Ну, а пока, в этой небольшой заметке, я хочу показать один из способов выхода из этого положения.

Реляционная базы данных — зверь сравнительно непознанный, и имеет репутацию генератора проблем. Не то, чтобы проблем не существовало, но как и с другими инструментами, чаще всего сложности возникают от неумения их (РСУБД) готовить.
Готовить с одной статьи не выучиться, но одно блюдо сдюжим.

Я постарался выделить скелет, набор скриптов, на базе которого можно делать свои схемы данных PostgreSQL и тестировать их при помощи pgTAP: github.com/C-Pro/pg_skeleton
И в качестве приятного бонуса я прикрутил это дело к Travis, чтобы у вас ещё и CI было уже на старте :)

Многие из нас сталкивались в своей работе с СУБД. На текущий момент базы данных в том или ином виде окружают нас повсюду, начиная с мобильных телефонов и заканчивая социальными сетями, в число которых входит и любимый нами хабр. Реляционные СУБД являются наиболее распространенными представителями семейства СУБД, и большинство из них являются транзакционными.
В институте нас заставляли заучивать определение ACID и стоящие за ним свойства, но почему-то стороной обходились подробности реализации этой парадигмы. В данной статье я постараюсь частично заполнить этот пробел, рассказав о MVCC, которая используется в таких СУБД как Oracle, Postgres, MySQL, etc. и является весьма простой и наглядной.

Год заканчивается, а я давно не писал заметок о проверке открытых проектов. Мне уже неоднократно предлагали проверить проект PostgreSQL Database Management System. Этим я и занялся. К сожалению, грандиозной и интересной статьи не получится. Я заметил только несколько типовых ошибок. Так что в этот раз получилась совсем небольшая статья.

Доброго времени суток. При работе с базой данных для сайта иногда возникает ситуация, когда приходится выбирать, как и где хранить изображения. Среди возможных вариантов, как правило, имеются следующие:

• изображения находятся целиком в БД
• изображения находятся в файловой системе, в БД хранится имя файла
• изображения находятся во внешнем специализированном сервисе

Хоть PostgreSQL и предоставляет возможность хранения в БД файлов (непосредственно в bytea полях или через large objects), это наименее оптимальный вариант, как в плане скорости, так и потребляемой памяти. Другой, общепринятой практикой, является хранение изображений в виде файлов на диске, для сайта формируется путь к изображению. Из преимуществ — возможность кеширования или использование специализированной файловой системы. И третий вариант — для изображений выделяется отдельный сервис, в котором может быть кеширование, маштабирование на лету, изменение формата. Попробуем реализовать взаимодействие PostgreSQL с таким сервисом.

Подолжаю публиковать авторскую переработку Understanding EXPLAIN от Guillaume Lelarge.
Ещё раз обращу внимание, что часть информации для краткости опущено, так что настоятельно рекомендую ознакомиться с оригиналом.

Предыдущие части:

Часть 1
Часть 2

Подолжаю публиковать авторскую переработку Understanding EXPLAIN от Guillaume Lelarge.
Ещё раз обращу внимание, что часть информации для краткости опущено, так что настоятельно рекомендую ознакомиться с оригиналом.

Предыдущие части:

Часть 1

Почему запрос выполняется так долго? Почему не используются индексы?
Наверное, все слышали об EXPLAIN в PostgreSQL. Но не так много тех, кто понимает, как его использовать. Сам длительное время не мог найти доступного для понимания учебника (плохо искал?).
Надеюсь, эта статья поможет желающим разобраться с этим замечательным инструментом.

Предыстория

При разработке проекта для онлайн навигации (в будущем и оффлайн) возникла необходимость разработки собственных онлайн карт. Сервисы от Google, Bing и т.п. имеют ограничения в использовании их карт в коммерческих целях. Бесплатные же, типа OpenStreetMap, не удовлетворяли требования заказчика.
Стал вопрос о создании онлайн карты (тайлов карты) для всего мира. Стиль приближенный к Google и Skobbler. Данные на основе OpenStreetMap.

Привет уважаемому сообществу!

В какой-то момент времени встала потребность перенести базу приложения на django с mysql на postgresql. Первые два захода на эту проблему были неудачными, но позволили разобраться с целостностью данных, искоренить проблемы для manage.py syncdb и manage.py migrate.

Здравствуйте, хабрачеловеки! Темой этой статьи будет создание расширений для PostgreSQL. В качестве примера, мы реализуем небольшую библиотеку для работы с 3D векторами. Параллельно будут рассмотрены пользовательские типы, операторы и приведения типов. Не будет лишним ознакомися с этим материалом, так как реализация хранимых функций будет на языке C. Надеюсь, друзья слонов помогут скрасить серый технический текст статьи.