Lazy Materialization (25.4): чтение колонок после фильтра

С версии 25.4 в ClickHouse появилась новая оптимизация плана запроса — lazy materialization. Идея: для запросов вида SELECT * FROM t ORDER BY x LIMIT N тяжёлые колонки (длинные строки, JSON, массивы) читаются с диска только для тех N строк, которые попадут в финальный результат, а не для всей таблицы.

В блог-посте ClickHouse приводится пример с Amazon reviews (150 миллионов строк): тот же запрос ускорился с 219 секунд до 0.139 секунды — ускорение в 1576 раз, при этом пиковое потребление памяти упало с 1.11 GiB до 3.80 MiB, а I/O — с 71.38 GB до 1.81 GB.

Проблема: чтение тяжёлых колонок впустую

Рассмотрим типичный аналитический запрос Top-N:

SELECT helpful_votes, product_title, review_headline, review_body
FROM amazon.amazon_reviews
ORDER BY helpful_votes DESC
LIMIT 3;

Без оптимизации pipeline выглядит так:

1. Прочитать с диска все 4 столбца для всех 150 миллионов строк.
2. Отсортировать по helpful_votes.
3. Вернуть первые 3 строки.

Узкое место — шаг 1. Колонки product_title, review_headline и review_body — это переменной длины строки (десятки гигабайт совокупно), а в результат попадает всего 3 строки. Получается: ClickHouse читает 70+ GB строковых данных, которые сразу отбрасываются.

Как работает lazy materialization

Lazy materialization меняет порядок операций в pipeline:

1. Прочитать только helpful_votes (плюс PREWHERE-колонки, если есть).
2. Отсортировать строки по helpful_votes.
3. Применить LIMIT 3 — остаются 3 строки с конкретными row positions.
4. Только теперь прочитать product_title, review_headline, review_body — но только для этих 3 строк.

Когда срабатывает оптимизация

Lazy materialization применяется для запросов конкретной формы:

Главные условия:

• Есть ORDER BY или LIMIT N с детерминированным порядком.
• В SELECT нет агрегатных функций, GROUP BY, window functions.
• Запрос не идёт через Distributed-таблицу (см. ограничения ниже).
• N в LIMIT не превышает порог query_plan_max_limit_for_lazy_materialization.

Lazy materialization vs. PREWHERE

Это две разные оптимизации, которые дополняют друг друга, а не заменяют:

Порядок при их совместном применении:

1. PREWHERE-колонки читаются первыми, фильтр применяется.
2. Сортировочная колонка читается для строк, прошедших PREWHERE.
3. ORDER BY + LIMIT N оставляет N row positions.
4. Тяжёлые SELECT-колонки дочитываются для этих N строк.

Настройки

Оптимизация управляется через query plan settings:

-- Включить lazy materialization (по умолчанию = 1 в 25.4+)
SET query_plan_optimize_lazy_materialization = 1;

-- Порог LIMIT, до которого применяется оптимизация
-- В 25.4 default = 10, в 25.12+ default увеличен до 10000
SET query_plan_max_limit_for_lazy_materialization = 10000;

Логика порога: для очень больших LIMIT (например, 100000) дополнительный random-access I/O при дочитке тяжёлых колонок может перевесить экономию. Поэтому при LIMIT выше порога ClickHouse возвращается к eager-чтению.

-- Полностью выключить (для отладки или fallback)
SET query_plan_optimize_lazy_materialization = 0;

Подтверждение через EXPLAIN

Самый надёжный способ убедиться, что оптимизация применена — посмотреть план запроса с actions = 1:

EXPLAIN actions = 1
SELECT helpful_votes, product_title, review_headline, review_body
FROM amazon.amazon_reviews
ORDER BY helpful_votes DESC
LIMIT 3
SETTINGS query_plan_optimize_lazy_materialization = 1;

В выводе появится секция вида:

Lazily read columns: product_title, review_headline, review_body

Это значит: на уровне ReadFromMergeTree из диска поднимается только helpful_votes, а перечисленные колонки помечены как lazy и будут материализованы позже — после LIMIT.

Если оптимизация не применилась, такой строки не будет, и в плане появится обычный ReadFromMergeTree со всеми колонками сразу.

Метрики через query_log

После выполнения запроса можно сравнить I/O и память:

SELECT
    query_duration_ms,
    formatReadableSize(memory_usage) AS memory,
    formatReadableSize(read_bytes) AS read_bytes,
    read_rows,
    Settings['query_plan_optimize_lazy_materialization'] AS lazy_setting
FROM system.query_log
WHERE query LIKE '%amazon_reviews%'
  AND type = 'QueryFinish'
ORDER BY event_time DESC
LIMIT 5;

Запустите запрос дважды — с query_plan_optimize_lazy_materialization = 0 и = 1. Разница в read_bytes и memory_usage покажет реальный эффект на ваших данных.

Ограничения

Lazy materialization не универсальна. Известные на момент 25.4 — 25.12 кейсы, когда оптимизация не работает или работает с проблемами:

Сравнение: до и после

Полный пример с двумя запусками:

-- 1. Без lazy materialization (как было до 25.4)
SELECT helpful_votes, product_title, review_headline, review_body
FROM amazon.amazon_reviews
ORDER BY helpful_votes DESC
LIMIT 3
SETTINGS query_plan_optimize_lazy_materialization = 0;

-- Результат блог-поста: ~219 сек, 71 GB прочитано, 1.11 GiB RAM

-- 2. С lazy materialization (default в 25.4+)
SELECT helpful_votes, product_title, review_headline, review_body
FROM amazon.amazon_reviews
ORDER BY helpful_votes DESC
LIMIT 3
SETTINGS query_plan_optimize_lazy_materialization = 1;

-- Результат блог-поста: ~0.139 сек, 1.81 GB прочитано, 3.80 MiB RAM

Разница 1576x — не теоретический максимум, а измеренный benchmark на публичном датасете. На ваших данных выигрыш зависит от ширины таблицы, размера тяжёлых колонок и LIMIT.

Когда оптимизация не помогает

Lazy materialization не даст заметного выигрыша если:

• Все колонки SELECT — узкие числа (UInt32, Float64) и таблица не очень широкая.
• LIMIT превышает query_plan_max_limit_for_lazy_materialization.
• В запросе есть GROUP BY, JOIN или window functions — оптимизация просто не применится.
• Запрос идёт через Distributed без обращения к локальной таблице.
• Таблица очень маленькая — там и без оптимизации всё быстро.

Ключевые выводы

1. Lazy materialization (25.4+) откладывает чтение тяжёлых колонок до момента после ORDER BY + LIMIT, читая их только для финальных N строк.
2. Реальный benchmark ClickHouse на Amazon reviews — 1576x speedup, 40x меньше I/O, 300x меньше памяти на запросе SELECT * … ORDER BY … LIMIT 3.
3. Не заменяет PREWHERE — это разные оптимизации: PREWHERE отсекает строки до чтения остальных колонок, lazy materialization откладывает чтение тяжёлых колонок до после LIMIT. Они работают вместе.
4. Настройки: query_plan_optimize_lazy_materialization = 1 (default), query_plan_max_limit_for_lazy_materialization (default 10 в 25.4, 10000 в 25.12+).
5. Проверка: EXPLAIN actions = 1 показывает строку Lazily read columns: ... для отложенных колонок.
6. Ограничения: не работает для GROUP BY, JOIN, window functions, Distributed, mutations; известны баги на проекциях.