PostgreSQL *

Всем кому приходилось сталкиваться с процедурой 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. Надеюсь, друзья слонов помогут скрасить серый технический текст статьи.

PostgreSQL предлагает несколько вариантов резервирования данных. Обо всех них уже рассказано не раз, в том числе и на хабре. Но в основном рассказывается про технические особенности методов. Я же хочу постараться рассказать про общую стратегию резервного копирования, объединив все методы в эффективную систему, которая поможет вам сохранить все данные и уменьшить число погибших нервных клеток в критических ситуациях.
Вводные данные: сервер PostgreSQL 9.2, База размером >100Gb.