SQL *

При работе с данными в SQL рано или поздно возникает задача ранжирования: топ-5 продуктов по продажам, рейтинг сотрудников по KPI, распределение клиентов по категориям.

На первый взгляд RANK() и DENSE_RANK() делают почти одно и то же. На тестовых данных разница может быть вообще незаметна. Но в проде именно здесь часто начинаются ошибки: — топ-3 внезапно возвращает 5 строк; — дашборд "врёт"; — backend-логика начинает вести себя не так, как ожидалось; — запрос, который вчера работал быстро, сегодня уходит в disk spill.

Две самые популярные функции для ранжирования — RANK() и DENSE_RANK(). Ниже разберём, чем они отличаются, где именно ошибаются разработчики и аналитики, и что важно понимать: не только что делает оконная функция, но и сколько она стоит на больших объёмах данных.

Представьте, что вы создаёте мощное поисковое приложение. Пользователи вводят ключевые слова, а ваш бэкенд должен выполнять запрос к базе данных Manticore Search, чтобы найти подходящие результаты. Распространённый (и соблазнительный!) подход — напрямую вставлять ввод пользователя в SQL‑запросы. Например, вы можете фильтровать по числовому полю, такому как категория или идентификатор записи. Если пользователь передаёт обычное значение, например 5, запрос будет SELECT FROM products WHERE id=5. А что, если он передаст 1 OR 1=1? Запрос станет SELECT FROM products WHERE id=1 OR 1=1 — условие всегда истинно, поэтому запрос вернёт все строки вместо одной. Это SQL‑инъекция.

К счастью, существует более безопасный и эффективный способ: prepared statements. По сути, prepared statements отделяют ваш SQL‑код от передаваемых данных. Вместо того чтобы каждый раз собирать всю строку запроса, вы один раз задаёте структуру запроса с маркерами параметров, а затем отдельно передаёте поисковые термины. Подробнее о концепции можно узнать на Wikipedia .

Manticore Search поддерживает prepared statements через стандартный протокол MySQL, предоставляя мощный инструмент для создания безопасных поисковых приложений. Используя prepared statements, вы не только значительно снизите риск SQL‑инъекций, но и улучшите читаемость вашего кода.

prepared statements — это не просто функция; иногда они являются обязательными. Например, библиотека Rust sqlx работает с MySQL-эндпоинтом, используя исключительно prepared statements. Кроме того, некоторые OLE DB‑коннекторы, позволяющие MS SQL работать с сервером MySQL, тоже используют prepared statements внутри.

Хабровчане, приветствую! Меня зовут Михаил Казанцев, я ведущий системный аналитик в мобильном приложении Вайлдберриз. Работал и писал требования как в стартапах с монолитами, так и в банковском секторе с сотнями сервисов в одном контуре, рассказать есть что.

Я хочу рассказать о своём восприятии основной идеи книги Мартина Клепмана — Высоконагруженные приложения через призму своего ультрамарафонского опыта тренировок и соревнований и практики проведения чайных церемоний. Книга технически сложная, поэтому

Миграция базы данных в Legacy системах

Если ваша система не использует ORM

Если промышленное окружение вашей Системы находится не у Вас под контролем

Если нет возможности внедрить инструмент делающий “магию для миграций” - Liquibase / Flyway

И тем не менее, очень, очень и очень :) хочется контролировать как изменения в коде попадают в базу данных

Пришёл в проект, там легаси погоняет легаси. Спагетти такие что уже в рот лезут. Отчёты по филиалам открывались 30 секунд. Команда реально боялась нажать кнопку в рабочее время, а вдруг база ляжет.

Это была система управления розничной сетью: несколько филиалов, сотни тысяч записей о заказах, ежедневные отчёты по выручке и остаткам. На бумаге ничего страшного. На практике монолит на Django где бизнес-логика размазана по контроллерам так, что поменяй что-то одно и сломается три другого.

Первое, что я сделал: открыл EXPLAIN ANALYZE.

Меня зовут Иван Васильев, я ведущий аналитик в Ви.Tech, IT-дочке ВсеИнструменты.ру. Хочу показать, как из на первый взгляд простой формулы KPI выросла инженерная задача: нам нужно было не просто посчитать интегральный показатель эффективности поставщика, а объяснить, какая именно закупка его ухудшила и почему. В статье разберу, почему для агрегированных метрик не работает наивный подход, как мы пришли к remove-one analysis и где пришлось отдельно фиксировать логику расчета, чтобы результат вообще можно было интерпретировать.

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

Ответить на него можно было бы общими словами. Но затем появился уточняющий вопрос:
| А какая именно закупка ухудшила показатель?

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

Поиск редко сводится к одному универсальному сценарию. Пользователь, вводящий "cheap running shoes", хочет точных совпадений по ключевым словам, а пользователь, задающий "comfortable footwear for jogging", выражает то же намерение другими словами. Традиционный полнотекстовый поиск хорошо справляется с первым случаем. Векторный поиск решает второй. Гибридный поиск объединяет оба в одном запросе, так что вам не приходится выбирать.

В современных поисковых системах это часто описывается как комбинирование лексического (разреженного) поиска с семантическим (плотным) поиском. Разные термины, одна идея: точное совпадение плюс смысл.

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

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

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

Работу аналитика хранилищ данных можно разделить на две части:

1. Организация интеграции данных от какого‑либо источника к какому‑либо приемнику;

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

В этой статье хотим с вами поговорить именно о второй части, так как, согласно практике, именно по ней отсутствует какая-либо документация по действиям для устранения каких-либо проблем.

В мире данных, где информация является ключевым активом, процессы ETL играют центральную роль в агрегации, очистке и подготовке данных для анализа и принятия решений. Однако одной из самых неприятных и критических проблем, с которой сталкиваются дата-инженеры и аналитики, является расхождение данных на приемнике (целевой системе) с данными в источнике. Как следствие, это может привести к некорректным отчетам, ошибочным бизнес-решениям и потере доверия к данным.

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

Если у вас стоит Always On Availability Groups, вы наверняка бывали в такой ситуации: в SSMS всё зелёное, дашборд показывает «Synchronized», а пользователи звонят с жалобами на тормоза. Смотришь на secondary — а там redo_queue_size 600 МБ, реплика отстаёт на полчаса. Ни одного алерта.

У нас это случилось на продуктивном кластере с 1С: secondary молча отвалился в SYNCHRONIZING, а мы узнали только при плановом переключении. Полтора часа redo queue. Стало понятно, что встроенный дашборд SSMS — это не мониторинг. Дальше — как мы это закрыли Zabbix'ом за вечер.

Вторая часть серии по PostgreSQL из моих внутренних докладов. В этот раз — индексы: откуда берётся cost в EXPLAIN и почему это «попугаи», а не миллисекунды. Почему PostgreSQL игнорирует ваш индекс при высоком покрытии таблицы. Как физическое расположение данных на диске влияет на скорость даже при наличии индекса. Плюс GiST для нечёткого поиска с триграммами, GIN для полнотекстового поиска и EXCLUDE constraints для задач типа бронирования. Всё на примере таблицы с 4 миллионами строк.

Привет! Меня зовут Денис, я работаю аналитиком потерь на складе. В какой-то момент я устал от постоянной работы с Excel-выгрузками и решил это автоматизировать.

В итоге всё началось с простого Telegram-бота, а закончилось полноценным web-приложением с отдельным backend, интеграциями и нормальным интерфейсом.

Сегодня хочу рассказать про сам путь: как из “скрипта под задачу” постепенно вырастает система.

Есть мнение, что принципиальной точкой в развитии ИИ станет обретение им сознания. Что такое со‑знание, как оно появляется и «работает» (у Жизни, у нас, у ИИ) разговор отдельный. Но говоря о сознании нельзя пройти мимо темы так называемый «квалий», на использовании которых в качестве своеобразной базы данных как считается сознание и основывает свою работу. Конечно же есть множество литературы на эту тему, в т.ч. и Д. Чалмерс, однако к.м.к. всё же имеет смысл схематически показать что такое квалии, как они получаются и работают на краткой, простой и понятной модели с использованием ПК и языка SQL.

В этой статье продолжаем борьбу с фильтрами по дате в Apache Superset. Сегодня разберем, как реализовать подобие логики remove_filter в старых версиях (до 5), чтобы виртуальный датасет не оборачивался фильтрами.

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

Я просто хотел принимать платежи и донаты в своём 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-примерами, которые можно повторить.