Сегодня я хочу рассказать вам об одном из вариантов доставки событий для распределённого приложения на Java.
Это доставка событий через БД, в которой хранится состояние распределённого приложения.
PostgreSQL 18 вот-вот выйдет, и это не просто минорное обновление, а настоящий прорыв для разработчиков и администраторов БД. В новом переводе от команды Spring АйО рассмотрим ключевые новинки — асинхронный I/O для ускорения чтения, поддержка UUID версии 7 с улучшенной сортировкой, skip scans в B-tree индексах, виртуальные вычисляемые столбцы и даже OAUTH 2.0 для аутентификации. Всё это делает Postgres ещё более быстрым, гибким и современным.
Self-modifying SQL — это техника, при которой SQL-запросы не просто выполняют фиксированную операцию, а генерируют, изменяют и выполняют другие SQL-запросы во время работы приложения. Эта концепция может показаться экзотической и даже спорной, но в определённых сценариях она позволяет создать гибкие, адаптивные решения для динамического управления базой данных.
Эта статья предназначена для разработчиков всех уровней: от начинающих, которые хотят понять основы динамического SQL, до продвинутых специалистов, интересующихся нетривиальными приёмами и автоматизацией управления данными.
Про протокол MCP (Model Context Protocol) сейчас говорят всё чаще. Этот протокол позволяет нейросетям общаться с внешним миром. С его помощью к LLM можно подключать любые источники данных или системы управления, и всё это через один универсальный стандарт. MCP часто сравнивают с USB — устройство одно, протокол один, а число сценариев применения практически бесконечно.
В статье расскажу про практический сценарий «как связать LLM и базу данных». Это может сделать любой на своём компьютере.
Протокол MCP придумали ребята из Anthropic. Далее будем использовать нейросети Claudе Sonnet и Claude Opus — это LLM от Anthropic.
Зачем это нужно? Такая связка позволит промтами вытаскивать инсайты из данных, создавать отчёты в PDF и строить интерактивные отчёты в HTML. Это работает на моём компьютере последние два месяца и результаты очень обнадёживающие.
Чтобы было интереснее, в качестве данных возьмём все вакансии Habr Career c описаниями.
В одной из московских школ мы сделали Telegram-бота, который автоматизировал «операционку»: согласия на мероприятия, запись на кружки, заявки в хозчасть/ИТ, массовые оповещения, анонимный канал психолога и контур директора с согласованиями и дашбордами. Я старался максимально упростить сложную и разрозненную модель управления.
Проект реально сработал, но его пришлось закрыть: с 2025/26 учебного года все школьные коммуникации перевели в национальный мессенджер «Макс» (MAX), а Telegram оказался «под запретом».
Знакомо чувство, когда интеграционные тесты с PostgreSQL в Go работают дольше, чем хотелось бы? Каждый тест создает базу заново, применяет миграции, и большая часть времени уходит не на проверку логики, а на подготовку окружения. В этой статье я расскажу о своем open-source решении на Go, которое использует встроенные механизмы шаблонов PostgreSQL, чтобы ускорить этот процесс в полтора раза, уменьшить потребление памяти и сделать ваши тесты по-настоящему параллельными.
В статье рассматривается логирование соединений с базами данных кластера PostgreSQL. Системы мониторинга создают сессии для сбора метрик и проверки доступности экземпляра. Это создаёт большое число записей в диагностическом журнале кластера, затрудняя его анализ. Администраторы ищут возможность отключения логирования для сессий мониторинга. Такая возможность есть только у параметра log_disconnections. Приводится пример, как с его помощью отключить логирование при создании сессии. Также рассматриваются особенности использования расширений pgaudit и pgaudittofile, которые позволяют выводить логирование соединений в отдельный файл аудита.
25 сентября в Москве мы снова собираем участников Java-сообщества вместе. В программе: хардкорные доклады, дискуссия о будущем Spring в России и много живого общения.
Регистрируйтесь на митап по ссылке.
А пока присоединяйтесь к нашему ТГ-каналу и чату Java Rock Stars Meetup, чтобы быть в курсе новостей митапа.
Регулярные выражения (или regex) — это особые текстовые строки, используемые для описания поискового шаблона. В PostgreSQL regex становится незаменимым инструментом, особенно при работе с большими объёмами неструктурированных строковых данных.
Возможно, у кого‑то есть вопрос: «А для чего нам регулярные выражения в БД?» И мы вам ответим:
Регулярные выражения (regex) позволяют описать сложные текстовые шаблоны компактно и гибко.
Совсем скоро (в конце сентября) выйдет PostgreSQL 18. Релиз готовит важные обновления — от асинхронного I/O до EXPLAIN с показателями CPU и WAL.
Довольно громкая новинка — нативная поддержка UUIDv7, нового стандарта уникальных идентификаторов, идеально подходящих для B-tree индексов.
В новом переводе от команды Spring АйО рассказывается, почему это важно, как работает UUIDv7 и чем он лучше UUIDv4 для современных распределённых систем.
Привет, Habr! На связи эксперты команды сервиса WatchDog — Дмитрий Коновалов и Геннадий Переломов.
В ВТБ, у нашего основного заказчика, мы развиваем сервисы автоматизации сопровождения баз данных. Одной из ключевых СУБД в инфраструктуре является PostgreSQL. Поддержка её в актуальном состоянии требует периодических мажорных обновлений, которые остаются одной из самых трудоёмких задач для DBA, особенно в ночные или выходные технологические окна.
В этой статье мы расскажем, как разработали внутренний сервис, позволяющий администраторам прикладных систем запускать мажорное обновление PostgreSQL в один клик и без участия DBA.
Команда Python for Devs подготовила перевод статьи о том, как можно освободить десятки гигабайт места в PostgreSQL без удаления данных и индексов. TL;DR: удаляем неиспользуемые индексы, чистим bloat, пересобираем таблицы и используем частичные индексы, чтобы хранить только то, что реально нужно.
Всем привет! Меня зовут Андрей, я бэкенд‑разработчик ядра Яндекс Диска. В индустрии я уже около 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, который предоставляет удобное меню выбора колонок и событий.
После нескольких выходных дней получилась минимальная реализация, которой хочу с вами поделиться.
В данный момент реализован самый простой функционал.
