PostgreSQL *

Всем привет! Меня зовут Андрей, я бэкенд‑разработчик ядра Яндекс Диска. В индустрии я уже около 15 лет и повидал некоторое ПО. Последние три года занимаюсь ядром файловой системы — всем, что связано с метаданными о файлах.

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

Однако при дублировании важно было избежать распределённых транзакций, так как они снижают общую производительность. Также проблемой был сам процесс перехода: у нас сотни миллионов пользователей, которые не должны были ощущать процесс перехода и потерять доступ к своим данным. При этом надо было выкатывать изменения не сразу на 100%, а частично, с возможностью в любой момент отключить функциональность. При выкатке также нельзя было допустить даунтайм.

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

Добрый день, коллеги!

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

В процессе загрузки наблюдалось следующее явление: через некоторое время процесс checkpointer переставал делать контрольные точки в зависимости от других параметров БД либо сразу, либо через 2-3 часа.

В данной статье описывается пошаговая настройка отказоустойчивой репликации PostgresPro-12 на двух серверах в изолированной среде без внешнего доступа и возможности развертывания третьего узла. Решение ориентировано на AstraLinux, но легко адаптируется под другие дистрибутивы. В условиях, где стандартные решения вроде Patroni с etcd или ZooKeeper неприменимы из-за требования минимум трёх нод, предлагается альтернативный подход на базе keepalived и кастомных bash-скриптов.
Ключевой особенностью является использование keepalived не только для управления виртуальным IP-адресом (VIP), но и для автоматического переключения роли PostgreSQL между мастером и репликой при отказе основного сервера.

Делимся опытом создания робота-диспетчера на low-code платформе n8n для обработки большого потока заказов. В статье рассказываем, как использовали Redis для очередей и динамической конфигурации, показываем реальные workflow и код, а также делимся, как боролись с утечками памяти и гонкой состояний. Будет полезно разработчикам, аналитикам и тимлидам, которые смотрят в сторону low-code для решения реальных бизнес-задач.

Что известно про Greenplum?
Это MPP система на базе PostgreSQL, которая нужна, чтобы работать с большими объемами данных и делать OLAP. Отлично, но лично меня не устраивает это поверхностное знание, хочется узнать, что внутри. Какие алгоритмы использует Greenplum в своих процессах. Я хочу начать с дистрибуции, и приглашаю вас с собой в это путешествие.

25 сентября ожидается выход PostgreSQL 18. Эта статья о мартовском коммитфесте завершает описание новых возможностей 18-й версии. Статья получилась большая, ведь последний мартовский коммитфест по традиции наиболее объемный и богатый на новинки.

Самое интересное из предыдущих коммитфестов версии можно прочитать здесь: 2024-07, 2024-09, 2024-11, 2025-01.

Клиентские и серверные приложения

pg_dump[all]/pg_restore: выгрузка и восстановление статистики
Сбор статистики после обновления сервера
pg_upgrade --swap: перемещение каталогов из старого кластера в новый
pg_combinebackup --link или жесткие ссылки вместо копирования файлов
pg_dump[all], pg_restore: --no-policies
pg_createsubscriber: включение параметра two_phase для всех подписок
pg_createsubscriber: удаление публикаций на подписчике
pg_createsubscriber: создание подписок для всех баз данных сервера публикации
psql: конвейерный режим работы
psql: информация о текущем подключении
psql: настройка умолчания для интервала времени в команде \watch
psql: \dx показывает версию расширения по умолчанию

Мониторинг

NUMA: инструменты мониторинга систем с архитектурой неоднородного доступа к памяти
pg_stat_get_backend_wal: статистика WAL для отдельного процесса
EXPLAIN: фактическое число строк с точностью до двух знаков после запятой
EXPLAIN: интерфейс для добавления команде новых параметров
Журналирование неудачных попыток захватить блокировку
Журналирование времени на подключение нового сеанса
log_line_prefix: IP-адрес локального сервера
pg_stat_statements: нормализация команд со списками констант в IN
Дополнительные инструменты мониторинга переполнения буфера WAL
Отслеживание времени простоя при выполнении очистки и анализа

[Авто]очистка и анализ

vacuum_truncate: управление обрезанием пустых страниц в конце таблицы
Более частая автоочистка «мертвых» строк в больших таблицах
Более частая автоочистка после вставки новых строк
Нетерпеливая заморозка в помощь агрессивной очистке

Производительность

Асинхронный ввод/вывод
io_combine_limit: максимальный размер увеличен до 1МБ
[Применение интер

Привет, Хабр! Писать статьи — дело приятное, но только если нет на плечах релиза. Релиз оказался марафоном на месяцы, где каждый день мы жили задачами и доработками. Мы делились на три фронта: кто-то закрывал критические баги («баг-фиксеры»), кто-то добивал бизнес-логику («бизнес-логеры»), а кто-то всерьез отрабатывал план «Б» — ставил свечи за успешный релиз («молитвенники за прод»). Играли мы на разных уровнях, но финальный босс у всех был один: система, которую мы героически толкали в ПРОД, как кота в переноску: и он не хочет, и нам страшно.

Но как бы там ни было, сегодня на ПРОДе живет большая система. Прям такая, что, если бы она была организмом, у нее были бы печень, почки и амбулаторная карта в Сфере Знания. 

Пользователи — сотни сотрудников. Система — новая, кнопки — непонятные, интерфейс — как квартира после переезда: ты вроде дома, но даже чайник включить страшно.

И вот представьте: в этой «квартире» все двери распахнуты настежь. Любой может зайти куда угодно, нажать любую кнопку, открыть любой экран. Кнопки, которые лучше не трогать, экраны, куда и разработчик-то без инструктажа не сунется… Получился цифровой «чулан Моники» — хаос, который мы срочно должны были привести в порядок. 

Решение было очевидным: нужна ролевая модель.

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

HistoryHelper - плагин для DBeaver

Зачем и почему?

Работая с БД часто приходится вручную писать SQL для создания history-таблиц, которые хранят "историю" о каждой записи из таблицы. То есть, если запись создана/изменена/удалена, для неё создается новая запись в таблице с окончанием "_hist" или "_history".

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

Поэтому, я решил сделать небольшой плагин для DBeaver, который предоставляет удобное меню выбора колонок и событий.

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

В данный момент реализован самый простой функционал.

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

В статье мы разберёмся, как передавать и получать вложенные объекты в процедурах и функциях PostgreSQL с помощью JDBC.

Когда фильтра по ключу секционирования нет, локальные индексы превращаются в марафон по секциям. Новый gbtree держит единый каталог ключей и прыгает к строке по PK; покажем алгоритм, реальные цифры и ограничения (PK обязателен, ON CONFLICT не работает) — и где это решает боль в CRM/биллинге.

Привет, меня зовут Анатолий, я ведущий разработчик в ITFB Group. У нас высоконагруженный сервис торговых операций. И раз в неделю, как по расписанию, раздавался панический звонок: «Опять пропали запросы!». Мы неслись смотреть логи — а там... ничего. Ни ошибок, ни падений. Никаких пятисотых, только стабильные двухсотые. Стенды dev и prod молчали, как рыбы. Запросы загадочным образом появлялись через некоторое время, и всё работало, пока история не повторялась снова. Это был не баг, это был призрак. Призрак в сети.

Сегодня я расскажу, как мы его поймали.

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

Я много лет занимался тех. консалтингом и работал архитектором в компаниях с кучей внутренних команд со своими проектами и один из самых частых вопросов:

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

Постгрес – не просто реляционная БД, а настоящий кладезь фич, о которых начинающий разработчик может и не догадываться. Всё началось с того, что PostgreSQL изначально писался на С/C++ и всегда тянуло к расширению стандартного SQL набора возможностей. Так однажды разработчики решили добавить в него JSONB, логику на уровне запросов и многое другое – что в итоге сделало его не хуже NoSQL-систем. Но вернёмся к малоизвестным фичам. Ниже – пять приёмов и возможностей, которые неожиданно полезны в повседневной работе.

Как построить микросервисы на RabbitMQ так, чтобы система не падала каскадом, а деградировала предсказуемо: outbox, mandatory, AE, идемпотентность, DLQ, приоритеты и реальные грабли из продакшена

В планах выполнения запросов PostgreSQL рассчитывается два числа, которые показывает команда EXPLAIN:cost=A..B Без использования курсора, планировщик выбирает план с наименьшим значением B, а при использовании курсора: A + cursor_tuple_fraction * (B − A), где cursor_tuple_fraction - параметр конфигурации, который можно установить на уровне сессии и других уровнях.

Если вы инженер в крупной компании, а особенно если ваша организация поставляет свои услуги в виде SaaS-решений, то вам так или иначе придется решать задачу мониторинга работы всех ваших баз PostgreSQL. На них часто бывает завязан функционал, важный для компании с точки зрения финансовых рисков, поэтому крайне желательно организовать не только мониторинг, но и получение уведомлений, когда что-то идет не по плану (или пойдет в ближайшем будущем). В рамках статьи мы рассмотрим несколько способов, как это можно сделать: самостоятельно, с использованием уже привычного стека Prometheus + Grafana, либо подключая сторонние open-source специализированные решения для мониторинга PostgreSQL, либо же используя специализированные платные решения. По каждому варианту поймем все плюсы и минусы, чтобы вы cмогли более уверенно выбрать свой путь.

Ivory — это бесплатный open-source инструмент с веб-интерфейсом, созданный для управления кластерами PostgreSQL, которые работают под контролем Patroni. Если раньше для таких задач приходилось использовать командную строку или Patroni API, то с Ivory всё можно делать через удобный браузерный интерфейс.

Цель проекта — упростить жизнь администраторам баз данных (DBA) и разработчикам:

Современная сфера IT — как бурное море: динамичная и полная вызовов, особенно для новичков. Поймать волну новейших технологий, получить реальный опыт и поддержку менторов можно на хакатоне. Как раз такой сейчас проходит — на More.tech участников ждут практические кейсы из мира большого IT и командная работа. А победителей — призовой фонд 1,5 млн руб. и шанс получить оффер от ВТБ. В статье вместе с лидерами треков расскажем, что ждет участников More.tech 2025, почему задачи хакатона актуальны для IT сегодня и как их преодолеть.

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

Команда Python for Devs подготовила перевод статьи о том, как легко «сломать» внешние ключи в Django и что с этим делать. Если кратко, то unique_together больше не нужен, индексы на ForeignKey работают не так, как вы думаете, миграции могут блокировать продакшен, а правильный порядок операций и частичные индексы экономят гигабайты и спасают нервы.

Как я сделал MoonTap - космическую кликер-игру прямо в Telegram на Rust и Vue

Когда в Telegram появились первые кликер-игры вроде Notcoin, стало ясно: мессенджер идеально подходит для лёгких и социальных игровых проектов. Никаких установок, просто открыл ссылку и играешь.

Я решил попробовать свои силы и собрать свою игру - так родился MoonTap, космический кликер с монетками, бустерами и заданиями. На фронтенде - Vue и Canvas-анимации, а для бэкенда я впервые использовал Rust, хотя до этого писал только на Node.js.