SQL *

Вы храните в PostgreSQL пользователей, заказы и платежи — а потом проект обрастает Redis для очереди, отдельным поисковиком и самодельными блокировками через таблицу locks. Иногда это оправдано. Но часто типовые бэкенд-задачи закрываются прямо в базе: атомарно, транзакционно, с индексами и без лишней сетевой болтовни.

Привет, Хабр! Меня зовут Тимур Исламгулов. Я преподаватель МФТИ и ведущий вебинаров по PostgreSQL. За годы работы я насмотрелся, как разработчики поднимают лишнюю инфраструктуру там, где хватило бы самой базы, — об этом и поговорим.

Выискивать архитектурные несоответствия вручную при проверке чужих проектов неэффективно. Проблема решилась написанием легковесного скрипта автоматизации на Python.Утилита работает на чистом SQL, подключается к живой бд и мгновенно вытаскивает наружу скрытые дефекты проектирования.

Детская футбольная школа имеет базу данных детей и их родителей, в которой более 7000 уникальных записей. На данный момент посещаемость, продление абонементов и напоминания об оплате происходять в ручном режиме через ERP‑систему.

Проблема: Администраторы тратят много времени на проверку платежей и ручную рассылку с напоминаниями об оплате родителям. Из‑за различных причин часть родителей не оплачивают абонемент на следующий месяц вовремя, что существенно снижает выручку школы.

Цель работы: Автоматизировать процесс контроля оплаты и отправки уведомлений, связав интеграцию ERP‑системы с платежным шлюзом и СМС‑провайдером для увеличения выручки школы.

Проектирование процессов и API‑контракта:

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

Схема взаимодействия систем / UML Sequence Diagram

AngaraBase — OLTP/HTAP СУБД, написанная с нуля на Rust. Совместима с PostgreSQL по протоколу — работает с psql, JDBC, psycopg2 и стандартными драйверами. UNDO-log MVCC без VACUUM, векторизованный исполнитель с SIMD-батчами — транзакции и аналитика под одним SQL и одним снапшотом, без ETL и второго хранилища. Fail-closed контракты ресурсов, USDT-пробы без рестарта, EXPLAIN с разбивкой по фазам исполнения. Dev preview доступен на angarabase.dev.

Если вы когда-либо преподавали SQL или проходили курс по базам данных, то почти наверняка встречали Sakila — маленькую базу данных видеопроката, которая вот уже почти двадцать лет служит эталонным примером в туториалах по MySQL и MariaDB. Схема чистая, нормализованная, данных достаточно для интересных запросов.

Проблема в другом: Sakila спроектирована в 2006 году под MySQL 5.0.

С тех пор многое изменилось.

TL;DR: я сделал sqlalchemy-query-manager — небольшой слой поверх SQLAlchemy для типовых backend-запросов. Он не заменяет SQLAlchemy, а добавляет более компактную запись для частых операций: фильтры в стиле number__gte=100, условия через Q, фильтрацию по связанным моделям, eager loading, CRUD helpers, агрегаты и просмотр итогового SQL. Идея в том, чтобы оставить SQLAlchemy в основе, но убрать повторяющийся код там, где запросы становятся слишком большими.

Когда мы выпустили Auto Embeddings — функцию автоматического преобразования текстов в векторные представления — без развёртывания отдельного сервиса для работы с ML-моделью, — главный запрос пользователей касался скорости работы. Ранее для генерации эмбеддингов использовался только стек SentenceTransformers поверх Candle (Rust-рантайм Hugging Face для ML-инференса), и ресурсы CPU использовались далеко не полностью: в большинстве сценариев нагрузки показатель QPS держался на уровне нескольких десятков документов в секунду независимо от способа подачи данных, а параллельные запросы обрабатывались последовательно в рамках одной сессии модели.

Поэтому мы в течение нескольких недель оптимизировали механизм запуска ONNX-моделей в Manticore. Новый бэкенд ONNX Runtime доступен начиная с Manticore Search 27.1.5 . ONNX (Open Neural Network Exchange) — переносимый формат моделей, в котором уже публикуется большинство популярных open-source моделей для эмбеддингов: MiniLM, BGE, E5 и другие. В результате получилось решение, которое в среднем в 14 раз быстрее прежней реализации SentenceTransformers/Candle на том же оборудовании (обычный недорогой сервер с 16 ядрами / 32 потоками), с той же моделью и теми же весами, если усреднить по всей матрице замеров threads × batch, — и это преимущество сохраняется как при одном клиентском потоке, так и при тридцати двух. Предыдущая реализация во всём диапазоне нагрузок показывала 5–11 документов/с; новая реализация работает в диапазоне 70–230 документов/с.

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

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

Многие из backend-разработчиков получали ошибки с неприятным содержанием, суть которого можно описать двумя словами: deadlock detected. Эти ошибки коварные. Возникают они там, где их не ждёшь, отладочной информации крайне мало или вообще нет, и для их решения необходимо глубокое понимание архитектуры как самого запроса и метода, из которого он вызвался (или методов, возможно, чужих...), так и архитектуры самой СУБД. Поэтому часто у таких ошибок либо переносится срок, либо попытки их исправить приводят к тому, что они возвращаются снова и снова. А deadlock-и так никуда и не исчезают...

Когда у каждого репозитория есть свой Tx, код может выглядеть чисто, но атомарность всё равно сломается: один Store откатится, другой уже успеет закоммитить изменения.

В статье показан более надёжный вариант для Go-кода: репозитории остаются небольшими интерфейсами, транзакционная логика уезжает в Unit of Work, а сервис работает с готовым набором хранилищ, построенных поверх одного sql.Tx.

Сегодня разберемся, что такое кросс-фильтрация в Apache Superset и какую неожиданную опасность она может нести.

В менеджерской среде есть изречение: «Управлять можно только тем, что можно измерить». Рискнем его дополнить — данных сейчас генерируется так много, что одного измерения уже мало: «…а эффективно управлять — лишь когда результаты измерений представлены наглядно». В предыдущих статьях про адаптивное администрирование Sigla Vision мы описывали, как собирать данные об изменении объектов BI-системы. Теперь покажем, как представить эти данные наглядно, и приведем примеры наших дашбордов — мы назвали их «системными», чтобы отличать от пользовательских.

Статья пригодится BI-разработчикам и ИТ-специалистам, которые развивают или сопровождают Sigla Vision и другие BI-системы.

Здесь мы разбираем, как системные дашборды помогают решать задачи администрирования Sigla Vision, и прикладываем код для PostgreSQL, который готовит таблицы-источники датасетов для комплексного дашборда «Состояние системы». В нем можно отслеживать, как меняются во времени количественные показатели по объектам: дашбордам, подключениям, ролям, пользователям, рабочим книгам, элементам корзины и т. д.

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

Меня зовут Жуйков Андрей, в Диасофт я занимаюсь развитием и продвижением СУБД Digital Q.DataBase.

Импортозамещение СУБД перешло из разряда регуляторных требований в практическую плоскость: компаниям нужно менять платформы без остановки бизнеса. Типичная проблема — огромная экосистема вокруг MS SQL, PostgreSQL или Oracle с тысячами процедур, отчетов и интеграций. Ручной перенос такого объема (например, 900 тысяч строк кода) занимает месяцы и несет риски, при этом даже автоматизация не исключает доработок.

Даже с автоматизированными средствами конвертации большинство проектов миграции СУБД требует доработок и тестирования, поэтому ключевым требованием становится сохранение существующей логики приложений. Digital Q.DataBase решает эту задачу через воспроизведение функциональности популярных СУБД и поддержку их диалектов SQL, что позволяет переносить системы быстрее без масштабной переработки прикладного слоя.

В новой версии Digital Q.DataBase существенно переработана архитектура продукта. Вместо единого монолитного решения СУБД получила независимые модули, воспроизводящие функциональность PostgreSQL, Microsoft SQL Server и Oracle Database. Это упрощает установку, сопровождение и обновление системы, а также позволяет использовать только те компоненты, которые действительно необходимы в конкретном проекте.

В этой статье покажу, как установить Digital Q.DataBase 18.2 на Astra Linux 1.8, познакомлю с новой архитектурой продукта и продемонстрирую подключение к каждому из поддерживаемых диалектов.

Продолжаем проводить конкурc SQL в рамках «IT-Планеты 2026». Как обычно во втором этапе участникам было предложено решить пять задач на чистом SQL. Перейдем к рассмотрению задач.

Привет, Хабр! Я — Дмитрий Селищев,  в компании «Синимекс» совмещаю роли руководителя подразделения и разработчика баз данных. В этом материале хочу поделиться историей о том, как простые, но не всегда очевидные приемы помогают кардинально ускорить SQL-запросы. Мы поговорим о стандартных конструкциях CASE и FILTER, которые позволяют писать более чистый код и, что важнее, на порядки сокращать время построения сложных отчетов. Давайте на живых примерах посмотрим, как это работает.

4 июня 2026 вышла PostgreSQL 19 Beta 1. Все пишут про графовые запросы SQL/PGQ, но главная операционная новость в другом: в ядро завезли команду REPACK с неблокирующей опцией CONCURRENTLY — перепаковку раздутых таблиц без ACCESS EXCLUSIVE lock и без внешнего pg_repack. Разбираю по официальному анонсу и release notes: как это работает (спойлер — через слоты репликации, отсюда max_repack_replication_slots), чем отличается от VACUUM FULL и pg_repack, и что именно стоит прогнать на staging до GA — дисковый оверхед, documented-ограничения (команда не MVCC-safe!), бюджет слотов. Плюс честный разбор SQL/PGQ: GRAPH_TABLE убирает отдельный Neo4j для связей фиксированной глубины, но обходы переменной длины в бете пока не поддерживаются. Без ‘я проверил в проде’ — beta в прод не ставят.

Новая статья из цикла про нашу OLTP-СУБД на Rust.

С самого начала мы выбрали MVCC на UNDO-логе вместо версионирования в heap, как в PostgreSQL. И годами повторяли свой же лозунг: «нет VACUUM, нет bloat». Оказалось, это правда ровно наполовину.

Heap и правда не пухнет от истории версий. Но bloat никуда не делся: он переехал в индексы, в мёртвые слоты и в сам UNDO-лог. А сборка мусора из одного механизма незаметно превратилась в пять, и мы только сводим их к единому координатору.

В статье разобрали без прикрас обе стороны. Что UNDO-модель дала: стабильный TID (UPDATE, который не трогает индексы), rollback пропорционально размеру транзакции, аналитику, не дорожающую от write-нагрузки, и AS OF как «машину времени» почти даром. И чем за это платим: главная эксплуатационная цена это долгоживущий снапшот, который молча останавливает очистку для всех.

Вопрос к тем, кто эксплуатировал MVCC-базы под нагрузкой: что меньшее зло — блокировать GC ради долгих транзакций или отдавать «snapshot too old»? Любопытно ваше мнение в комментариях.

Всем привет. На связи Дмитрий Немчин из Т-Банка. Снова буду говорить про Greenplum, но в необычном контексте.

С 2015 года занимаюсь Greenplum: развитием, эксплуатацией, автоматизацией и всем, что обычно появляется вокруг большой аналитической платформы. Когда я пришел, у нас было два production-кластера Greenplum и десятки терабайтов данных. Сейчас production-кластеров около 20 и объемы данных измеряются петабайтами. За это время Greenplum прошел путь от небольшого DWH до центра крупной Дата Платформы. И сейчас это система, которая все еще держит большую часть нагрузки, но постепенно перестает быть точкой будущих инвестиций. 

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

В статье хочу разобрать переход на примере Greenplum: что я называю legacy, почему технология начала ограничивать следующий этап роста, какие варианты были у команды и что происходит с людьми, когда привычная система постепенно уходит из фокуса развития. 

Всем привет! Меня зовут Иван Привалов, я разработчик в команде BI Авито Финтеха и в этой статье расскажу, как мы сделали FIFO-сопоставление между N начислений и M списаний для бонусов. Заодно покажу подвох, без которого SQL быстро превращался в тыкву.

Статья будет полезна аналитикам и data-инженерам уровней мидл+, которые работают с финансовыми данными в Trino, Presto и Spark SQL.

JOIN - крайне популярная операция в SQL, о которой еще и спрашивают на 99% собеседований на программиста. Но когда начинаешь впервые разбираться с ней, то постоянно путаешься, какие таблицы соединять и когда именно.

В этой статье простыми словами и с великолепной графикой расскажу, что такое JOIN в SQL, что такое Foreign Key, какой тип JOIN когда использовать - INNER или OUTER - и зачем вообще.