N+1 в масштабе: исчерпание пула, изменения планов и денормализация

Сервис с 50 запросами на request и connection pool размером 25 начинает возвращать 503 при нагрузке. Отдельные запросы быстрые. База данных здорова. Пул насыщен — каждый request удерживает соединение на протяжении 50 серийных запросов, и пул не успевает ротироваться достаточно быстро для обслуживания трафика.

Исчерпание connection pool

Endpoint с N+1 удерживает соединение с базой данных на протяжении многих серийных запросов. При размере connection pool 25 и 50 запросах на request по ~2 мс каждый, каждый request удерживает соединение ~100 мс.

Пропускная способность на соединение: ~10 requests/s. Общая пропускная способность пула: 250 requests/s. Когда нагрузка превышает 250 requests/s, новые запросы встают в очередь ожидания соединения. Очередь добавляет latency; хвосты latency раскручиваются; в итоге 503.

Диагностическая сигнатура: метрика насыщения connection pool высокая, latency отдельных запросов стабильная, очередь запросов растёт. Первопричина — не база данных, а приложение, удерживающее соединения слишком долго.

# pgbouncer метрики — опережающий индикатор
cl_waiting > 0 более нескольких секунд → вероятен N+1
server_active / max_server_connections > 80% устойчиво → давление на пул

Фикс — это фикс N+1: уменьшить запросы на request с 50 до 2–3. Каждый request теперь удерживает соединение ~10 мс вместо 100 мс. Пропускная способность пула возрастает с 250 до 2 500 requests/s — облегчение в 10× при том же размере пула.

Та же форма применима к HTTP client pools, gRPC connection pools, Redis pools: любой pooled resource, где hold-time вызывает исчерпание.

Изменения query plan после фиксов N+1

Фиксы N+1 меняют форму запросов, что меняет query plan’ы. Запрос, который был WHERE id = 1, теперь WHERE id IN (1, 2, ..., 1000). Postgres может переключиться с index scan на bitmap scan или sequential scan в зависимости от оценок selectivity и размера списка.

-- До: быстрый index scan
EXPLAIN SELECT * FROM tasks WHERE project_id = 1;
-- Index Scan using tasks_project_id_idx (cost=0.43..8.45 rows=10 width=80)

-- После фикса: большой IN-список, план может измениться
EXPLAIN SELECT * FROM tasks WHERE project_id IN (1, 2, ..., 500);
-- Bitmap Heap Scan on tasks (cost=12.55..350.00 rows=5000 width=80)

Senior production дисциплина: после фикса N+1 запустите EXPLAIN ANALYZE на новом запросе на репрезентативных размерах продакшн-данных. Убедитесь, что план не деградирует для edge-кейсов (очень маленькие наборы родителей, очень большие наборы родителей, специальные значения параметров). Фикс, работающий на 50 строках, может изменить план на 5 000.

# Postgres инструменты для мониторинга планов
pg_stat_statements   — отслеживать количество и длительность выполнения запросов
auto_explain         — логировать планы для запросов, превышающих порог

Стратегия Hibernate subselect loading генерирует SELECT * FROM child WHERE parent_id IN (SELECT id FROM parent WHERE ...) — коррелированный подзапрос, который может давать очень разные планы по сравнению с основным запросом к родителю. После применения batch-size или subselect loading в Hibernate проверьте стабильность плана.

Безопасность: query amplification как DoS

N+1 путь кода может быть вектором атаки. Если публичный endpoint позволяет пользователю запрашивать N элементов, а обработчик выполняет N+1 запросов на элемент, атакующий может насытить базу данных одним большим запросом.

Реальные инциденты: Strapi 2021 (CVE-2021-32820) — глубоко вложенный фильтр мог амплифицировать запросы в 1 000 раз. Разные GraphQL-провайдеры — цикличные запросы вызывают экспоненциальное расширение резолверов. Ранние версии Hasura — permission filters без ограничений.

Меры защиты:

// GraphQL — ограничения глубины и сложности
import depthLimit from 'graphql-depth-limit';
import { createComplexityRule } from 'graphql-query-complexity';

const server = new ApolloServer({
  validationRules: [
    depthLimit(5),
    createComplexityRule({ maxComplexity: 200 }),
  ],
});

Per-request query budget, применяемый на уровне фреймворка: Rails strict_loading + max-queries middleware. Hasura automatic complexity analysis. Любой user-controlled параметр, умножающий количество запросов — вектор DoS. Senior code review для кода с ORM включает: “может ли это позволить query amplification при hostile input?”

Prepared statements снижают overhead даже при сохранении N+1

Когда N+1 неизбежен (legacy код, exploratory запросы), prepared statements снижают overhead на запрос. Каждый параметризованный запрос WHERE id = ? парсится и планируется один раз; последующие выполнения пропускают parse и plan.

-- Postgres явно:
PREPARE get_task AS SELECT * FROM tasks WHERE id = $1;
EXECUTE get_task(42);

-- ORM'ы используют prepared statements по умолчанию для параметризованных запросов.
-- Синтаксис ? или $1 параметра ORM И ЕСТЬ протокол prepared statement.

Экономия: ~30–50% на повторный запрос на Postgres. Для сервиса, выполняющего тысячи повторных запросов в секунду, prepared statements сами по себе могут снизить CPU БД на 10–30%.

Tradeoff: аффинность connection pool. Prepared statements ограничены соединением в некоторых настройках. pgbouncer transaction mode отключает server-side prepared statements (используйте PgBouncer statement-level pooling или pgbouncer_params prepared statement passthrough если нужно и то, и другое).

Когда денормализация — правильный ответ

Для путей с экстремальными latency SLO — HFT, real-time bidding, sub-50 мс p99 на тяжёлых join’ах — даже 2–3 запроса слишком много.

Counter cache: хранит производные данные у родителя. Вместо count(*) на request — один SELECT поля.

# Rails counter_cache
belongs_to :project, counter_cache: true
# project.tasks_count поддерживается автоматически при create/destroy

Materialised view (Postgres): предвычисляет сложный join + агрегацию. Страница получает данные одним запросом к полностью готовому view.

CREATE MATERIALIZED VIEW product_summary AS
SELECT p.id, p.name, c.name AS category,
       COUNT(r.id) AS review_count,
       AVG(r.score) AS avg_score
FROM products p
JOIN categories c ON p.category_id = c.id
LEFT JOIN reviews r ON r.product_id = p.id
GROUP BY p.id, p.name, c.name;

REFRESH MATERIALIZED VIEW CONCURRENTLY product_summary;

CQRS read model: write side обновляет нормализованную схему; event handler записывает в read-оптимизированную таблицу с предварительно соединёнными данными. Read path получает данные одним запросом.

Tradeoff’ы: staleness (read view отстаёт от writes на миллисекунды до секунд), дублирование хранилища, стоимость поддержки (логика derivation должна оставаться корректной при эволюции схемы).

Когда применять: read p99 SLO < 50 мс на тяжёлых join’ах И read нагрузка в 1 000 раз или более превышает write нагрузку. Для сбалансированных нагрузок ORM eager loading проще и достаточен. Денормализация — правильный ответ только когда измерение показывает, что eager loading не может удовлетворить SLO.