PostgreSQL *

Официальное предупреждение (дисклеймер)

Настоящая статья подготовлена с использованием технологий искусственного интеллекта.

В частности:

— экспериментальные данные обработаны и проанализированы нейросетью;

— иллюстративный материал, сопутствующие слоганы, а также предисловие и послесловие сгенерированы нейросетью;

— макет статьи редактировался и корректировался нейросетью.

Лицам, придерживающимся позиции «ИИ‑веганства» (испытывающим устойчивый страх, неприязнь или психологический дискомфорт по отношению к нейросетевым системам), настоятельно не рекомендуется ознакомление с содержанием данной публикации, равно как и участие в её обсуждении, во избежание возможного нанесения вреда психологическому благополучию.

// todo: тут N+1 на invoice — надо переделать через entity graph.

Этот комментарий висел в коде полтора года. Все, кто заходил в файл, его видели. Никто не завёл тикет. В пятницу вечером он сработал — и забрал с собой три пода, 30% запросов на критичной ручке и моё спокойствие на выходные.

Каждый разработчик помнит тот самый момент, когда система, которая только что работала идеально, вдруг начинает вести себя так, будто сошла с ума. Когда дашборд в Grafana показывает что-то страшное, а ты стоишь перед ним с кружкой остывшего кофе и не понимаешь, с чего начать.

На нашем мероприятии Avito Go Loto разработчики поделились своим опытом без прикрас. О блоате в полтора терабайта, о девяти инстансах, которые передрались за один звонок, о бэкенд-разработчице, которая в пятницу вечером открыла чужой фронтовый проект, о нагрузочных тестах за несколько месяцев до большой рекламной кампании, и о транзакции, которую забыли закоммитить тоже в пятницу вечером.

Спойлер: все выжили. Но стали другими людьми.

Сначала всё выглядело как типичная AI-история успеха.

За пару вечеров LLM помогла превратить Google Sheets для учёта финансов в настоящее приложение. Потом появился backend, sync между устройствами, mobile-first UX, AI-рекомендации, rollback, conflict resolution, миграции, Docker images, golden tests и React-компонент на 10 537 строк.

Оказалось, что AI действительно радикально ускоряет старт разработки. Но production начинается сильно позже демки.

Лучший инструмент 1С эксперта по технологическим вопросам это голова. Подготовка к 1С:Эксперту по технологическим вопросам. Основной курс©

Удар был нанесен тупым предметом, очевидно головой (из милицейского протокола) ©

Из тех кто не собирается стать тимлидом (а возможно и из них тоже) 1С-ники делятся на тех кто собирается идти на экзамен 1С:Эксперт по технологическим вопросам и те кто собирается идти еще раз на экзамен 1С:Эксперт по технологическим вопросам.
Тем из них, кто в очередной раз поклялся за лето/отпуск переделать домашки курса

В SQL самые опасные ошибки часто выглядят как рабочие запросы. Они не падают, не ругаются на синтаксис и не подсвечиваются в IDE — просто возвращают пустоту там, где должны быть данные.

В этой статье разберём классическую ловушку NOT IN: почему один NULL в подзапросе может «отравить» всю выборку, чем IN на самом деле отличается от NOT IN и почему в таких случаях безопаснее писать через NOT EXISTS.

Провести честный тест на 30 000 ВРМ, сжечь 400 тысяч процессорных ядер-часов и доказать, что отечественная связка из RED OS, 1С и Postgres Pro Enterprise способна стабильно держать промышленную нагрузку в 1 Тб — выполнено. Рассказываем историю одного большого нагрузочного тестирования длиною в три месяца

Оператор OUTER JOIN — бич конфигураций 1С на базе PostgreSQL: планировщик пока небогат на оптимизации такого типа соединений. В то же время ORM-фреймворки — и 1С как яркий их представитель — часто генерируют внешние соединения по типовым шаблонам, что открывает возможности для точечной оптимизации.

В этой статье я разбираюсь с одним из таких шаблонов — разрешением полиморфных ссылок: что это за паттерн, откуда он берётся (Rails, Django, Hibernate, Salesforce — не только 1С), насколько он распространён и почему его структурные особенности позволяют существенно ускорить выполнение.

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

SUM() OVER (ORDER BY ...) часто выглядит как очевидный способ посчитать нарастающий итог, пока в данных не появляются одинаковые значения ключа сортировки. В этот момент результат начинает «прыгать», LAST_VALUE возвращает текущую строку, а запрос формально остаётся корректным.

В статье разбираем скрытую причину таких сюрпризов — кадр оконной функции: как база подставляет его по умолчанию, чем ROWS отличается от RANGE и какие детали стоит проверять, чтобы аналитические SQL‑запросы считали именно то, что вы ожидали.

Меня зовут Ирек Агмалов, я DBA-SRE в Ви.Tech - IT-дочке ВсеИнструменты.ру.

Мы обновляли PostgreSQL в кластере Patroni и хотели переключить приложение на новую версию без смены строки подключения и без долгого простоя.

Для роутинга у нас уже использовались consul-dns и Patroni, поэтому вместо замены DSN мы попробовали временно взять переключение трафика на себя через записи в Consul. В статье покажу, как перевели реплику на PostgreSQL 18, сохранили синхронизацию через логическую репликацию и переключили master и replica так, чтобы потом вернуть кластер в нормальный режим работы.

Каждый раз, когда пользователь открывает страницу каталога или дашборд со статистикой, база данных заново считает одно и то же. Запрос к 800 тысячам строк ради одного числа — снова и снова. Расширение pgpro_result_cache в Postgres Pro Enterprise решает эту проблему на уровне СУБД: результат тяжёлого запроса сохраняется в разделяемой памяти и при повторном обращении возвращается за миллисекунду — без сканирования, без нагрузки на процессор, прозрачно для приложения. В этой статье разберём, как это работает, когда кэш действительно полезен и на что нужно обратить внимание при настройке.

Уже совсем немного осталось до выхода релиза СУБД Tantor Postgres 18, и мы хотим наперед рассказать о его новых возможностях для работы с приложениями на платформе "1С:Предприятие". В обзоре разберем улучшения планировщика, по традиции коснемся работы временных таблиц и не обойдем вниманием вспомогательные утилиты, которые упрощают поиск и диагностику проблем в высоконагруженных системах. За каждым пунктом - реальные запросы 1С, реальные рабочие базы и сотни часов тестирования!

В предыдущих частях серии мы разобрали, как читать планы выполнения через EXPLAIN ANALYZE, и научились автоматически ловить медленные запросы с помощью pg_stat_statements, auto_explain и log_min_duration_statement. Теперь — следующий шаг: что делать с проблемами, которые вы нашли.

В этой части разбираем три рычага оптимизации: статистику планировщика, индексы и рефакторинг SQL‑запросов. На демонстрационном примере покажем, как снизить стоимость запроса почти вдвое — без изменений в инфраструктуре.

Оборудование, конфигурация сервера и схема БД тоже влияют на производительность, но остаются за рамками статьи — здесь сосредоточимся на том, что можно улучшить на уровне запросов.

Официальное предупреждение (дисклеймер)

Настоящая статья подготовлена с использованием технологий искусственного интеллекта.

В частности:

— экспериментальные данные обработаны и проанализированы нейросетью;

— иллюстративный материал, сопутствующие слоганы, а также предисловие и послесловие сгенерированы нейросетью;

— макет статьи редактировался и корректировался нейросетью.

Лицам, придерживающимся позиции «ИИ‑веганства» (испытывающим устойчивый страх, неприязнь или психологический дискомфорт по отношению к нейросетевым системам), настоятельно не рекомендуется ознакомление с содержанием данной публикации, равно как и участие в её обсуждении, во избежание возможного нанесения вреда психологическому благополучию.

Запутались в многоэтажных SQL‑запросах? Обобщённые табличные выражения (CTE) — тот инструмент, который превращает лапшу из JOIN и подзапросов в читаемый, модульный код.

Разберем на реальных примерах из FinTech и e‑commerce, как разбивать сложную логику на цепочку простых шагов, использовать CTE в UPDATE/DELETE, строить рекурсии для иерархий и избегать ловушек оптимизатора в PostgreSQL.

В логистике проблема часто не в том, что нет данных.

Проблема в том, что данные разбросаны по разным местам.

Одни заявки лежат во внутренней системе, другие — в закрытых кабинетах грузоотправителей, третьи — на тендерных площадках, четвёртые приходят через Excel‑выгрузки, пятые доступны только через веб‑интерфейс. Где‑то есть нормальный HTTP‑обмен, где‑то данные спрятаны за фронтендом, где‑то приходится читать DOM‑таблицу, а где‑то сначала кажется, что всё просто, пока не выясняется, что цена приходит в копейках, маршрут состоит из трёх точек, а тип кузова записан как «тент 20т, верхняя загрузка».

Для менеджера всё это выглядит не как единый рынок грузов, а как набор вкладок в браузере.

Открыть один кабинет. Потом второй. Потом третий. Проверить направление. Сравнить цену. Посмотреть дату. Понять, где реф, где тент, где просто «20 тонн». Не забыть про аукцион, у которого скоро истекает время. Потом всё равно перенести результат в таблицу или открыть внутреннюю панель.

В какой‑то момент стало понятно: нам нужен не ещё один парсер, а единая витрина.

Так появился внутренний агрегатор заявок — условный «Авиасейлз для логистики».

Юнит-тесты в PostgreSQL, как и в других базах данных, не являются обязательными для CI/CD, но они крайне важны и фактически становятся стандартом. С помощью этих юнит-тестов мы уже нашли и исправили много ошибок в функциях на уровне БД, а также сократили загрузку ручных тестировщиков.

Привет, Хабр! В этой статье мы, старший разработчик Анастасия Цацкина и старший инженер-тестировщик Владимир Белинский из IBS, расскажем о нашем опыте внедрения юнит-тестирования на уровне БД.

Эта статья совсем не технический анализ, а увлекательный рассказ о том, как маленький, но очень перспективный стартап стал топовым приложением, а также о том, какие сложности встали на пути команды разработки, DevOps и тестирования X5 Tech.

Мы сразу заложили основные принципы нагруженного приложения: микросервисы как основа всего, полное покрытие метриками, асинхронность, кэширование на максималках. Какую-то функциональность разрабатывали сами, где-то задействовали сервисы других техкоманд из X5, а где-то и сторонние решения с рынка.

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

Мне пришла задача на исследование — выбрать хранилище для промышленной телеметрии. Я раньше с таким вообще не работал. Ни с временными рядами, ни с реактивным программированием, ни с WebSocket. Работал только с Postgres.

Слышал про Redis, но не применял. На выбор — SQLite или Redis, надо исследовать что лучше. Пошёл читать. Нашёл TimescaleDB и ещё кучу вариантов — у каждого свои плюсы.

Основной плюс SQLite — там можно писать запросы, SQL знакомый, Spring интеграция есть. Скорость записи меня вообще удивила — и у Redis, и у SQLite. Я не ожидал таких цифр.

Долго не мог понять зачем вообще Redis, если там нет нормального поиска. Просто хэши ключ-значение. Хочешь найти все датчики по типу объекта — не работает. Я такой: ладно, Redis минус, берём SQLite.

Сделал прототипы. Потестировал один поток — SQLite летит, 370 000 вставок в секунду. Redis ещё быстрее — 650 000. Нашёл RediSearch с поиском по индексам — оч круто, но скорость падает до 150 000. SQLite снова выглядит выигрышнее.

И вот я запускаю 100 потоков на SQLite.

В логах появляется:

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

В теории все выглядит аккуратно: берем фото, считаем embedding, ищем ближайшие вектора, возвращаем совпадения. На практике начинаются нюансы: у товара несколько изображений, ракурсы отличаются, фон мешает, каталог обновляется постоянно, а бизнес ждет не исследовательский прототип, а сервис, который можно поставить в production.

С вами старший программист в Fix Price Константин Репин. И в этом материале разберу, как мы строили сервис визуального поиска товаров, какие инженерные решения реально повлияли на качество и почему текущий результат в 98% совпадений получился не из-за одной удачной модели, а из-за правильно собранного пайплайна.