Привет, Хабр! Меня зовут Кирилл Абрамов, я backend-инженер в сервисе Автотека Авито. В этой статье я расскажу, как остановил постоянное увеличение объёма базы данных PostgreSQL и что надо делать, если времени на остановку не остаётся.
За прошедшие две недели я узнал, что сначала Anthropic, а потом Open AI запустили программы поддержки open source проектов: Claude for Open Source и Codex for Open Source. Я подал заявку в обе программы со своим open source проектом и мои заявки одобрили.
Какие были требования, что это даёт и как я буду применять новые инструменты — ниже.
В горнодобывающей промышленности точный учёт рейсов карьерных самосвалов — ключевой фактор управления производительностью. Традиционные системы диспетчеризации (DISPATCH от Modular Mining, Wenco, российская «Карьер») опираются на GPS-зоны: система фиксирует въезд самосвала в зону экскаватора или пункта разгрузки и по факту пересечения геозон формирует рейс. Однако этот подход не улавливает аномалии внутри цикла — простои, заторы, сбои датчиков, затянувшиеся обеды — и не позволяет классифицировать тип рейса по его «форме».
Альтернативный подход реализован в системе «Симуляция и детекция рейсов» — серверно-клиентском приложении (Go + React + PostgreSQL), которое распознаёт рейсы в реальном времени путём шаблонной векторизации телеметрических данных скорости и веса. Вместо привязки к координатам система строит вектор из скользящего окна телеметрии и сравнивает его с заранее сохранёнными эталонными шаблонами через меру сходства (косинусное сходство или нормы L1/L2). Когда степень совпадения превышает порог — рейс считается обнаруженным.
Данная статья детально разбирает архитектуру, алгоритмическую основу и инженерные решения этого подхода, сопоставляя его с мировой практикой детекции рабочих циклов тяжёлой техники.
Договоримся о терминах:·
*Шардинг БД (db sharding) — это метод горизонтального масштабирования, при котором большая база данных разбивается на более мелкие, независимые части (shards), размещаемые на разных физических или виртуальных серверах. Каждый шард содержит подмножество данных, что снижает нагрузку на отдельные узлы, ускоряет запросы и позволяет хранить большие объемы информации, преодолевая ограничения вертикального масштабирования
**Read consistency (согласованность чтения) в БД — это гарантия того, что транзакция видит согласованное состояние данных, соответствующее определенному моменту времени (обычно моменту начала транзакции или запроса).
Привет, Хабр! Меня зовут Ибрагим и я бэкенд-разработчик в команде, которая разрабатывает C2C-площадку в Wildberries — раздел, где пользователи могут продавать друг другу товары через объявления. За каждым объявлением и заказом стоит набор данных, который аналитики используют для отслеживания метрик платформы: жизненный цикл объявлений, конверсии, статусы заказов.
Чтобы эти данные попадали в ClickHouse к аналитикам, нам нужна была надёжная синхронизация из PostgreSQL. Долгое время она работала через polling-сервис — и какое-то время нас это устраивало. Но по мере роста платформы проблемы стали проявляться всё чаще: данные терялись, лаг репликации достигал нескольких минут, а нагрузка на базу росла вместе с объёмами.
Когда проблема стала достаточно ощутимой, мы с тимлидом начали смотреть в сторону CDC — он подсветил Debezium как подходящий инструмент, я взял реализацию на себя: написал Go-сервис, развернул всю инфраструктуру локально и протестировал. Далее описал девопсам всю схему и мы развернули инфраструктуру на виртуалках. В этой статье расскажу, что из этого вышло.
В исходниках PostgreSQL встречаются ироничные комментарии, а самый веселый, на мой взгляд, находится в строке прямо перед запуском сервера. Судя по логам Git, это комментарий Тома Лейна, который сообщает: "We are ready to rock and roll", а следующей строкой идёт запуск сервера СУБД. Действительно, когда пытаешься запустить кластер PostgreSQL, порой не покидает ощущение "rock and roll", а потом вдруг кластер не стартует или внезапно переключается на другой узел из-за отступов в YAML-конфиге :).
В этой статье разберём ключевые элементы отказоустойчивого кластера и типовые места, где чаще всего допускают ошибки.
Управляемые блокировки в 1С. Механизм выглядит простым (объект БлокировкаДанных, три метода — добавить, установить значение, заблокировать), а на практике поведение отличается от ожидаемого настолько, что в типовых конфигурациях до сих пор находят ошибки, связанные с блокировками.
В PostgreSQL есть фича, про которую знают далеко не все, хотя она существует с незапамятных времён. Advisory locks — пользовательские блокировки, которыми управляет не БД, а ваше приложение. PostgreSQL только хранит их состояние и разруливает конкуренцию. А вы решаете, что именно заблокировать и когда отпустить.
Зачем это нужно? Вы строите распределённую систему, несколько инстансов приложения работают с одной базой, и вам нужно гарантировать, что определённую операцию выполняет только один инстанс одновременно. Классический ответ — Redis с SETNX или Consul/ZooKeeper. Но если у вас уже есть PostgreSQL — зачем тащить ещё одну зависимость?
Привет, Хабр!
Меня зовут Андрей Жуйков, и в этой статье я хочу рассказать вам историю абсолютно практического содержания. Без теоретических рассуждений и без лозунгов про импортозамещение. Это реальный кейс о том, как мы перевели несколько наших корпоративных 1С с Microsoft SQL Server на Digital Q.DataBase.
Бывают ситуации, когда есть список значений, и нужно найти значения, которых нет в БД. Прямым SQL-запросом найти отсутствующие значения невозможно, так как из базы нельзя получить значения, которых там нет. В статье рассмотрим какие есть замены временным таблицам в SQL.
После первой статьи в комментариях несколько раз прозвучало примерно одно и то же:
"Всё правильно, но это же про любую зрелую СУБД — что с этим делать?"
Я думал над этим вопросом несколько недель. И в итоге решил не искать ответ в виде
"возьмите правильный инструмент X" — а попробовать честно сформулировать:
какими свойствами OLTP-БД должна обладать сама по себе, независимо от того,
насколько хорош ваш оператор, консультант или runbook.
Что такое "контракт" — и почему это не маркетинг
Попробую объяснить не через определение, а через ощущение.
Когда вы покупаете автомобиль, вы не читаете инструкцию к тормозам каждое утро.
Вы просто знаете: нажал педаль — машина тормозит. Это контракт. Он не зависит от того,
правильно ли вы настроили тормозную жидкость этим утром или не забыли включить
"режим торможения" в меню.
Создать реплику PostgreSQL на базе в 1 TiB — задача, где быстро выясняется, что NVMe и сеть в 75 Гбит/с сами по себе ничего не гарантируют: упираешься в инструмент, который копирует данные в один поток. В статье разбираемся, как обойти этот потолок с помощью pgBackRest и параллельной передачи, какие настройки реально влияют на скорость, где легко потерять порядок величины на «мелочи» вроде хранилища под spool, и почему в PostgreSQL 18 внезапно стало лучше — но недостаточно.
Практическое применение статистического анализа производительности СУБД с использованием pg_expecto v.7: разбор инцидента и верификация гипотез
GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL
GitFlic - pg_expecto - статистический анализ производительности и ожиданий СУБД PostgreSQL
Глоссарий терминов | Postgres DBA | Дзен
Целесообразность применения нейросети DeepSeek для анализа статистических данных и подготовки рекомендаций по итогам инцидентов обусловлена ограниченностью традиционных методов нагрузочного тестирования, нерелевантных в условиях стохастических пиковых нагрузок промышленных систем. В рамках настоящей работы на базе инструментария pg_expecto v.7 продемонстрирована эффективность перехода к статистическому анализу инцидентов PostgreSQL: от идентификации критических факторов до верификации гипотез оптимизации. Использование DeepSeek обеспечивает математически обоснованные выводы о причинах деградации производительности, что подтверждает высокую эффективность данного подхода для оперативной диагностики и повышения отказоустойчивости информационных систем.
СУБД PostgreSQL давно закрепилась в топе благодаря открытости, надёжности и расширяемости, однако ее архитектурный консерватизм порождает ряд нерешённых проблем: отсутствие горизонтального масштабирования, деградация при тысячах соединений, узкое место WAL при высоком commit rate, невозможность полноценной HTAP-обработки и другие.
В статье рассказываем как в новом, третьем поколении машин баз данных Tantor XData Gen3 эти ограничения преодолеваются через глубокую переработку архитектуры — от полного разделения Compute и Storage с протоколом RDMA и распределённой файловой системой PFS до внедрения механизмов CSN для MVCC без блокировок, конвейерной обработки WAL и встроенного MPP‑движка, превращающего PostgreSQL в систему, способную конкурировать с Oracle Exadata уже по‑настоящему. И все это — со 100% сохранением совместимости с «обычным» PostgreSQL.
Ещё в 1987 году Майкл Стоунбрейкер в основополагающем документе «The Design of POSTGRES» написал, что транзакции должны быть 64-битными. Прошло почти 40 лет — и Postgres до сих пор живёт в мире 32-битных счётчиков. Но в декабре 2025 года в кодовую базу тихо вошёл мой коммит, который стал первым реальным шагом к тому, о чём думал Стоунбрейкер. Расскажу, что именно изменилось и почему это важнее, чем кажется.
Странный вопрос, в column_default таблицы information_schema.columns.
Казалось бы вопрос закрыт, но что произойдёт когда мы удалим дефолт с колонки?
Как известно, начиная с 11 версии postgresql, при добавлении новой not null колонки со значением по умолчанию, физически не меняет данные в таблицы. Просто в момент чтения старых данных возвращает указанное значение. Но что произойдёт если удалить дефолт?
Я тоже удивился тому, что not null колонка может возвращаться null и провёл небольшой эксперимент
«Поднятие» унаследованного Postgres без специнструментов быстро превращается в головную боль: вас ждет ручной разбор схем, перелопачивание десятков таблиц и прочая невеселая археология - где лежат персональные данные, что за колонки, как это всё соотносится с 152-ФЗ… Один неверный шаг – и можно запросто упустить что-то важное. Встроенного защитного преобразования данных на диске нет, приходится либо городить огород на уровне приложений, либо создавать триггеры. Хранить ключи, тестировать производительность, поддерживать это всё, руками выставлять фильтры, думать, куда писать логи, как следить за аномалиями и так далее. Всё, что связано с безопасностью – проверять вручную. Любое изменение схемы — снова садись и аудируй заново. Времени уходить будет очень много, и неизвестно, какие грабли вылезут.
В СУБД Tantor Certified то, что обычно делается на коленке, превращается в понятный и безопасный процесс, который подробно описывается в статье.
Как я написал радар межбиржевых спредов на Python и понял, почему 90% публичных ботов считают прибыль неправильно
В этой статье мы разберём, как PostgreSQL обрабатывает запросы, изучим работу планировщика запросов и освоим анализ отчётов EXPLAIN ANALYZE — важнейшего инструмента оптимизации запросов. Эти знания помогут вам находить и устранять узкие места в производительности, оптимизировать запросы и предотвращать проблемы, из-за которых СУБД может работать медленнее.
Реализуем сервис семантического поиска на базе PostgreSQL с расширением PGVector. В статье: настройка БД через Docker, миграции Alembic, асинхронный слой на SQLAlchemy и API на FastAPI. Иллюстрация на обложке - нейрослоп для привлечения внимания
