SQL *

Всем привет!

На одном из проектов я настраивал дашборд в Yandex DataLens, который объединяет данные о трафике из Яндекс Метрики с данными о заказах из CRM и позволяет анализировать доход в разрезе источников трафика.

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

Привет, Хабр! В этой статье я хочу поделиться опытом проведения внешнего black-box пентеста и разобрать методологию, которая позволяет находить критические уязвимости даже при минимальном входном скоупе. Статья будет разбита на две части, про внешний расскажу я, а про внутренний расскажет мой коллега.

Black-box подразумевает, что у пентестера нет никакой внутренней информации: ни списков IP, ни учётных данных, ни описания архитектуры. Только доменное имя - и вперёд. Звучит как ограничение, но на практике это зачастую преимущество: вы смотрите на инфраструктуру глазами реального злоумышленника.

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

Разберем топ вопросов на знание SQL, которые чаще всего задают на собеседованиях. Я собрала в этот топ свой опыт и опыт коллег, которые недавно проходили собеседования.

EXPLAIN ANALYZE часто воспринимается как инструмент, который показывает план выполнения запроса. Но если посмотреть внимательнее на блок BUFFERS, он начинает отвечать на более прикладной вопрос — где именно запрос упёрся в I/O и почему это произошло. В этой статье разберём, как читать эту статистику на уровне отдельных узлов плана, как интерпретировать hit/read в контексте нагрузки и почему сами числа почти ничего не значат без сравнения во времени.

Метрики могут «упасть» даже если вы ничего не меняли в модели.
Разбираемся, как распознать distribution shift и что с ним делать в продакшене.

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

Эта история о том, как мы придумали и реализовали свой собственный метод, когда никакие другие сторонние инструменты не позволяли сохранять работоспособность сервиса и гарантировать надёжность. Его можно применять во всём мире, где используются платформы на базе PostgreSQL.

Один из наших пользователей недавно пришёл к нам со знакомой проблемой: поиск внезапно стал заметно медленнее, хотя внешне ничего явно не ломалось.

Сервис работал, ошибок в логах не было, загрузка CPU выглядела нормально, но пользователи уже начали жаловаться, что поиск тормозит.

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

К тому моменту, когда пользователи это замечают, настоящая проблема нередко копится уже несколько часов. Без хорошей видимости остаётся только гадать: система перегружена? Одна таблица съедает ресурсы? Или незаметно что-то идёт не так?

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

Меня зовут Сергей Усов. В Газпромбанке я в составе небольшой команды занимаюсь развитием и сопровождением корпоративной BI-системы на базе решения Sigla Vision (российский форк FineBI).

Мы хотим поделиться практическими наработками с сообществом пользователей Sigla Vision / FineBI — сделать работу с системой удобнее и облегчить жизнь администраторам. При этом часть наших подходов может пригодиться и тем ИТ-специалистам (разработчикам, дата-инженерам, аналитикам), которые сопровождают работу технических систем, имеющих в своем составе БД с репозиториями метаданных. Описанные решения являются общеинженерными и могут быть применены не только к корпоративным аналитическим системам.

Это первая статья из цикла, посвященного нашему опыту администрирования Sigla Vision.

Самый неприятный тип инцидента — когда база данных не падает полностью, а просто начинает работать медленнее.

Пользователи замечают это сразу. Жалобы начинают поступать. Технически всё по-прежнему работает, но явно что‑то не так.

И обычно самое сложное здесь не заметить проблему, а понять, что на самом деле происходит.

Я Шевкопляс Дмитрий, технический руководитель проекта Swapno — сервис для обмена автомобилями ключ-в-ключ, без дилеров. Механика — как в Tinder: свайпаешь чужие авто, если оба владельца лайкнули машины друг друга — Swap Match, начинается обмен. В этой статье расскажу, как мы спроектировали и написали бэкенд на Go за 3 месяца: от выбора архитектуры до matching engine, AI-модерации фото и observability в продакшене. С реальными ошибками, которые мы допустили, и тем, как их чинили.

Если серьезно, то сегодня мы поговорим про БАЗЫ данных. Как-то один мой друг разработчик сказал, что программирование можно понимать как

Начиная с Manticore Search 24.4.0, компактизация RT-таблиц использует более эффективную модель выполнения. Вместо последовательного слияния пар чанков оптимизация теперь поддерживает два важных улучшения:

С JSONB в PostgreSQL есть одна довольно коварная ловушка: GIN‑индекс вроде бы поставили, запросы вроде бы работают, EXPLAIN не пугает — и на этом многие успокаиваются. Но как только данных становится действительно много, выясняется, что выбор между jsonb_ops и jsonb_path_ops — это не нюанс из документации, а вполне ощутимая разница в размере индекса, количестве лишних проверок и времени выполнения запросов. В этой статье разберём, как устроены оба оператор‑класса, почему один считается универсальным, а второй часто оказывается выгоднее на практике, и в каких случаях дефолтный выбор в PostgreSQL оказывается далеко не лучшим.

В статье показываем контракты будущей OLTP-СУБД: как разделены слои ядра, зачем нужен per-tablespace page size, почему конфигурация уходит в adaptive tuning и как мы встраиваем USDT/eBPF-наблюдаемость прямо в бинарник.

JSON в PostgreSQL давно перестал быть экзотикой, но работать с ним по-реляционному до сих пор приходилось не самым изящным способом: jsonb_array_elements, LATERAL, ручные касты, обработка ошибок на честном слове. В PostgreSQL 17 появился JSON_TABLE — стандартный SQL/JSON-механизм, который превращает JSON-документ в табличное представление одним выражением. В статье разберём, как он работает, чем отличается от привычного подхода, где действительно упрощает запросы и какие ограничения по производительности и применению у него остаются.

С тех пор как мы представили инструмент резервного копирования в Manticore Search 6, создавать резервные копии данных стало заметно проще. Но мы постоянно слышали один и тот же вопрос: "А как насчёт облачного хранилища?" Сегодня мы рады объявить, что manticore-backup теперь поддерживает S3-совместимое хранилище с потоковой загрузкой — без промежуточных файлов, без проблем с местом на локальном диске, только бэкапы напрямую в облако.

На старте у клиента уже были дашборды, но они не закрывали текущие задачи бизнеса. Данные находились в разных системах — 1С, Excel, Google Таблицы, XML-выгрузки и внутренняя система.

Клиент принял решение выстроить аналитику заново и выбрал Apache Superset как инструмент визуализации. Сначала собрали единый слой в PostgreSQL, настроили загрузку через Python, привели метрики к одной логике и зафиксировали правила расчётов.

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

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

При работе с данными в 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 внутри.

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

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