01. Зачем оптимизировать производительность запросов

Для продукта класса СУБД оптимизация даёт:

• Кратный прирост производительности (×10): парк машин у пользователя можно сократить со 100 до 10.

• Сокращение времени ответа с 10 с до 1 с: интерактивная аналитика становится реально применимой там, где раньше это было невозможно.

• Более высокую конверсию внедрений: оптимизация запросов почти всегда входит в POC, поскольку она хорошо поддаётся измерению.

Для инженера баз данных:

• Кратные (и порядковые) ускорения приносят серьёзное профессиональное удовлетворение.

• Быстро растёт компетенция: оптимизация производительности БД — многомерная и очень сложная инженерная задача, затрагивающая всё: от архитектуры до низкоуровневых деталей, от «железа» до «софта», от ядра ОС до приложения.

02. Цели оптимизации

• Со стороны приложения — задержка (latency) и пропускная способность (throughput). При неизменном бюджете ресурсов уменьшение задержки, как правило, повышает throughput.

• Со стороны системы — эффективное использование CPU, I/O, памяти и сети. Важно следить не только за латентностью и throughput, но и за утилизацией ресурсов: иногда кратный выигрыш достигается ценой кратного роста потребления CPU.

03. Как находить узкие места производительности

Используйте:

• Встроенные средства наблюдаемости СУБД.

• Универсальные инструменты Linux производительности.

3.1. StarRocks Observability: Query Profile

Query Profile показывает, где «тормозит» запрос: на этапе планирования (plan) или на этапе выполнения (execution), и какой оператор становится «бутылочным горлышком».

3.2. StarRocks Observability: Optimizer Trace

Optimizer Trace позволяет одной командой выяснить, на каком этапе оптимизатора возникает задержка, и быстро локализовать узкое место планирования.

3.3. StarRocks Observability: Executor Trace

Executor Trace помогает найти проблемное место во время выполнения: CPU, I/O или scheduler.

3.4. CPU Sampling — perf

Помимо встроенных средств СУБД, используйте Linux perf для профилирования на CPU и построения флейм‑графов (flame graphs), чтобы видеть «горячие точки» нагрузки.

3.5. Off‑CPU Tracing — eBPF

Часто узкое место — это не вычисления на CPU, а ожидание I/O, сети или блокировок. Для этого нужен off‑CPU‑анализ — изучение времени ожидания вне CPU; инструменты на основе sampling здесь малоэффективны, поэтому применяйте трассировку (tracing), например eBPF.

3.6. Intel Top‑down Microarchitecture Analysis Method

Методика top‑down разбивает узкие места CPU на 4 класса и детализирует их до конкретных причин:

• Retiring — завершение инструкций (недостаток SIMD‑оптимизаций, неэффективные инструкции).

• Bad Speculation — ошибочная спекуляция (промахи предсказания ветвлений и пр.).

• Frontend Bound — ограничения фронтенда (instruction cache miss, декодирование).

• Backend Bound — ограничения бэкенда (data cache miss, память/шины).

Упрощённо: Retiring, Bad Speculation, Frontend Bound, Backend Bound соответствуют (грубо): отсутствию SIMD‑оптимизаций, ошибкам предсказания, промахам I‑cache и промахам D‑cache.

3.7. Linux Performance Tools

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

3.8. Метрики мониторинга производительности

Хороший пример — TiDB: ключевые метрики всего пути обработки запроса экспонированы и позволяют удобно анализировать «узкие места» по слоям. Это удобно для администраторов БД (DBA), инженеров решений и пользователей.

3.9. Тестирование планов оптимизатора

SQL — декларативный язык («что», а не «как»), поэтому вариантов плана — тысячи. Итоговый план оптимизатора нередко не оптимален. Причины:

• Слишком много альтернатив, человеку трудно их перечислить.

• Реальная производительность зависит от исполнителя (операторов), размера кластера, характеристик данных и железа.

Нужны специальные средства перебора и измерения реальной производительности альтернативных планов (optimizer plan test), чтобы находить лучший.

Примеры:

• Два эквивалентных SQL могут отличаться в 3 раза по времени из‑за того, что не выведен предикат вида ename NOT LIKE 'ACCT'.

• Если известно, что emp_pk — первичный ключ, GROUP BY emp_pk можно упростить и получить ×3 ускорение.

04. Как оптимизировать производительность запросов

4.1. Общая CPU‑оптимизация

СУБД — крупное CPU‑приложение, поэтому используйте общие подходы:

• Аппаратное обеспечение: прямая замена (HDD → NVMe/SSD). Чтобы раскрыть потенциал нового «железа», оптимизируйте архитектуру, структуры данных и алгоритмы.

• Операционная система: обновления ядра часто дают новые возможности/ускорения, например асинхронный интерфейс ввода‑вывода io_uring.

• Компилятор: современные компиляторы улучшают векторизацию и оптимизации.

• Язык и библиотеки: отличаются производительностью; внутри одного языка есть множество приёмов ускорения.

• Архитектура приложения: сильно влияет на масштабируемость, например MPP vs Scatter‑Gather.

• Структуры данных и алгоритмы: выбор даёт порядковые отличия (пример — хеш‑таблица).

• Низкоуровневые оптимизации: SIMD, кэш‑локальность.

• Бизнес‑логика: упрощения (например, приблизительная вместо точной дедупликации), оптимизация моделирования данных.

4.2. DataBase Pre‑Process vs Runtime Process

Ключевой выбор: что предвычислять заранее (pre‑process), а что делать «на лету» (runtime). Чем больше полезной работы перенесено в подготовительную стадию (в рамках SLA на свежесть), тем меньше задержки в runtime. Важно найти правильный баланс для вашего профиля нагрузок.

4.3. High Level‑оптимизации на уровне БД

• Архитектура: разделение хранения и вычислений или совмещение; Serverless; распределённый или локальный кэш.

• Масштабирование:

  • По горизонтали (Scale Out): линейный рост производительности при увеличении числа узлов.

  • По вертикали (Scale Up): эффективное использование всех ядер.

• Стратегии выполнения: sort‑based vs hash‑based для агрегирования и join; повторное использование CTE (CTE reuse); pushdown‑агрегация.

• Модель выполнения: векторизация; генерация кода (codegen); модель push или pull.

4.4. Low Level‑оптимизации на уровне БД

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

4.5. Оптимизация с точки зрения ресурсов

Суть — уменьшить бесполезную работу и расход ресурсов при той же асимптотике:

• «Read Data Less and Fast» — оптимизация I/O на уровне хранения.

• «Transfer Data Less and Fast» — оптимизация сетевых передач на уровне вычислений.

• «Process Data Less and Fast» — оптимизация CPU и памяти на уровне вычислений.

05. Как грамотно тестировать производительность

• Проводите сравнения на одинаковой базе: железо, данные, модели — без рассинхронизации условий.

• Тестируйте под разные аппаратные профили (ядра, накопители и т. п.).

• Оценивайте не только одиночный поток, но и высокую параллельность.

• Смотрите не только задержку и throughput, но и утилизацию ресурсов.

• Анализируйте не только среднее (avg), но и p99 и джиттер (вариативность задержек).

• Тестируйте не только целевой сценарий, но и типовые workload’ы.

• Процесс должен быть тщательным, системным, «чутким» к деталям, автоматизированным и стандартизованным.

06. Есть ли предел оптимизации на CPU‑архитектуре?

Оптимизация бесконечна, потому что:

• «Железо» постоянно меняется: это ведёт к изменениям архитектуры и даже структур данных/алгоритмов.

• Архитектура СУБД эволюционирует: меняются модели/стратегии выполнения и фокус оптимизации.

• Больше контекста — больше стратегий: чем больше знаний о данных и нагрузке, тем точнее оптимизации.

• Инновации в структурах данных и алгоритмах не прекращаются (даже хеш‑таблицы продолжают эволюционировать).

• Инновации в стратегиях выполнения: CTE reuse, агрегирование pushdown, runtime‑фильтры и др.

• From Manually to Adaptive: постепенно скрываем настройки и session‑параметры; отказ от каждого ручного тюнинга предполагает появление новой адаптивной стратегии.

07. Производительность в продакшене vs бенчмарках

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

• Большие запросы мешают маленьким.

• Импорт, запросы, компакция (compaction), сбор статистики и пр. взаимно влияют.

• Управление параллельностью и очередями запросов.

• Таймауты и повторные попытки (retry).

• Ориентир — p99, а не среднее.

• Медленные узлы («slow‑ноды»).

• Перекос распределения данных (data skew).

Каждый пункт — это самостоятельный и нетривиальный проект оптимизации.

08. Компромиссы при оптимизации

Перед внедрением оптимизации взвесьте:

• Сложность кода.

• Совместимость.

• Стабильность.

• Соотношение затрат и эффекта (ROI).

• Универсальность (переносимость идеи).

• Предсказуемость результата.

И помните:

• Не все запросы нужно удовлетворять.

• Не все баги нужно чинить.

• Не все оптимизации нужно реализовывать.

09. Будущее оптимизации OLAP‑СУБД

9.1. Serverless: производительность с приоритизацией стоимости

Чтобы добиться высокой производительности в Serverless‑архитектуре:

• Не допускайте последовательных «бутылочных горлышек» в архитектуре, фреймворке и алгоритмах.

• Обеспечьте близкую к линейной масштабируемость каждого SQL при росте числа узлов.

• Решайте перекос данных (data skew), иначе ресурсы кластера не будут использоваться полноценно.

9.2. Адаптивное выполнение в реальных сценариях

Из‑за различий в распределении, кардинальности и корреляции данных оптимизатор не всегда построит «хороший» план. Значит, адаптивное выполнение неизбежно (feedback‑driven планирование, динамические стратегии, runtime‑фильтры и пр.).

9.3. AI‑оптимизация на основе истории

В batch‑сценариях используйте History‑based оптимизацию:

• Опора на фактические метрики прошлых задач и путей выполнения.

• Учет реальных SQL пользователей для обучения и выбора стратегий.

10. Как вырасти до эксперта по оптимизации производительности БД

• Глубокие знания CPU, памяти, сети и I/O: принципы, метрики, инструменты наблюдаемости.

• Профильные знания в области СУБД.

• Инструменты и методологии тестирования производительности.

• Набор подходов к оптимизации в сфере БД (архитектурные, алгоритмические, операционные).

• Отслеживание научных и индустриальных трендов.

• Внимание к новому железу и архитектурам.

• Глубокое понимание принципов и исходного кода целевой системы.

• Оптимизация — это инженерия: практика, эксперименты, накопление кейсов.

Присоединяйтесь к профессиональным сообществам — вместе проще обмениваться опытом и расти!