SQL *

Не так давно на моей текущей работе впервые за весь мой немногочисленный 4-летний опыт бэкендера понадобилось для нового микросервиса рассчитывать ресурсы под PostgreSQL для данного сервиса. Раньше для меня данная тема было чем-то, чем занимаются DevOps/DBA и никогда прежде не задумывался и не исследовал информацию о том, как качественно рассчитать необходимые ресурсы, чтобы бизнесу не пришлось переплачивать за очень дорогие железки лишние деньги, чтобы потом оказалось, что от купленных мощностей в реальности используется 20-40% (опыт на нескольких работах показывает, что такое случается ну очень часто).

Q: Для кого эта статья?
A: Да в целом для любых технических специалистов, которые так или иначе взаимодействуют с технической поддержкой PostgreSQL и которым впервые нужно для новой БД (например, под микросервис) и сформулировать задачу для DevOps команды на поднятие СУБД для вашего сервиса.

Q: «Зачем мне это? Ну прикину я на глаз, что здесь нужно 50ГБ диска, 64ГБ RAM и нормально поедет»
A: Очень часто в условиях микросервисной архитектуры используется парадигма database per service и в таком случае нельзя просто запросить максимально мощную виртуальную машину. Ресурсы стоят много денег, инфраструктура должна масштабироваться, а значит необходимо уметь определять, какой именно мощности ВМ требуется и какие параметры PostgreSQL следует задать на старте.

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

tl;dr:

Каждая операция INSERT несет фиксированный overhead (в наших тестах 64–99 ms), независимо от количества строк.

Формула: Total_time = N_statements * fixed_overhead + actual_write_time — подтверждена тестами.

1000 single-row INSERT = 64 секунды (Shared-data) или 100 секунд (Shared-Nothing).

Разница не в диске и не в Docker, а в протоколе commit: TxnLog + publish через BRPC против 2PC + publish_version.

В ANALYZE PROFILE commit overhead прячется в разнице TotalTime - ExecutionTime — это FE overhead.

Батчинг нивелирует разницу: при INSERT SELECT оба режима дают ~0.25 с на 1000 строк.

Работая с MS SQL, я привык воспринимать название Ring Buffer как небольшую структура в памяти, организованную по принципу FIFO overwrite. И чаще всего в контексте Extended Events. Но как-то я встретил упоминание того же Ring Buffer в заголовке статьи про секционирование таблиц! Купился на название, прочёл статью и сохранил себе идею.

В статье описывалось, как Ring Buffer решает задачу ротации данных во времени, которую принято решать с помощью Sliding Window. И я постараюсь передать эту идею так, чтобы после прочтения у вас появился еще один способ решить обычную задачу необычным способом. Не для галочки в резюме, а для рассказов на встречах с коллегами. В моей работе этот подход позволил сделать интересной скучную задачу организации хранения статистики производительности сервера, но может быть использован и для других данных с ограниченным сроком хранения или иначе фиксированным количеством секций. Например, данных аудита.

Здравствуйте, уважаемые читателя Хабра!

В серии статей хочу рассказать о создании основного функционала MVP (Minimum Value Product) системы по управлению цифровыми активами для базы данных PostGIS. В этой публикации рассмотрим как быстро находить одинаковые и похожие по геометрии объекты среди тысячи таблиц и 300 млн записей.

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

Речь идёт о списаниях с баланса пользователей оплаты за мониторинг сайтов в моём Tg-боте. Тариф простой: 1 сайт бесплатно, каждый дополнительный — 2 рубля в сутки.

Пользователь может в любой момент включать/выключать сайты.

Задача в том, чтобы честно считать, сколько сайто-дней набежало за предыдущие сутки, и фиксировать в базе соответствующее списание.

Я сам для себя сформулировал ряд дополнительных требований, которые сильно усложнили код. А уже этот сложный код в комбинации с некоторым дальнейшими обстоятельствами привёл к сумятице в списаниях. Ниже поделюсь своим опытом и выводами.

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

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

В современной разработке мы привыкли решать проблемы производительности стандартным набором инструментов. "База не тянет? Поставь Redis!" — это стало почти рефлексом. Но всегда ли оправдано тащить в инфраструктуру лишний сервис, настраивать сетевые хопы и следить за инвалидацией, если ваша задача — это всего лишь быстрый доступ к небольшому справочнику?

В нашем Open Source проекте BMSTU-ITSTECH/SSO мы столкнулись именно с таким кейсом. И решение оказалось элегантнее, чем просто "поднять Redis". Рассказываю, как мы сэкономили на инфраструктуре и получили мгновенный отклик, используя скрытую мощь PostgreSQL LISTEN/NOTIFY.

Продолжаем цикл статей с обзором изменений 19 версии. Сегодня о ноябрьском коммитфесте 2025 года.

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

Как не потеряться в сотнях графиков и найти реальные рычаги влияния на бизнес? В статье представлен подробный разбор Дерева метрик на примере FoodTech-сервиса (доставки еды). Мы уходим от простого мониторинга цифр к системной декомпозиции North Star Metric.

Как часто бизнес задает вопрос о результатах A/B-теста уже на второй день после запуска? В классической статистике основной ответ: необходимо ждать набора фиксированной выборки, иначе риск ложноположительного результата становится неконтролируемым. Однако современные подходы позволяют не только проводить мониторинг данных без риска математической ошибки, но и останавливать эксперименты значительно раньше срока. В основе такой гибкости лежит методология mSPRT, которая превращает эксперимент из закрытого процесса в прозрачный поток данных.

Вместо пассивного ожидания можно использовать концепцию доверительных последовательностей и всегда валидных p-значений. Эти инструменты сохраняют свою математическую силу независимо от того, как часто проверяются промежуточные итоги. Ключевую роль в настройке системы играет параметр смешивания тау, который помогает найти тонкий баланс между чувствительностью к минимальным изменениям и скоростью получения итогового результата.

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

Такой метод позволяет сократить время проведения тестов на 30-50%, не жертвуя при этом достоверностью. Это способ сделать процесс проверки гипотез более гибким и быстрым, сохраняя безупречную математическую строгость в каждой точке принятия решения.

Третья статья цикла о построении CDC-пайплайна с нуля. Сегодня — самое интересное: захватываем изменения из PostgreSQL и отправляем в Kafka. И разбираемся, почему WAL может съесть весь диск, даже если данные не меняются.

Выделили из production-проекта и открыли в open-source PWA-приложение для персонального фитнес-тренера с AI.

Дисклеймер: это open source, в нем могут быть недостатки, заходите, предлагайте идеи, исправления. Публикую тут в ознакомительных и образовательных целях. Выпилил этот кусок в open source из части личного проекта, о котором писал тут. Весь код писал полностью Claude Code на Opus 4.5 с thinking режимом.

Привет Хабр! Возможно вас, как и меня, первое знакомство с функциональными зависимостями в базах данных повергло в легкий ступор. Длинные определения, которые не давались даже после третьего прочтения, излишняя абстрактность, когда на простые и понятные примеры поскупились, и прочее прелести «научного» подхода к объяснению сложных тем.

Пора раз и навсегда разобраться во всем этом. Тем не менее, я постараюсь не упускать детали и, где это уместно, углубиться в тему с головой. Без претензии на академичность, но с претензией на ясность. Начнем.

Ты изучал SQL в университете, получал пятёрки на экзаменах… а на собеседовании по Data Science сталкиваешься с вопросом про OVER() и думаешь: "Что?! Впервые такое слышу..."
В этой статье я рассказываю, как превратить университетский SQL в инструмент, который реально помогает на собеседованиях.

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

В предыдущей статье мы рассказали, как установить Digital Q.DataBase на Astra Linux 1.8 и начать работу с этой российской СУБД, которая поддерживает нативную работу с диалектами MS SQL, PostgreSQL и Oracle. Сегодня мы поговорим о том, как перенести уже существующие данные в Digital Q.DataBase из других систем управления базами данных. 

Для решения поставленной задачи мы разработали инструмент – Мастер переноса БД. Он позволяет выгрузить структуру, данные и хранимую логику из уже развернутой БД на одной из трех СУБД (Oraсle, MS SQL и PostgreSQL) и загрузить их в Digital Q.DataBase без переписывания кода приложений в отличие от любых миграторов-конверторов.

Стек: Python, Airflow, ClickHouse, Slack

В iGaming падение активности игровых провайдеров почти никогда не выглядит как "обрыв". Чаще это медленное затухание: ставок становится меньше, затем еще меньше, игроки уходят постепенно. Формально провайдер продолжает работать, стандартный мониторинг молчит, а бизнес уже теряет деньги.

Моя задача была не фиксировать факт полного падения активности, а поймать момент, когда траектория уже направлена вниз, но ситуацию ещё можно развернуть.

Вся логика работает внутри DAG в Airflow. Он запускается каждые 6 минут и анализирует активность игровых провайдеров в реальном времени. При обнаружении начала падения или восстановления система отправляет уведомления в Slack.

Привет, Хабр! Сегодня на связи Илья Ищенко, руководитель группы администраторов хостинга Рег.ру и Роман Рогов, старший системный инженер.

В прошлом году мы закончили масштабную задачу — добавили MySQL 8 на все серверы шаред-хостинга с ispmanager. Получилась полноценная инфраструктурная перестройка: с двумя версиями MySQL на одном сервере, прозрачным переключением клиентов и возможностью безопасной миграции.

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

В статье рассматриваются текущие возможности горизонтального масштабирования СУБД для 1С, а также какое решение предлагает Tantor Postgres.

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

Вторая статья цикла «CDC Pipeline в домашней лаборатории». В первой мы сделали Telegram-бота для парсинга банковских скриншотов. Теперь подготовим PostgreSQL к тому, чтобы Debezium мог захватывать изменения в реальном времени.