SQL *

Почему я решил сделать свой платёжный бот

Я просто хотел принимать платежи и донаты в своём Telegram-канале. Ничего сложного: кинул ссылку — получил деньги. Но когда начал смотреть существующие сервисы (Трибьюн, BotPay и подобные), столкнулся с одним и тем же: регистрация, паспорт, ИП, привязка карт. Мне это было неприятно — как будто чужой дядька лезет в интимные места.

Я не хотел светить данные, не хотел оформлять юридическое лицо, не хотел возиться с налоговой. Хотел просто продавать мануалы и принимать донаты, используя встроенную валюту Telegram — Stars.

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

Clickhouse. CPU под нагрузкой, память на пределе, диск нагружен. Запросы тормозят. Расчёты не завершаются. Сервер на грани. Что же делать?

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

Блокировки — одна из тех тем в 1С, которые все знают на уровне «ну там что-то с параллельным доступом», но мало кто понимает до конца.

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

Когда два пользователя одновременно меняют один и тот же документ или регистр, возникает конфликт. Без блокировок один перезапишет данные другого — классическая проблема lost update. Или один прочитает данные, которые второй ещё не дозаписал.

Блокировки гарантируют, что параллельные операции не сломают данные. Но за это приходится платить — пока один пользователь держит блокировку, другие ждут. Вопрос в том, кто управляет этим процессом: СУБД автоматически или мы вручную.

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

В задачах на SQL особенно интересно то, что один и тот же результат часто можно получить несколькими способами – и разница между ними оказывается не только в красоте запроса, но и в его поведении на реальных данных. В этой статье – разбор прикладной задачи про поиск подозрительных логинов из разных стран в пределах двух часов: с вариантом через self join, альтернативой на оконных функциях и сравнением планов выполнения в PostgreSQL.

Привет, Хаброжители! Реляционные базы данных используются практически в каждой компании. И разбираться в том, как они работают, приходится и разработчикам, и аналитикам, создающим дашборды и отчеты, и специалистам, которым просто нужна актуальная информация. Это увлекательное руководство по миру баз данных и SQL написано в доступной и юмористической манере. Авторы, опытные преподаватели из Университета Торонто, превращают сложные концепции в простые и понятные объяснения с помощью ярких примеров, забавных иллюстраций и практических заданий.

Книга охватывает основы SQL, проектирование сущностей и связей, нормализацию, безопасность, оптимизацию и даже роль генеративного ИИ в дизайне БД. Идеальный выбор для тех, кто хочет освоить реляционные базы данных без скучных лекций, а с удовольствием и практическим применением.

Несколько лет назад я делал внутренние доклады по PostgreSQL для команды — разбирали транзакции, блокировки и уровни изоляции на живых примерах. Потом ушёл на другой стек, а недавно вернулся к PostgreSQL и пересмотрел свои записи. Материал до сих пор актуален — базовые концепции не изменились. В статье: почему UPDATE из двух сессий «висит», чем Read Committed отличается от Repeatable Read на практике, почему Serializable падает даже без логического конфликта, и как VACUUM на самом деле работает с мёртвыми строками. Всё с SQL-примерами, которые можно повторить.

Меня зовут Виталий, я из команды ArcaneGaming.
Сегодня я хочу рассказать вам о своем пет-проекте, который немного вышел из-под контроля и превратился в полноценный продукт.
Встречайте - Snuffer!

😫 С чего всё началось?
Знаете это чувство, когда вам пишет клиент (или, что еще хуже, мама):

Привет Хабр! В прошлой статье мы детально разобрали функциональные зависимости. Возможно, после нее у вас, как и у многих, остался закономерный вопрос: зачем нам вообще так париться, выискивая эти зависимости? Как это применяется в проектировании баз данных?

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

И вот это уже плохо.

В этой статье хотелось бы начать раскрытие больной для многих пользователей Apache Superset темы — фильтры по дате. Начнем с малого: как суперсет выбирает колонку даты; как выбрать желаемую колонку вместо той, которую он выбирает; каким образом это реализовано; какие баги породили этим решением; почему КОП не доведет до добра.

Простой вопрос, который разделяет инженеров и «операторов фреймворков»

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

Достаточно большое количество проблем производительности в backend-приложениях на самом деле находятся не в коде. За последние пару лет мне несколько раз приходилось разбирать системы, где:

• API отвечало слишком долго

• CPU базы был загружен почти на 100%

Более 5 лет я работаю ClickHouse DBA и помогаю командам разработки и аналитики эффективно использовать ClickHouse. Неизменным помощником в этом мне служит хеш-функция cityHash64(). В данной статье мы поговорим в основном про оптимизацию SQL запросов с помощью хеш-функций. Вероятно, рассматриваемые приемы в той или иной степени актуальны не только для ClickHouse, но и для других баз данных, и могут быть полезны любому, кто пишет SQL запросы.

Мы рассмотрим только те применения хеш-функций, которые регулярно встречаются в практике, а не что-то из разряда "100 способов измерения высоты здания с помощью барометра".

С вами снова Виталий Виноградов, я занимаюсь созданием asapBI - платформы для моделирования баз данных и ETL.

Продолжу цикл по системе.

Чего хочется от ETL процесса?

Если процесс простой – например, проброс данных из одной таблицы в другую с промежуточным расчетом – то графический мэппинг полей. Таких простых пробросов в работе – 90%, не хочется лазить по SQL-коду.

Если же процесс сложный – только тогда уже в бой идет ручной SQL, Python, Java, Scala, R.

Если процесс длительный – тогда его лучше выполнять на внешних кластерах Trino, Spark, Impala – как говорится, хранилища отдельно, считалища – отдельно.

Еще нужна только одна точка контроля загрузок – не дело, когда мониторинг загрузок раскидан по разным системам.

В связи с последними (?) событиями было бы здорово иметь возможность заниматься разработкой в оффлайне – сидишь в палатке без 5G, разрабатываешь модели и тестируешь трансформации и цепочки без доступа к инету, а вечером результат сбрасываешь в систему разработки через wi-fi придорожного кафе.

Причем должна быть возможность убрать asapBI и продолжать заниматься разработкой вручную (= медленно и печально) – этим мы предотвращаем вендор лок.

Как бы нам это все замиксовать?

На текущий момент существует много систем со своими интерфейсами и для моделей данных, ETL–процессов нужно в них создавать объекты. Объектов много, надо не забывать, где что лежит и как завязано.

По идее, хорошо бы иметь единый интерфейс, где объекты, рассыпанные по разным системам, связаны между собой. Если убрать этот интерфейс, то модели данных и ETL процессы не рассыплются, все продолжит работу, но настраивать будет уже не так удобно. Единый интерфейс просто объединяет в себе удобную работу с разными инструментами. Именно этот принцип я и реализую в asapBI.

Привет, ХАБР! Я Владимир Хаймин, эксперт по системам управления базами данных PostgreSQL в ВТБ. Когда вы знакомитесь с документацией по какой-то системе в части базы данных, то обычно характер нагрузки определяется исходно в архитектуре проекта. Но если система определена архитектором как OLTP, но в действительности может вести себя в некоторые периоды времени как OLAP. Нормально ли такое поведение, и каким образом мы можем определить, что она ведет себя как-то иначе? Как определить фактический профиль нагрузки OLAP или OLTP и выразить это через метрики, пригодные для событийного и графического мониторинга?

Эта статья является скорее исследовательской в области Data Science в прикладном контексте PostgreSQL. Data Science – это не только задачи ИИ: (ML, LLM,..), но прежде всего математика. Мы используем регрессивные методы для получения некоторых нужных нам параметров исходя из табличных рекомендованных данных. Также мы делаем упор на исследование состояния БД на основе статистики динамики ожиданий. Задача, несмотря на ее простой смысл, в решении оказалась не такой простой, и мы в итоге работали над ней довольно долго, хоть и в фоновом режиме. Также обратились к студенческому сообществу и провели по этой теме Хакатон ВТБ х Башня, прошедший в МГТУ им. Баумана 27 ноября 2025 года. В нем приняли участие студенты и выпускники НИУ ВШЭ, СПбГУ, ВКА им. А.Ф. Можайского, РАНХИГС, Московского Политехнического университета, НИТУ МИСИС, а также уже действующие архитекторы и администраторы БД. У команд было всего три дня на решение задачи, и хотя полностью её не удалось выполнить никому, совокупный результат всех участников позволил сформировать корректное решение. Результат именно этих работ я и изложил в статье и обязательно буду упоминать команды и авторов интересных идей, о которых пойдет речь.

У нас есть продукт и нам нужно рассчитать ключевые метрики, которые показывают здоровье продукта:

• DAU/MAU – вовлеченность
• Conversion Rate – конверсия в целевое действие (у нас это создание объявления)
• Retention – удержание пользователей
• LTV – жизненная ценность клиента
• ARPPU – средний доход с платящего пользователя

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

Проблема N+1 стара как мир. Инструментов много: Debugbar хорош локально, Telescope тяжеловат для продакшена. Мне хотелось решения, которое будет «стучать» в Slack или Telegram именно тогда, когда проблема случилась на проде, и при этом сразу показывать пальцем на виновную строку кода.

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

Представим типичную ситуацию. Есть таблица с десятками колонок и миллионами строк. Нужно понять, почему изменился какой-то показатель — например, выручка или конверсия. Обычно это превращается в цепочку SQL-запросов: сначала агрегируем данные по стране, потом по городу, потом по конкретному сегменту пользователей и тд.

Если таких гипотез несколько, количество запросов быстро растёт с геометрической прогрессией. Каждый новый уровень детализации требует отдельного SQL.

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

Именно здесь на помощь приходят BI-инструменты. Один из самых популярных open-source инструментов для аналитики — Apache Superset.

Почему SUM() OVER (ORDER BY ...) иногда даёт неожиданный результат, даже когда запрос синтаксически правильный? В статье на практических примерах разбираю, как работают оконные фреймы в SQL, чем отличаются ROWS, RANGE и GROUPS, где чаще всего возникает путаница и как писать накопительные итоги и скользящие метрики без сюрпризов. Если используете оконные функции в аналитике, этот разбор поможет сделать их поведение предсказуемым и управляемым.

Договоримся о терминах:·       

*Шардинг БД (db sharding) — это метод горизонтального масштабирования, при котором большая база данных разбивается на более мелкие, независимые части (shards), размещаемые на разных физических или виртуальных серверах. Каждый шард содержит подмножество данных, что снижает нагрузку на отдельные узлы, ускоряет запросы и позволяет хранить большие объемы информации, преодолевая ограничения вертикального масштабирования

**Read consistency (согласованность чтения) в БД — это гарантия того, что транзакция видит согласованное состояние данных, соответствующее определенному моменту времени (обычно моменту начала транзакции или запроса).