Базы данных *

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МБ
[Применение интер

Когда я работал Reddit и отвечал там за инфраструктуру, самой важной поддерживаемой системой для меня была Postgres, а на втором месте стоял брокер сообщений RabbitMQ. Он был необходим для работы Reddit — перед сохранением в базу данных все данные поступали в распределённую очередь. Например, если пользователь лайкал пост, то это записывалось в очередь и кэш, а затем пользователю передавалось сообщение об успешном выполнении. Затем программа обработки очереди брала этот элемент и пыталась записать его в базу данных, а также создать новую рабочую операцию для пересчёта всех списков, на которые влияет этот лайк.

Мы использовали эту архитектуру очередей задач, потому что она была простой, масштабируемой и обладала мощными возможностями:

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

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

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

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

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

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

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

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

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

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

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

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

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

Статья рассказывает о том, как банк строит единый цифровой профиль клиента, используя графы и эмбеддинги. Вы узнаете, как разрозненные данные о транзакциях, связях и балансах превращаются в мощный инструмент для анализа и прогнозирования. Разберем, почему классических табличных подходов недостаточно и как графы помогают выявлять скрытые связи между клиентами, как клиенты «превращаются в слова» и на чем измеряется успех. Статья будет полезна data scientist’ам, ML-инженерам и всем, кто интересуется практическим применением графовых методов и машинного обучения в крупном бизнесе.

Собственники и топ‑менеджеры МСБ часто сталкиваются с парадоксом: обороты растут, а прибыль тает. Причина не в рынке и не в ценах, а в хаосе внутри компании.

Отчёты собираются вручную, ключевые показатели никто не считает, решения принимаются на интуиции, без опоры на цифры.

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

Рассказываем, какие задачи решают оркестраторы в проектах внедрения корпоративных хранилищ данных. Выясняем, в чем разница между инструментами, и почему Dagster становится все популярнее в DWH-проектах, чем Airflow.

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

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

В большинстве материалов по SQL обсуждаются знакомые всем конструкции — SELECT, JOIN, WHERE, группировки, простые индексы. Но когда вы обрабатываете сложные данные, оптимизируете производительность или строите аналитические отчёты, ограничиваться только базовыми операторами — значит добровольно усложнять себе жизнь. В SQL есть мощные, но редко упоминаемые функции, которые помогают решить задачи элегантно и эффективно.

В этой статье, основанной на личных экспериментах и наблюдениях, мы рассмотрим три таких инструмента: PIVOT/UNPIVOT, CROSS APPLY/LATERAL и частичные (filtered) индексы.

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

Когда делаешь сервисы на C++ и вокруг летает много данных, в какой-то момент понимаешь простую вещь: REST хорош для управления сущностями, но плохо подходит для потока колонок в десятки гигабайт в секунду. Переносить фреймы по сто миллионов строк через JSON и спотыкаться об сериализацию — не наш путь. В статье рассмотрим как собрать транспорт данных на Apache Arrow Flight и где встраивается ADBC, чтобы между сервисами гонять таблицы почти на скорости сети и не городить зоопарк драйверов.

Привет, Хабр! Часто ли вам приходилось часами смотреть на сложный JOIN, пытаясь понять, почему он работает не так, как надо? Или, может, вы только начинаете свой путь в IT и слышите со всех сторон, что без SQL никуда? Вы правы, так и есть. SQL – это не просто строчки кода, это ваш ключ к данным, настоящий швейцарский нож для любого тестировщика, аналитика или разработчика.

Все мы знаем, что можно прочитать тонну теории, но без реальной практики она быстро выветривается из головы. Именно поэтому я решил поделиться своей коллекцией проверенных тренажеров и ресурсов. Здесь есть все, чтобы вы могли уверенно «заговорить» на языке данных: от уютных песочниц для новичков до хардкорных задачек с реальных собеседований в ведущих IT-компаниях. Так что устраивайтесь поудобнее, добавляйте в закладки и поехали тренироваться!

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

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

Сегодня мы рассмотрим реализацию Outbox паттерна в разных ЯП. Цель простая: одним атомарным действием обновлять бизнес-данные и фиксировать факт события, а затем надежно доставлять его в брокер. Разберем общую схему, конкуренцию воркеров, ретраи, дедупликацию, метрики и покажу, как это собрать на C#, Java, Go, Python и Node.js.

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

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

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

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

Меня зовут Кирилл Курдюков, в 2024 году я выступил в Питере на Joker — конференции для Java-разработчиков — с историей о том, как мы с командой делаем СУБД Яндекса удобной для джавистов.

Под катом статья, написанная по мотивам доклада. Это история о том, как маленькими шагами пройти путь от нативного клиента на Java до поддержки Hibernate, Liquibase, jOOQ и других популярных в мире Java-разработки решений.

Мы в Beeline Cloud развиваем площадку для обмена опытом между ИТ-специалистами — «вАЙТИ». Делимся техническими материалами, которые могут быть полезны хабражителям: как перекинуть два терабайта данных между дата-центрами за шесть часов, как перевести почту на локальный сервер Postfix, а также — какие SQL-запросы могли бы помочь Остапу Бендеру найти заветные стулья... (и другие материалы).

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

Механизм реализации транзакций - основная часть реляционных баз данных. Он упрощает разработку приложений, в которых гарантируется целостность данных. Стандарт SQL регламентирует, часть свойств по поддержке транзакций, но многие детали не стандартизованы. Как следствие, реализация поддержки транзакций в разных базах данных может существенно различаться. В настоящее время, многие пытаются перейти с Oracle на PostgreSQL. Для миграции приложений важно понимать различия в реализации работы транзакций, иначе можно столкнуться с неприятными сюрпризами, которые могут поставить под угрозу производительность и целостность данных. Поэтому Лоренс Альбе решил, что полезно сравнить реализацию работы транзакций в Oracle и PostgreSQL и свести различия в одной статье.

В мире систем обработки данных редко встречаются инструменты, которые одновременно просты в использовании и решают болезненные задачи архитекторов и инженеров. ReplacingMergeTree в ClickHouse — один из таких случаев. Этот движок берёт на себя рутину по дедупликации и обновлению строк, позволяя хранить только актуальные версии данных без лишних костылей. Как он работает на практике, зачем нужен ORDER BY, чем помогает столбец version и какие подводные камни могут ждать при проектировании — разбираем в статье.