PostgreSQL *

Привет, Хабр! Меня зовут Дмитрий Королёв, я инженер по нагрузочному тестированию Platform V Pangolin — целевой СУБД в Сбере и не только. Эту статью я написал вместе с моим коллегой Алексеем Хорохориным @AlexeyHorohorin. Наш продукт — специальная сборка PostgreSQL с доработками (крупных больше 30, а всего уже больше 70) в области безопасности, производительности, отказоустойчивости.

Условия для нас таковы: мы тестируем продукт целиком, в разных версиях, на разных ядрах. У нас работает три версии в параллель для восьми разных ОС, и тестировать нам нужно при использовании и неиспользовании разных фич. А теперь представьте, сколько тут интеграций…

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

Недавно попался на глаза запрос, которым хотели отобрать в таблице (очевидно, для последующего удаления) все id записей интервалов, которые полностью перекрыты каким-то другим интервалом того же owner'а.

Но self-JOIN показал себя не лучшим образом...

В прошлой статье был предложен вариант для создания docker образов БД для последующего использования в разработке и тестирования приложений в пайплайнах гитлаба.

Из-за перехода на новую инфрастуктуру k8s 1.30 (restricted psp) и новый гитлаб 17.3 все это ломается. Поэтому придется исправлять ситуацию!

Привет, Хабр! Меня зовут Станислав Епишин, я DBA в дивизионе поддержки решений в тестовых средах в СберТехе. Эту статью я написал вместе с Дмитрием Корневым, тимлидом и DBA. У Сбера есть целевая СУБД, которую разработали в СберТехе на основе open source версии PostgreSQL, — Platform V Pangolin. Наша команда перешла на Pangolin в числе первых, когда у продукта еще не было инструментов для мониторинга БД. Забегая вперед, позже появились такие решения — графическая консоль Platform V Kintsugi, расширение для сбора статистики — Performance Insights и система мониторинга IT‑инфраструктуры Platform V Monitor. А поначалу мы решили мониторить базы данных связкой Grafana, Prometheus и postgres_exporter. Но, во‑первых, столкнулись, с тем, что нам не хватает гибкости в использовании queries.yaml в postgres exporter. А, во‑вторых, так мы не могли регистрировать события с таймаутом меньше 15 секунд. Поэтому мы тогда сделали свой инструмент для мониторинга — pangolin_exporter.

Надеюсь, что эта статья будет полезна тем, кто мониторит инфраструктуру с помощью postgres_exporter и хочет кастомизировать все под свои нужды. Покажу детали и код решения.

В мире управления базами данных от эффективного хранения больших объемов информации зависит оптимизация производительности и использования дискового пространства. В этой статье разберем основные методы сжатия данных в TOAST, их эволюцию, плюсы и минусы PGLZ и LZ4 и продемонстрируем базовую работу с TOAST в Postgres. В завершение обсудим, как данные с различными методами сжатия могут храниться в одной TOAST-таблице.

Привет, Хабр!

Сегодня поговорим о том, как правильно настраивать автовакуумирование в PostgreSQL — одном из механизмов, который позволяет базе данных оставаться "в форме" и поддерживать производительность на должном уровне. Если неправильно подойти к настройке, можно столкнуться с деградацией скорости обработки запросов и внезапным ростом объема данных.

Задачи эксперимента

1) Оценить степень влияния регулярного выполнения vacuum/analyze на производительность СУБД.

2) Оценить степень влияния распухания таблицы на производительность СУБД.

Некоторые головоломки можно решать на SQL just for fun, а часть получается выразить на этом декларативном языке даже эффективнее других, императивных.

Попробовать сделать более наглядное решение, а заодно познакомить с некоторыми нетривиальными возможностями PostgreSQL меня натолкнул пост о решении на Python задачи Black and White.

Конференции

PGConf.СПб 2024

Появилось расписание [проверить!!]

Первый доклад — Павла Лузанова, возглавляющего отдел образования в Postgres Professional — (новое в) PostgreSQL 17 (а пока можно почитать его PostgreSQL 17: Часть 5 или Коммитфест 2024–03).

Андрей Бородин (Yandex Cloud) представит Необычные возможности системы резервного копирования WAL‑G, а Дарья Лепихова и Алексей Дарвин (оба Postgres Professional) — Выбор репликационного протокола при разработке pg_probackup3 (напомним, что 3-я версия не очередная, это практически переписанный с нуля pg_probackup, в отличие от 2.х).

Cиквел и приквел: занимательная археология Егора Рогова — это исторический экскурс, новый (кажется) для Егора жанр, но не сомневаюсь, что это будет информативно и увлекательно: расскажу, как работали с базами данных до Кодда и что изменилось с изобретением реляционной теории; поговорим о зарождении первых реляционных систем — System R и Ingres; о том, как появился и завоевал популярность язык SQL; о людях, которые определили наше настоящее и в какой‑то степени будущее.

От редакции: Майкл Стоунбрейкер - один из самых известных в IT мире ученых и отец-основатель Postgres. В соавторстве с Энрю Павло, недавно опубликовал большой обзор всех актуальных технологий систем управления базами данных. В этом материале — подробно обо всем, что произошло в мире баз данных за последнее время, а также прогнозы. Мы посчитали что нельзя лишать нашу аудиторию возможности ознакомиться с этим обзором, поэтому подготовили данный перевод.

Обычные последствия посое получения оповещения мониторинга «CPU Utilization High» — все в панике, лихорадочные поиски причин, аварийная ситуация, конфколлы и т. д. и т. п. Всё, как положено для ИБД.

Однако, если посмотреть на ситуацию чуть подробнее, то выясняется, что всё не так печально, а даже совсем наоборот и причин для паники — никаких.

Всегда ли снижение производительности является инцидентом и требует решения и поиска причин?

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

В статье, в самом общем виде, рассмотрены некоторые методы использования математической статистики и примерный порядок действий для определения факта наличия инцидента снижения производительности и установления одной из причин деградации производительности, на реальном примере.

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

Проблема воспроизводится на последней стабильной на данный момент версии PostgreSQL - 16.2. При этом используются стандартные настройки PostgreSQL. Я пробовал менять разные настройки, но мне не удалось добиться правильного плана в общем случае, поскольку в данном случае проблема скорее логическая, а не в определении стоимости вычислений. Однако, каждый может легко воспроизвести эту ситуацию локально и попробовать поиграться с настройками. 

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

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

Это пятая, заключительная часть статьи, в которой я скажу пару слов про расширения, мониторинг, а также подведу некоторые итоги по статье в целом.

Это четвертая часть статьи, в которой мы научимся работать с логическими и физическими резервными копиями, а также сравним алгоритмы сжатия.

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

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

Эта статья предназначена для системных администраторов, которые хотят научиться работать с PostgreSQL, но не знают, с чего начать.