Все данные лежат на быстрых SSD, хотя заказы трёхлетней давности читают раз в квартал. Это значит, что вы платите за дорогую ёмкость там, где она не нужна. Разбираем, как в Postgres Pro Enterprise расширения pgpro_ilm и pgpro_usage сами переносят редко используемые секции, таблицы и индексы на дешёвые диски. Показываем правила, на что они реагируют и какие подводные камни есть у этого механизма.
«Давайте скормим модели документацию, а она сама нагенерит тест-кейсы». Вот что обычно слышишь, когда разговор заходит про нейросети в тестировании. Звучит красиво, но в моей работе это оказалось чуть ли не самым бесполезным сценарием. Я занимаюсь автоматизацией, ручные кейсы пишу не каждый день, и генерация их «по щелчку» закрывает не ту боль. Для меня настоящая боль в другом. Как понять, что вообще нужно проверять, где лежат данные, какая логика сейчас актуальна, какие сценарии уже покрыты и где документация расходится с тем, как система ведёт себя на самом деле.
Поэтому я стал относиться к LLM как к ассистенту, которому можно постепенно отдавать доступ к рабочему контексту: документации, векторному поиску по ней, базам данных, тест-кейсам и репозиторию автотестов. Всё это я подключал через MCP. И дальше расскажу, как именно всё подключал, на какие грабли наступил, а что в итоге реально выстрелило.
Это помогло. Я стал быстрее вникать в незнакомую бизнес-логику и проверять гипотезы по данным, не перечитываю каждый раз всё заново, и трачу меньше умственных сил на механический поиск. По кнопке LLM так и не генерирует ручные тест-кейсы, но это, я думаю, нормально.
Обычно пишут: техжурнал на рабочем сервере включайте точечно, иначе гигабайты в час. А сколько именно? Я прогнал одну нагрузку шесть раз с разными настройками logcfg.xml и посчитал объём, процессор и записи по событиям. Базовый набор дал 0,8 МБ в час, «всё подряд» — 10,6 ГБ. Плюс несколько неочевидных мест: единицы duration в фильтре, тысячи пустых каталогов rac_<pid> и ошибки запросов, которых нет в EXCP.
Мой знакомый - отличный архитектор, но полнейший сноб. У него в проде четыре разных базы данных. PostgreSQL для OLTP, в ClickHouse у него лежат данные OpenTelemetry и веб аналитики, Elasticsearch для полнотекстового поиска в приложении, а MongoDB - “так исторически сложилось”.
Между всем этим ETL, CDC вместе с дежурствами разработчиков в поисках где именно результаты не сходятся. Для него это все продуманная архитектура, а для меня излишняя сложностью в поддержке и разработке.
Недавно рассказал ему чем я занимался последнее время. Добавил табличный движок из ClickHouse в PG и поборол раздувание таблиц при обновлениях.
Две вкладки обновили токены. Оба запроса вернули 200 OK, а при следующем обновлении пользователя отправило на экран входа. Такое возможно даже с транзакцией и FOR UPDATE.
Разберём, как это получается, почему повтор refresh не обязательно означает потерю ответа и как новый токен может пережить отзыв всего семейства. Последнюю гонку воспроизведём в двух соединениях PostgreSQL.
DVT — open-source платформа визуального ETL: пайплайн собирается из нод (чтение → преобразования → запись) и выполняется на воркерах поверх Dask. Я разрабатываю бэкенд DVT, в статье — устройство одного из его компонентов.
Нода чтения из БД должна одинаково работать на таблице в 10 тыс. и в 100 млн строк, на шести СУБД (PostgreSQL, MySQL/MariaDB, MS SQL, Oracle, SQLite, ClickHouse), в воркере с ограниченной памятью и без избыточной нагрузки на источник.
Ниже — устройство планировщика чтения core/db/read_v3: оценка размера строки, расчёт числа партиций, построение границ range и hash, стоимость разметки для источника и интеграция с Dask.
Два популярных совета по PostgreSQL для 1С, больше shared_buffers и выключенный synchronous_commit, мы проверили тестом Гилева. Но пять прогонов без изменений разошлись шире, чем любая из настроек. Рядом таблицы, команды смены параметров и шесть шагов для своего замера.
У сменного персонала нет даты увольнения. Грузчик или комплектовщик, который работает самозанятым по договору оказания услуг, не пишет заявление. Он просто перестаёт брать смены, а через месяц может снова появиться в приложении, как будто никуда не пропадал. Поэтому классическая формула, по которой считают текучесть кадров организации (уволившиеся за период, делённые на среднесписочную численность), здесь не работает: в числителе нечего считать.
Зато есть журнал событий: в нашем приложении у исполнителя на каждой смене четыре кнопки: «Выехал», «На месте», «Работа выполнена», «Оплата получена», и каждое нажатие ложится строкой в таблицу. Из такого журнала текучесть можно посчитать прямо в базе, без выгрузок в Excel и без Python: нужны две оконные функции и один честно выбранный параметр. Ниже разбор по шагам, с запросами и с тем, как сильно результат зависит от этого параметра: на одних и тех же данных месячная текучесть получается и 19%, и 213%.
Запросы написаны для SQLite (нужна версия 3.25 или новее, где появились оконные функции), в конце есть заметки про PostgreSQL.
Лет десять назад я делал инструмент сверки таблиц для мультимастера — крайне неэффективным способом: брал снапшот и под ним просто шёл по таблице, матчил строки. С тех пор задача стала только актуальнее: одни и те же данные всё чаще живут в разных дата-центрах, на разных инстансах с надёжным failover’ом, и рано или поздно приходится задумываться о проверке их идентичности.
Готовые инструменты для сравнения таблиц в мире Postgres есть — pg_comparator, pgCompare, ACE. Однако давайте сегодня поразмышляем, стоит ли ради большей эффективности городить огород с дополнительным софтом. Может быть, хватит простой транзакции и golang-скрипта, выполняющего SQL на обоих инстансах?
Расписание живёт в приложении ИТМО, а вся моя жизнь — в календаре: работа, секции, встречи, поездки. Каждую неделю я сверял одно с другим и почти каждый раз находил расхождение. В итоге сделал сервис, который превращает расписание в подписку: одна ссылка, и пары появляются в календаре сами. Сервис неофициальный: у ИТМО такой подписки нет, поэтому её сделал я.
Создать игру без знаний в IT практически невозможно, но мы нашли решение и разработали платформу, на которой пользователи могут сделать свои аналоги популярной игры Wordle. Как проходила работа над проектом, почему пришлось заново переписать почти весь код и что получилось в итоге, рассказываем в статье.
Патч UniqueKeys для PostgreSQL предлагает научить планировщик распознавать случаи, когда строки запроса уже гарантированно уникальны. Сейчас он (планировщик) не всегда может это определить и выполняет лишнюю работу: повторно проверяет данные на дубликаты, хотя в этом нет необходимости, или упускает более дешеый план выполнения. Механизм UniqueKeys позволяет прослеживать уникальность данных через сложные соединения и подзапросы, чтобы исключать ненужные операции DISTINCT и GROUP BY и точнее оценивать стоимость запросов. В Tantor Postgres этот механизм уже реализован, а патч предложен для рассмотрения сообществом PostgreSQL в рамках CommitFest.
Мы дошли до финала: 30 000 ВРМ, 4 NUMA-узла, сервер на 480 логических ядер и APDEX = 0,986 в конфигурации с асинхронной репликой. Но на последнем отрезке пути нас ждали сюрпризы. Один процесс Xorg загружал целое ядро и тормозил тонкие клиенты. INSERT на 15 строк висел больше 20 секунд из-за блокировок BufferMapping. Подключённая реплика заставила rphost съедать вдвое больше памяти и уронила кластер 1С. Рассказываем, как мы с этим справились и что вошло в Postgres Pro Enterprise for 1C 18.6.1.
Тест упал на пятом часу, на переходе с 16 800 до 21 000 ВРМ. Потом запрос, который выполнялся меньше секунды, вдруг стал занимать десятки секунд. После этого отчёт вместо 5 секунд начал строиться 800. Во второй части мы разбираем, как с этим справились: от LWLock:PgStatsHash и сбежавшего плана запроса до гигабитной сетевой карты и 3 миллионов файлов временных таблиц. В итоге на 21 000 ВРМ получили APDEX = 0,975.
Мы провели больше 100 запусков альтернативного теста 1С:ERP от «ИТ-Экспертизы» и дошли до APDEX = 0,986 на 30 000 виртуальных пользователей. Путь был непростым. На 15 000 ВРМ APDEX сначала упал до 0,704, и нам пришлось разбираться с загадочными ошибками PostgreSQL, штормом инвалидаций и перекосом нагрузки по NUMA-узлам. Рассказываем, что именно помогло.
Хижину на высоте 3 930 метров в Кыргызстане пришлось сделать шире, чем в чертежах. Причина простая: матрасы оказались на несколько сантиметров больше, чем рассчитывали. К этому моменту материалы уже лежали на леднике: их привёз вертолёт, а недостающее мы дотаскивали в рюкзаках. Я работаю в Postgres Professional и около двадцати лет хожу в горы. Сейчас вместе с друзьями строю здесь новую хижину для альпинистов. Пока мы утепляем стены и собираем электрику, на ней уже ночуют люди, а по ночам заглядывают куницы. Для них мы закрыли все щели, но куницы всё равно нашли путь.
HAProxy должен выполнять проверки, чтобы определить роль экземпляров PostgreSQL: мастер или реплика, чтобы направлять соединения на подходящие сервера. В статье описываются способы настройки HAProxy для обнаружения переключения ролей экземпляров PostgreSQL через Patroni REST API, через параметр in_hot_standby, передаваемый сервером сразу после аутентификации клиента, или запросом select pg_is_in_recovery(); Два последних способа используются, если Patroni поставлен на паузу или не используется.
Если у вас PostgreSQL с включённым row-level security и ночной pg_dump по таймеру, откройте каталог с бэкапами и сравните размеры вчерашнего и позавчерашнего дампов. Если файлы подозрительно одинаковые и маленькие, возможно, у вас нет ни одного рабочего бэкапа. У нас так было не меньше двух недель.
На прошлой неделе я перенес форк Apache Cloudberry на PostgreSQL 19 в виде набора расширений и рассказал, где этот порт проигрывает оригинальному форку. Впрочем как и Cloudberry на ClickBench современные колоночные движки обгоняют его на порядок. И дело тут не в реализации MPP, а в исполнителе PostgreSQL - он работает с кортежами в памяти СУБД. Каждый кортеж проходит отдельно, значение проходит через fmgr, а сегменты кластера лишь добавляют число процессоров на котором крутится тот же самый цикл по строкам таблицы.
Следующий логичный шаг для ускорения - векторизованный исполнитель в PostgreSQL. В открытом коде Apache Cloudberry его нет: от закрытого движка в репозитарии остались только следы - флаг create_vectorization_plan, который планировщик всегда передает как false, а также узел WindowHashAgg без реализации и адаптер PAX под VEC_BUILD, который не компилируется. Проектировать придется самому и, конечно, снова в виде расширения постгреса. Так появился pg_vexec - набор расширений для PostgreSQL 19.
Проект не требует модификации ядра PostgreSQL даже при использовании планировщика ORCA в одноузловой конфигурации без координатора на ванильной сборке PostgreSQL. Модуль gp_orca из порта Cloudberry теперь собирается без pg_core и прочих потрохов greenplum и патчей ядра СУБД, а vexec превращает ORCA в векторный планировщик с исполнителем в “одном флаконе”: его оптимизатор оценивает стоимости теперь и векторных узлов, а транслятор генерирует эти узлы в плане. Патчи ядра не нужны, только если не нужна функциональность и колоночное хранение данных таблиц из Cloudberry. Если же загрузить расширение Cloudberry на пропатченном ядре постгреса, то vexec может более эффективно читать и писать колоночные PAX и ao_column, без лишних конвертаций из и в строки, а Motion тогда может передавать между сегментами данные сразу в колоночном формате Arrow IPC.
И к постгресу можно подключаться как по привычному pgwire протоколу, так и по более современному Flight SQL, что могут оценить те кто будет запускать ML модели на данных из PostgreSQL. Как минимум при загрузке данных в polars скажут мне спасибо!
В настройках клиента базы стоял statement_timeout в одну секунду, а запрос выполнялся больше сорока. Таймаут выглядел включённым и не действовал. У этой поломки нашлись четыре родственницы. Пулер в тексте ошибки назвала только одна. Остальные выглядели как пропавшая таблица, недоступная база и простой после выката.
