ClickHouse 26.9 добавляет спиллинг и условный LIMIT

ClickHouse 26.9 вышел с 56 новыми возможностями и 135 оптимизациями производительности. Главные изменения касаются условных границ LIMIT, инкрементального обновления append-only materialized views и спиллинга на диск для DISTINCT-запросов с высокой кардинальностью. Эти функции снижают нагрузку на память и упрощают контроль доступа без внешних сервисов.

Условные границы LIMIT и инкрементальные представления

В релизе 26.9 появилась возможность задавать условные границы для LIMIT. Это позволяет останавливать выборку данных при выполнении заданных условий, а не фиксировать жёсткое число строк заранее. Инженеры получают более гибкий контроль над объёмом результатов, особенно когда точное количество записей заранее неизвестно. Такой подход полезен в сценариях, где данные поступают неравномерно, и заранее сложно определить, сколько строк потребуется для анализа. При принятии решения об обновлении важно оценить, насколько часто в текущих рабочих нагрузках возникает необходимость в динамической остановке запросов, поскольку это снижает риск избыточной обработки и перерасхода ресурсов.

Отдельно добавили инкрементальное обновление для append-only materialized views. Теперь при поступлении новых данных пересчитываются только добавленные порции, а не весь набор целиком. Это снижает время и ресурсы на поддержание отчётов, которые обновляются ежедневно или чаще. Термин append-only означает, что данные в представлении только добавляются, без изменений или удалений существующих записей. Инкрементальный механизм особенно ценен для команд, которые уже используют materialized views для регулярной аналитики, так как он позволяет избежать полного пересчёта при каждом обновлении. При этом важно проверить, что существующие представления действительно относятся к типу append-only, иначе инкрементальное обновление не применится. В противном случае придётся пересоздавать объекты или оставаться на предыдущей версии. Перед переходом стоит проанализировать текущие materialized views на предмет их структуры, чтобы понять, принесёт ли обновление реальную экономию времени и вычислительных мощностей.

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

Спиллинг DISTINCT и ускорение простых агрегатов

Для запросов с высокой кардинальностью DISTINCT теперь доступен спиллинг на диск. Когда данные не помещаются в оперативную память, ClickHouse автоматически переносит промежуточные результаты на жёсткий диск. Это предотвращает OOM-ошибки на серверах с ограниченным объёмом RAM при анализе логов или событий. Спиллинг помогает в случаях, когда кардинальность данных велика, например при подсчёте уникальных значений в больших наборах логов. Для решения об обновлении важно учитывать, что такая возможность снижает требования к объёму оперативной памяти, но увеличивает нагрузку на дисковую подсистему. Если кластер уже работает с запросами, где DISTINCT часто вызывает нехватку памяти, то спиллинг может стать ключевым фактором в пользу миграции.

Параллельно ускорили выполнение запросов min, max и count. Оптимизации затрагивают внутренние алгоритмы агрегации, поэтому прирост заметен даже без изменения запросов. В кластерах с большим количеством таких простых аналитических запросов это даёт ощутимое снижение задержек. Ускорение простых агрегатов полезно оценивать в контексте общей нагрузки: если min, max и count составляют значительную долю запросов, обновление может улучшить общую пропускную способность без дополнительных настроек.

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

Токены с ограниченным временем и расширения PromQL

В 26.9 ввели токены доступа с ограниченным сроком действия. Такие токены автоматически теряют силу после заданного момента, что упрощает выдачу временного доступа аналитикам или внешним подрядчикам. Настройка происходит через существующие механизмы управления пользователями без дополнительных сервисов. Это снижает риски долгосрочного доступа и упрощает аудит, поскольку нет необходимости в отдельной системе управления токенами. При оценке обновления важно понять, насколько текущие процессы выдачи доступа требуют временных ограничений и можно ли обойтись без внешних инструментов.

Также расширили поддержку PromQL. Теперь можно выполнять больше типов запросов метрик напрямую в ClickHouse, что полезно при миграции мониторинга с Prometheus. Ограничения остаются прежними: не все PromQL-функции реализованы полностью. Расширение поддержки помогает командам, которые хотят объединить хранение метрик и логов в одной системе, но требует проверки, покрывают ли новые возможности именно те запросы, которые используются в текущем мониторинге.

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

Практические ограничения при обновлении

Новые функции ориентированы на self-hosted-установки и не зависят от облачных компонентов. В российских инфраструктурах это важно, потому что позволяет сохранять данные внутри периметра и соблюдать требования по хранению. Спиллинг и инкрементальные представления особенно полезны на серверах со средним объёмом памяти, где раньше приходилось искусственно ограничивать запросы.

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

Источник

Это краткий разбор материала ClickHouse. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: ClickHouse 26.9 добавляет спиллинг и условный LIMIT.

Курс по теме — Построение DWH на ClickHouse