SQL *

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

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

Как ускорить Hash Join в PostgreSQL, отбросив 99% строк ещё до самого соединения? Рассказываем о фильтре Блума в СУБД Tantor Postgres на живых и синтетических примерах.

Читатели хабра знают меня как автора статей о django. Например, в предыдущем посте я писал о том, как собирался переписывать django на async/await. Кстати, первые эксперименты подтвердили, что подход рабочий, и что django отлично поддаётся переписыванию. А также - что он хорошо расширяем и содержит код высокого качества.

Однако, я пришёл к выводу, что несмотря на эти достоинства, django сильно уступает Pony ORM, которая, в отличие от django и других ORM, ещё и спроектирована правильно - способом, дружественным к оптимизациям. Не случайно в статьях, которые есть о ней на хабре, её хвалят именно за производительность.

В этой статье речь пойдёт о Pony ORM, но не о фичах для пользователя, которых много (о которых можно узнать в этих видео 1, 2), а о её внутренней архитектуре.

Giga4DQM — открытый проект, реализующий концепцию ИИ-агентов для автоматизированного расследования инцидентов с данными и построения целостной картины зависимостей в существующей БД. Система понимает вопросы на естественном языке, самостоятельно анализирует структуру базы, строит граф зависимостей и формирует диагностические запросы. Архитектура не привязана к одной СУБД: в качестве примера взята PostgreSQL, но подход может быть адаптирован к любой системе с развитым каталогом метаданных. В основе — мультиагентная архитектура на основе GigaChat и LangGraph. Код открыт, доступен для тестирования и внедрения.

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

Меня зовут Илья Новиков, я технический директор компании «Исходный код».

Ранее карточки артистов создавались автоматически на основе заявок на выступления. Поначалу это казалось вполне приемлемым: артист подает заявку, система создает карточку, администраторы могут с ней работать.

На практике мы получили кучу дубликатов. В некоторых записях был один и тот же адрес электронной почты. В некоторых — один и тот же номер телефона. Некоторые были связаны и тем, и другим, но не всегда напрямую.

Для команды, которой приходилось администрировать эту базу данных и координировать выступления, это стало настоящей проблемой. Стало непонятно, какая карточка артиста является подлинной, где хранится история бронирований и какую запись следует использовать для дальнейшей работы.

Правильное решение — предотвращать появление дубликатов до того, как они попадут в систему. Я с этим согласен. Регистрация должна проверять данные, нормализовать контакты и проверять, существует ли человек уже в системе.

Нам этого было недостаточно. У нас уже были производственные данные, производственные пользователи и производственный беспорядок. Нам нужно было перестраивать систему в процессе работы.

Я закинул бюджет в Telegram-рекламу своего pet-проекта — новостного бота — и за сутки получил +232 подписчика. Дашборд загорелся зелёным: «активация 81%». Палец уже тянулся к кнопке «пополнить баланс».

Хорошо, что не долил. Потому что когда я посмотрел, что эти 232 человека реально делают, оказалось: живое действие — осознанный тап 👍 или клик по ссылке — сделал ровно один. Остальные 231 — мёртвые души: 35% заблокировали бота в первый же день, а 218 из 232 зарегистрировались в один и тот же час.

Но самое неприятное — врала не только реклама. Врала моя собственная метрика: «активация 81%» считала автоматические просмотры, которые бот пишет сам себе в онбординге. Я радовался цифре, которую проще всего накрутить.

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

Всем привет, меня зовут Сергей Татарцев. Я эксперт-разработчик розничной АБС в банке Уралсиб. В финтехе уже много лет, в Уралсибе несколько месяцев и моя ключевая задача здесь – оптимизация в СУБД Oracle. Мне нравится эта тема, она дает развитие инженерному творчеству и очень похожа на спорт, где от подхода к подходу видишь, что взял бОльший вес штанги или планку выше предыдущей.

Мое погружение в работу проходило постепенно, не было задач из серии «бросаемся на амбразуру». Процесс онбординга шёл плавно, в том числе и на тестовых задачах.
В этой статье я хочу поделиться одним из таких тестовых заданий. Где мне удалось ускорить один простой запрос в 250 раз, а подход к решению задачи взят к применению на похожих кейсах.

Переход крупных корпоративных систем на отечественные СУБД остается одной из наиболее актуальных задач последних лет. Однако основная сложность подобных проектов заключается не столько в переносе данных, сколько в сохранении работоспособности существующих приложений, написанных под Microsoft SQL Server и Oracle Database.

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

Версия 18.2 стала одним из наиболее масштабных обновлений платформы. В релиз вошли изменения архитектуры продукта, значительное развитие совместимости с Microsoft SQL Server и Oracle Database, новые возможности мастера миграции, первая версия службы построения отчётов, совместимой с SQL Server Reporting Services, а также десятки других улучшений.

Подробнее об изменениях - в этой статье.

Rust скор во время выполнения, а вот компилируется он не так шустро. Едва ли это удивит читателя, имевшего дело с серьёзными базами кода на Rust. В блогах сложился целый жанр постов, повествующих о том, как скостить пару секунд с cargo build.

В нашем проекте мы реализовали функцию, позволяющую пользователям писать прямо на SQL, определяя таким образом таблицы и представления. Под капотом этот код на SQL компилируется в код на Rust — который затем передаётся rustc и с его помощью компилируется в единый бинарник. В этом двоичном файле путём пошагового приращения все представления актуализируются по мере того, как новые потоковые данные поступают в таблицы.

Ранее мы уже предпринимали всевозможные ухищрения, чтобы ускорить компиляцию: стирали типы, активно продавливали дедупликацию кода, сокращали строки, связанные с генерацией кода. В этом мы достаточно преуспели. Но недавно мы стали осваивать работу с крупным новым клиентом (энтерпрайз), у которого оказалась масса сложного SQL-кода. Они написали при помощи наших инструментов много больших программ. Например, там был образец размером в 8562 строк на SQL, который наш компилятор в итоге превращал примерно в ~100k строк на Rust.

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

Сессионные вычислители — залог успеха аналитики будущего

Всем привет, меня зовут Николай Голов. azathot Всю свою профессиональную жизнь я строю аналитические платформы. Возможно, вы видели мои статьи про Vertica и Snowflake.

[ Vertica+Anchor Modeling = запусти рост своей грибницы (Avito блог??, перед?? ней HP Vertica, проектирование хранилища данных, больших данных ]

- статья, 27 февраля

наша дискуссия с новой командой начиналась с одного и того же «дня сурка»:

— бизнес: «Аналитики работают слишком медленно!»;
— аналитики: «Нам не дают работать с базой напрямую, заставляют ставить задачи дата-инженерам и ждать неделями!»;
— инженеры: «Да как их пустить в центральное DWH? Вы видели их запросы? Один забытый ON в джойне — и база ложится на бок, блокируя и отчеты для CEO, и критические ETL-процессы».

Этот сюжет я наблюдал везде: в классическом on-premise (Greenplum, Vertica), в модных китайских решениях (StarRocks) и даже в open-source Lakehouse-инсталляциях (Spark). Меня окончательно шокировал кейс одной огромной европейской компании по доставке еды: она сидела на Databricks, имела практически неограниченные ресурсы, но всё равно страдала от взаимных блокировок и конкуренции за ресурсы.

Как должна выглядеть база, в которой аналитикам действительно можно дать полную свободу? Представьте: каждый аналитик работает в своей персональной базе данных. Он видит актуальные данные в реальном времени, но физически не делит «железо» с соседом.

Фантастика? Нет, Snowflake первым доказал, что это возможно, внедрив архитектуру Multi-cluster Shared Data:

Всем привет!
Эта статья является выжимкой моего опыта. Возможно для кого-то это очевидные вещи, тем не менее, считаю, что она может мыть полезна начинающим и не только.

Для работы с базами данных в го есть несколько подходов от стандартного "ручного", до удобных, таких как sqlx, GORM, sqlc... Список можно продолжать дальше.
При разработке очередного ПО я познакомился с sqlc (https://sqlc.dev/) и его подход мне понравился: на основе sql запросов создается полноценная обертка над бд - чем не песня, но как ее грамотно использовать в соответствии с принципами SOLID и Го подходом?

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

Почтовые адреса используют в реляционных БД, просто записывая их в одно текстовой поле или распределяя по отдельным полям типа город, улица, номер дома, корпус, квартира (возможно, вынося города и улицы в отдельные таблицы). В данной статье хочу поделиться одной моделью представления, которая коррелирует с моделью адресов ГАР ФИАС и позволяет выполнять широкий спектр действий с адресами средствами языка SQL.

Как известно, вручную написанные адреса обладают рядом неприятных свойств, затрудняющих их программное использование. Это и многовариативность написания одного и того же элемента, и пропуски, и искажения, и добавление лишнего. Идея состоит в том, чтобы выделить адресные элементы, нормализовать их, по возможности привязать к элементам ГАР ФИАС и сохранять в таблице БД не только нормализованные строки элементов адреса, но и GUID привязанных к ГАР элементов. При таком представлении возможно средствами SQL производить поисковые операции, находить дубликаты и пр., что затруднительно делать на исходных текстах адресов.

Данная модель применялась в проекте Досье компании Preferentum для системы загрузки и анализа неструктурированной и полуструктурированной информации (выгрузки разных баз и информационных систем). Для нормализации и привязки к ГАР используется SDK Pullenti Address, которое автор и разрабатывает.

Каждый бэкенд-разработчик рано или поздно сталкивается с ситуацией, когда база данных MySQL внезапно ложится при резком пиковом наплыве пользователей. Классическая ошибка на старте - создавать новое независимое соединение с СУБД на каждый чих приложения, выполнять один короткий запрос и закрывать коннект. Когда на сайт одновременно залетают сотни людей, сервер моментально упирается в системный лимит max_connections и падает с ошибкой OperationalError: (1040, 'Too many connections'), попутно забивая всю доступную оперативную память.

┼┼┼┼┼┼┼┼┼▄▀▀▀▄▄▄▄▄▄▄▀▀▀▄┼┼┼┼┼┼┼┼
┼┼┼┼┼┼┼┼┼█▒▒░░░░░░░░░▒▒█┼┼┼┼┼┼┼┼
┼┼┼┼┼┼┼┼┼┼█░░█░░░░░█░░█┼┼┼┼┼┼┼┼┼
┼┼┼┼┼┼─▄▄──█░░░▀█▀░░░█──▄▄─┼┼┼┼┼
┼┼┼┼┼┼█░░█─▀▄░░░░░░░▄▀─█░░█┼┼┼┼┼
┼┼┼██░██░████░██░░░██░░░█████┼┼┼
┼┼┼██▄██░██▄▄░██░░░██░░░██░██┼┼┼
┼┼┼██▀██░██▀▀░██░░░██░░░██░██┼┼┼
┼┼┼██░██░████░████░████░█████┼┼┼

Для строительства компиляторов, нам нужны начала математики. Из них, как мы убедимся, проистекает добрая половина понимания и всех наших работ.
В частности, без начал не понять лямбда-исчисление Чёрча, которое мы применим на этапе работы с AST. Рассмотрим элементы дискретной математики с примерами на С, JavaScript, 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.