SQL *

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

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

Хочу рассказать о своей разработке и поделиться ей с сообществом habr в виде готового модуля для Python.

Этот модуль решает задачу обновления данных в базе данных. Он выполняет insert/update/delete в одном действии.

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

Для взаимодействия с базой данных используется SQLAlchemy и ее универсальные механизмы, таким образом, разработка не имеет привязки к конкретной БД. (На момент написания статьи, детальные тесты проводились для PostgreSQL, MariaDB, SQLite, MS SQL)

Принцип действия

Принцип действия следующий: модуль создает временную таблицу в базе и записывает в нее весь входящий датасет через операцию массового insert. Далее он выполняет инструкции UPDATE, INSERT, DELETE для целевой таблицы.

Я решил собрать для себя приложение, которое объединит несколько AI-модулей в одном месте: фитнес-трекер с AI-тренером, новостной дайджест по AI/ML, дашборды для других проектов. Не SaaS для всех, а инструмент для себя. PWA, чтобы работало как нативное приложение на телефоне.

В итоге: 4 дня по 4 часа, 8600 строк кода, работающий продукт в production. Расскажу как это получилось.

Путь разработчика от «Prisma — это магия» через «почему это так медленно?» к решению, которое сохраняет и DX, и производительность.

В статье разбирается техническая реализация SQLize Embed — легковесного JS-компонента для создания интерактивных песочниц прямо в тексте технических статей. Автор подробно описывает архитектуру решения: от использования MutationObserver для инициализации редакторов на фронтенде до обеспечения безопасности и изоляции запросов в Docker-контейнерах на бэкенде.

Вы узнаете, как реализована поддержка более 20 СУБД (включая PostgreSQL 18, MS SQL 2025 и Oracle 23ai) и как встроить «живые» примеры кода в свой проект всего парой строк HTML.

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

Так выглядит ручной доступ к данным. Бизнес понимает, что нужные данные в хранилище есть, но не всегда может их быстро получить. А аналитик становится «бутылочным горлышком», через которое проходит большой поток запросов.

Мы хотели упростить работу с данными. Чтобы пользователь задавал вопрос, сервис превращал его в SQL, выполнял в хранилище и возвращал аналитический ответ. Чтобы рутина уходила в инструмент, а аналитик переставал быть «бутылочным горлышком».

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

В 1974 году, когда SQL только вышел из исследовательских лабораторий IBM, работа с базами данных выглядела просто: разработчик писал запрос и получал результат. Без слоёв, абстракций и фреймворков — только строки, описывающие нужные данные.

Эта прямота дорого обходилась. Переименование колонки превращалось в поиск по тысячам строк кода в надежде отловить все упоминания. Неаккуратная работа с пользовательским вводом приводила к SQL-инъекциям. Миграция с Oracle на PostgreSQL часто означала переписывание значительной части запросов из-за различий диалектов.

К середине 1990-х проблема стала настолько заметной, что начали появляться Object-Relational Mapper’ы (ORM). Идея выглядела привлекательно: работать с таблицами как с объектами, писать код на «родном» языке программирования вместо SQL-строк, а перевод на SQL оставлять фреймворку.

Продолжаем цикл статей с обзором изменений 19-й версии. На этот раз рассмотрим что появилось в рамках сентябрьского коммитфеста 2025 года.

Самое интересное из первого июльского коммитфеста можно прочитать здесь: 2025-07.

CedrusData Engine — это lakehouse-движок, основанный на Trino. На реальных нагрузках наш продукт рутинно превосходит по производительности другие технологии (Trino, Doris, Dremio, StarRocks) в 1.5-3 раза, с еще более значительным отрывом от устаревших Greenplum и Impala. Эти результаты — следствие постоянных вложений в разработку новейших техник обработки больших данных. В этой статье я расскажу про проект Oxide — одну из наших ключевых инициатив прошлого года по переписыванию ядра Trino с Java на Rust.

Это первая статья из цикла о построении CDC-пайплайна в домашней лаборатории.
Полный путь: Telegram → PostgreSQL → Debezium → Kafka → HDFS → DWH.
Но любой пайплайн начинается с данных — и эта статья про их получение.

Clickhouse никогда не удаляет ваши данные, главное помнить об этом и знать где искать. Наш кейс миграции на Clickhouse Keeper, история потери и восстановления данных

Всем привет! Меня зовут Кирилл Грищук, я Tech Lead в команде Инфомодели в Авито. Мы развиваем платформу объявлений и их характеристики.

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

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

Многие опытные разработчики недооценивают мощь инструментария БД при работе с микросервисами. По каким-то причинам в IT-сообществе приняты эмпирические правила - сервис маленький, значит и база маленькая. Но это не совсем так.

Скорее всего, при проектировании архитектуры у нас в голове чаще всего возникает паттерн database-per-service. И когда мы начинаем рисовать схемы, то возникает соблазн покрутить кирпичики модулей так, чтобы красиво их соединить стрелочками с цилиндриками, обозначающими БД.

С другой стороны, все знают, что много микросервисов, взаимодействующих через одну общую монструозную базу как Oracle, ElasticSearch и другие - это антипаттерн.

Поэтому выбирают маленькие(!) Postgres или MySQL.

Однажды при мониторинге мы обратили внимание на запрос, который занимал первое место по длительности: 40+ секунд на выполнение при 657 вызовах за день. Причина состояла в том, что из-за неточной статистики распределения данных выбирался неподходящий индекс. В статье расскажем о том, как с помощью параметра STATMULTIPLIER в СУБД Tantor Postgres этот проблемный запрос удалось ускорить примерно в миллион раз — до 0.042 миллисекунды, — просто повысив точность статистики без изменения кода или структуры базы данных.

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

Привет, Хабр! С каждым годом ИИ способен решать более сложные задачи, одной из задач является понимание DAX, связанных предметных областей и генерация кода. Можно выделить несколько задач, которые не являются первостепенными, тем не менее актуальны для анализа или работы в Power BI, например, от простейших — создание клиента для выполнения DAX запросов в Power BI из произвольной среды (например, из .NET приложения) и импорт метаданных TOM модели, до более сложных задач — экспорта схемы данных и самих данных из Power BI в произвольную СУБД (понятно, что такая задача не всегда актуальна с точки зрения ETL, т.к. проще взять данные из исходных источников, а не из Power BI, но польза решения задачи «интуитивно понятна» пользователю) и задач генерации SQL запросов на основе DAX для заданной СУБД, причем результаты сгенерированного SQL должны совпадать с результатами DAX запросов.

Интересующимся применением ИИ на примере DAX из Power BI — добро пожаловать под кат :)

Начинаем новый цикл статей с обзором изменений 19 версии. И первая статья о событиях летнего июльского коммитфеста прошлого года.

Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.

В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.

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

В PostgreSQL и Oracle Database команда UPDATE, столкнувшаяся с заблокированной строкой, ведёт себя по-разному. В статье рассматривается, как выполняется UPDATE в этих базах данных. Это может быть полезно при миграции кода приложения мжду этими базами данных.