Из названия не понятно буду ли я писать про странное тестовое задание или про то, как я упустил работу мечты. Дело в том, что я и сам не знаю. Но вы поставите все на свои места.
Как в одиночку собрать полноценный сервис мониторинга с проверками из 10 точек мира, алертами в Telegram/Slack и собственным агентом? Делюсь личным опытом выбора стека: почему FastAPI выиграл у Django, как TimescaleDB справляется с миллионами строк логов и зачем писать агент на Go, если основной код на Python. Только практика, архитектурные решения и честный расчет стоимости инфраструктуры в €11/мес.
Привет, Хабр!
Запрос работает 30 секунд. Вы смотрите на него, всё вроде ок: JOIN по индексированным полям, WHERE по дате, LIMIT 100. Должен летать, но что-то не летает. Добавляете индекс наугад — не помогает. Переписываете подзапрос в CTE и стало ещё хуже.
Проблема не в запросе, а в в том, что вы не смотрели в план выполнения. EXPLAIN ANALYZE показывает не что вы написали, а что PostgreSQL делает: какие индексы использует (и использует ли вообще), в каком порядке соединяет таблицы, где тратит время, сколько строк ожидал и сколько получил.
На связи Денис Волков из команды платформы данных в Yandex Cloud. В предыдущей статье мы рассказали, как устроен SPQR (Stateless Postgres Query Router): архитектура, компоненты и принципы. Красивая теория. Эта статья — про то, что происходит, когда теорию начинаешь применять к живому продакшену с десятками таблиц, набором микросервисов и новогодней нагрузкой. Про грабли, решения и конечно же проблемы.
Миграция базы данных в Legacy системах
Если ваша система не использует ORM
Если промышленное окружение вашей Системы находится не у Вас под контролем
Если нет возможности внедрить инструмент делающий “магию для миграций” - Liquibase / Flyway
И тем не менее, очень, очень и очень :) хочется контролировать как изменения в коде попадают в базу данных
Привет, Хабр!
PostgreSQL умеет блокировать строки (SELECT ... FOR UPDATE) и таблицы (LOCK TABLE). Об этом знают все. Но есть третий тип блокировок, который решает задачи, с которыми row-level и table-level locks не справляются: advisory locks. Консультативные блокировки — механизм, где PostgreSQL предоставляет инфраструктуру (атомарные блокировки с очередями ожидания), а семантику определяет приложение.
Это значит: вы берёте блокировку по произвольному числовому ключу, и PostgreSQL гарантирует, что никто другой не возьмёт блокировку с тем же ключом одновременно. Никаких таблиц, строк или ресурсов БД не блокируется — это чисто логическая блокировка, видимая только тем, кто её проверяет.
Звучит как-то абстрактно. Посмотрим на конкретные задачи, где advisory locks незаменимы.
В жизни разработчика периодически возникает задача каким-либо образом сохранить что-то древообразное. Это может быть оргструктура компании, каталог товаров, генеалогическое дерево и т.п.
Пришёл в проект, там легаси погоняет легаси. Спагетти такие что уже в рот лезут. Отчёты по филиалам открывались 30 секунд. Команда реально боялась нажать кнопку в рабочее время, а вдруг база ляжет.
Это была система управления розничной сетью: несколько филиалов, сотни тысяч записей о заказах, ежедневные отчёты по выручке и остаткам. На бумаге ничего страшного. На практике монолит на Django где бизнес-логика размазана по контроллерам так, что поменяй что-то одно и сломается три другого.
Первое, что я сделал: открыл EXPLAIN ANALYZE.
Эта история началась с подаренной коллегой своей новой книги: читая Jimmy Angelakos’ «PostgreSQL Mistakes and How to Avoid Them», я осознал один напрягающий меня факт — в Postgres команда EXPLAIN выдаёт слишком много информации. И примеры, которые автор обычно приводит, рассматривая тот или иной аспект систем баз данных, усложняют разбор задачи и рассеивают внимание. Так и родилась идея постфильтра для эксплейнов — чтобы сделать их более читабельными и проблемно-ориентированными.
Команда экспертов Postgres Professional — Павел Лузанов, Егор Рогов и Игорь Лёвшин — представила обновлённое 12-е издание своего бестселлера «Postgres. Первое знакомство». Главная новость: книга актуализирована под возможности новейшей 18-й версии PostgreSQL.
Это небольшое, но ёмкое руководство призвано максимально быстро и комфортно погрузить читателя в работу с самой продвинутой СУБД с открытым кодом.
Настоящая статья подготовлена с использованием технологий искусственного интеллекта.
В частности:
— экспериментальные данные обработаны и проанализированы нейросетью;
— иллюстративный материал, сопутствующие слоганы, а также предисловие и послесловие сгенерированы нейросетью;
— макет статьи редактировался и корректировался нейросетью.
Лицам, придерживающимся позиции «ИИ-веганства» (испытывающим устойчивый страх, неприязнь или психологический дискомфорт по отношению к нейросетевым системам), настоятельно не рекомендуется ознакомление с содержанием данной публикации, равно как и участие в её обсуждении, во избежание возможного нанесения вреда психологическому благополучию.
Логическая репликация в Postgres редко ломает прод внезапно — чаще она долго и методично копит проблему, пока replication slot удерживает всё больше WAL, потребитель отстаёт, а свободное место на диске начинает таять. В этой статье разбирается именно такая зона риска: как устроена работа replication slots, почему одних базовых настроек здесь недостаточно и какие практики реально помогают держать под контролем WAL, публикации, heartbeats, failover и мониторинг. Материал особенно полезен тем, кто работает с CDC, Debezium и production-инстансами Postgres, где цена ошибки измеряется уже не теорией, а стабильностью системы.
Привет, Хабр!
В течение последнего года я занимался разработкой аналитической панели для продавцов на маркетплейсах Wildberries и Ozon, а в перспективе планируется интеграция с Яндекс.Маркет. Я хотел бы поделиться своим опытом и представить систему WBOZYA-dash, которая предназначена для анализа продаж через эти маркетплейсы. До конца весны 2026 выпущу, думаю, с десяток статей на эту тему, а пока сделаю общий обзор своей системы.
Вторая часть серии по PostgreSQL из моих внутренних докладов. В этот раз — индексы: откуда берётся cost в EXPLAIN и почему это «попугаи», а не миллисекунды. Почему PostgreSQL игнорирует ваш индекс при высоком покрытии таблицы. Как физическое расположение данных на диске влияет на скорость даже при наличии индекса. Плюс GiST для нечёткого поиска с триграммами, GIN для полнотекстового поиска и EXCLUDE constraints для задач типа бронирования. Всё на примере таблицы с 4 миллионами строк.
На этапе тестирования я отобрал 6 городов (Москва, Санкт-Петербург, Новосибирск, Екатеринбург, Казань, Красноярск) и двух крупнейших провайдеров России - Ростелеком и Дом.ру. В планах масштабирование на большее количество городов и операторов.
Для парсинга тарифов у провайдеров применял связку Python + Selenium + BeautifulSoup, через хранимую процедуру складывал полученные данные в базу PostgreSQL.
Будучи поклонником идеи Айзека Азимова о коллаборации C/Si форм жизни, я провёл эксперимент и сгенерировал данный текст автоматически, AI агентом, по контексту, сформированному в процессе разработки новой фичи оптимизатора Postgres и расследования проблемного corner case, который время от времени завершался с runtime-ошибкой. Это первый опыт подобной совместной работы и проба пера, поэтому возможны шероховатости. Однако сама проблема и вариант решения для Postgres валидированы вручную. Любая, даже самая жёсткая критика, приветствуется.
Статья родилась в ходе наблюдения за одной из систем на Postgres, что у нас на поддержке. Результаты наблюдения несколько удивили, поэтому делюсь, ибо причинно-следственные связи далеко не очевидны.
Триггером к изучению, можно сказать, даже к расследованию, послужило событие, когда однажды утром сервер PG завалился, потому что процессы postgres заняли всю память.
В статье дан обзор одного из докладов конференции PgConf, которая прошла 23-24 марта 2026 года, Андрея Билле, главного инженера компании Postgres Professional. Название доклада: «Если ваш админ самурай или история о восстановлении очень нужных данных».
Мониторинг PostgreSQL сломан: 150 метрик в pg_stat_*, и ни одна не отвечает на вопрос «база здорова?». В статье — как устроен Health Score: единое число от 0 до 100, которое агрегирует состояние базы и заменяет 30 дашбордов Grafana.
Медленный запрос — это не приговор, это задача со своим решением. Но найти его невозможно, пока планировщик PostgreSQL остаётся для вас чёрным ящиком. Книга Павла Толмачёва «PostgreSQL 16. Оптимизация запросов» даёт то, чего не хватает большинству разработчиков и администраторов: системное понимание того, как планировщик принимает решения, — и практические инструменты, чтобы направить его в нужную сторону.
