Наступил сентябрь, и вышел ClickHouse 26.9 с очередной порцией новых функций.
Релиз ClickHouse 26.9 содержит 56 новых функций 🍁, 135 оптимизаций производительности 🍎 и 464 исправления ошибок 🐿️.
Этот выпуск добавляет условные границы для LIMIT, инкрементальные обновления для материализованных представлений типа append-only и выгрузку на диск для запросов DISTINCT с высокой кардинальностью.
Мы также рассмотрим токены доступа с ограничением по времени, ускоренные запросы min, max и count, расширенную поддержку PromQL и несколько улучшений для удобства использования.
Особое приветствие всем новым участникам разработки в версии 26.9! Рост сообщества ClickHouse впечатляет, и мы всегда благодарны за вклад, который сделал ClickHouse таким популярным.
Ниже приведены имена новых участников:
Aaron Harlap, Actuele AI, Alex Francoeur, Alex Prabhat Bara, AlexF, Anand Kumar Shaw, Anton Kovalenko, Aparajita Pandey, Brandon Pereira, Claude, Denys Stetsenko, Dmitrii Bezrukov, Evandro Leopoldino Gonçalves, Friedrich ten Hagen, George Viamontes, Gülçin Yıldırım Jelinek, Hamza Wasim, Hank Hoffmeier, Héctor Pablos, Itamar Tempelhof, Ivan N. Taranov, Ivan Tkachev, Ivan Tkatchev, Jithin Zachariah, Jordan Bertasso, Jords, Joshua, Juanjo, Kelly Toole, Lucas, Luis Neves, Luís Lizardo, Marat Dulin, Mike Shi, Navneet Kumar, Pablo Francisco Pérez Hidalgo, Paul Annesley, Philip Li, Pratham Nayak, Pratheesh, SamWolfberg, Sankalp Thakur, Sebastian Vercruyssse, Serhiy Bzhezytskyy, Takayuki Enomoto, Thien Phan, Vadim Ilves, XanderYoon, Yongqiang Tian, alexprabhat99, anand-tradesea, aparajita, bakhtiiartashbolotov, cuishuang, jithinzac, kasimtj, key-arg, kyungryun, linsen, maederm, mariahlynnenagy, miao tang, mosya415, ngagejason, sakshichitnis27, sleepingeight, statxc, t, tars, zhanglangning
Подсказка: если вам интересно, как мы формируем этот список… здесь.
Вы также можете посмотреть слайды презентации.
Начиная с ClickHouse 26.9, вы можете использовать значения Time в качестве смещений при сложении или вычитании со значениями DateTime. Результат сохраняет часовой пояс значения DateTime.
Давайте рассмотрим несколько простых примеров:
Если вычисление выходит за пределы диапазона, поддерживаемого типом результата, параметр date_time_overflow_behavior определяет, будет ли ClickHouse выдавать исключение, ограничивать результат ближайшей границей или оставлять переполнение без проверки.
Максимальное значение, которое мы можем хранить в DateTime, — 2106-02-07 06:28:15. Посмотрим, что произойдет, если мы добавим одну секунду к этому времени:
Произошло переполнение до минимального значения DateTime, что ожидаемо, так как значение по умолчанию для date_time_overflow_behavior — ignore. Но, возможно, мы предпочтем получить исключение, если значение переполняется:
Или мы можем использовать saturate, и в этом случае будет возвращено максимальное значение для этого типа:
Наконец, давайте проверим часовой пояс исходных и вычисленных значений:
ClickHouse 26.9 расширяет поддержку PromQL за счет новых функций, дополнительных эндпоинтов Prometheus HTTP API и прямых SELECT-запросов к таблицам TimeSeries.
PromQL и движок таблиц TimeSeries теперь доступны в рамках закрытого превью в ClickHouse Cloud, что позволяет хранить метрики в ClickHouse и запрашивать их из ClickStack, Grafana, clickhouse-client или SQL.
Вы можете узнать больше в блоге «Представляем новый движок TimeSeries для ClickHouse».
ClickHouse 26.9 представляет CREATE TOKEN, что позволяет пользователю создавать учетные данные с ограничением по времени для приложений, скриптов, CI-заданий и агентов, не раскрывая и не заменяя основной пароль.
Токен может быть ограничен подмножеством существующих привилегий пользователя, что снижает ущерб в случае утечки учетных данных.
Посмотрим, как это работает. Сначала создадим небольшую таблицу:
Затем создадим пользователя по имени alexey:
У alexey есть права SELECT и INSERT для этой таблицы, а также возможность создавать токен для себя.
Далее подключимся как alexey и создадим токен, который действует 30 дней и может выполнять только SELECT-запросы к нашей таблице ourTable:
Оператор возвращает сгенерированный токен и срок его действия:
ClickHouse отображает токен только один раз, поэтому обязательно скопируйте его.
Затем мы можем подключиться с помощью токена и выполнить SELECT-запрос:
Все работает отлично, как мы и ожидали. Но что, если мы попытаемся выполнить вставку в таблицу, используя наш токен?
Это не работает, так как у alexey есть только доступ SELECT при аутентификации с помощью токена.
Токен никогда не предоставляет больше привилегий, чем уже есть у пользователя, и перестает работать по истечении срока действия или при удалении пользователя. Если вы не укажете VALID UNTIL или VALID FOR, время жизни по умолчанию составит 30 минут.
ClickHouse 26.9 расширяет LIMIT граничными условиями, которые начинают и останавливают вывод на основе значений в упорядоченном потоке результатов — возможность, которая, насколько нам известно, в настоящее время недоступна ни в одной другой базе данных.
- AFTER включает строку, соответствующую условию.
- UNTIL останавливается перед соответствующей строкой.
- Вы можете добавить ALL, чтобы применять границу каждый раз, когда условие совпадает.
Попробуйте различные комбинации ниже, чтобы увидеть, какие строки возвращает каждый запрос.
Эта функциональность особенно полезна для анализа логов, поэтому давайте изучим набор данных Nginx, использованный в блоге «Сжатие логов nginx в 170 раз с помощью колоночного хранилища».
Сначала создадим таблицу:
Затем загрузим данные:
Теперь получим краткий обзор данных.
Следующий запрос начинается с первого ответа `5xx` и возвращает пять запросов. AFTER является инклюзивным, поэтому запрос, удовлетворяющий условию, включается.
UNTIL является эксклюзивным. Этот запрос начинается с первой ошибки сервера и останавливается перед первым ответом со статусом ниже 500:
Граница AFTER применяется только один раз, если мы не используем ALL, которая повторно применяет её всякий раз, когда совпадает другая строка. Этот запрос возвращает каждую ошибку сервера и следующие два запроса после неё:
В этот период есть три отдельных инцидента в строках 2, 7 и 12. Внутри каждого всплеска каждые 500 ответов повторно применяют трехстрочную границу.
Таким образом, последовательные сбои расширяют активное окно до тех пор, пока после последнего сбоя не произойдут два последовательных запроса, не являющихся 5xx. В этом примере оба являются успешными ответами 200.
ALL также может повторно применять начальную границу, в то время как UNTIL завершает каждый диапазон:
В отличие от предыдущего запроса, этот вывод исключает успешные запросы после каждого всплеска сбоев. UNTIL закрывает диапазон на первом ответе, не являющемся 5xx, в то время как ALL продолжает сканирование для следующего всплеска.
ClickHouse 26.9 добавляет APPEND INCREMENTAL к обновляемым материализованным представлениям. Вместо сканирования всей исходной таблицы при каждом обновлении, ClickHouse обрабатывает только строки, зафиксированные с момента предыдущего обновления.
Это можно использовать для инкрементального копирования данных типа append-only в другую таблицу ClickHouse или репликации потока событий из таблицы MergeTree в озеро данных Iceberg.
Давайте посмотрим, как использовать эту функцию с Iceberg.
Мы создадим поток событий заказов типа append-only в ClickHouse и периодически будем копировать их в таблицу Iceberg, демонстрируя, что каждое обновление обрабатывает только недавно зафиксированные строки.
Сначала создадим нашу таблицу ClickHouse:
Столбцы block-number и block-offset предоставляют курсор, который ClickHouse использует для идентификации строк, зафиксированных после предыдущего обновления.
Далее мы включим вставки в Iceberg и создадим таблицу Iceberg в моей локальной файловой системе:
Каталог lake_order_events содержит метаданные Iceberg, манифесты и файлы данных Parquet.
Наконец, мы создадим материализованное представление, которое будет копировать недавно зафиксированные события в Iceberg каждый час:
Пришло время загрузить немного данных!
Эти события будут скопированы в таблицу Iceberg, когда материализованное представление будет срабатывать каждый час, но чтобы ускорить процесс, мы запустим обновление вручную:
И если мы сделаем запрос к таблице Iceberg:
Все записи были успешно перенесены. Теперь давайте добавим еще несколько строк, чтобы имитировать изменения в этих заказах:
Мы снова вручную обновим материализованное представление, а затем снова сделаем запрос к таблице Iceberg:
Мы видим, что три новых события на месте.
Для целевой таблицы Iceberg ClickHouse хранит инкрементальный курсор в сводке снимка (snapshot summary). Таким образом, курсор и недавно добавленные данные фиксируются как часть одного и того же снимка Iceberg. Мы можем запросить system.iceberg_history, чтобы увидеть это:
Первое обновление добавило четыре записи, в то время как второе добавило только три новых события, увеличив общее количество с четырех до семи. Мы также видим, что оба снимка содержат курсор обновления.
ClickHouse хранит этот курсор в снимке Iceberg вместе с недавно добавленными данными. Если ClickHouse перезапустится, следующее обновление возобновится с этой позиции, а не будет повторять те же события. Курсор продвигается только тогда, когда добавление проходит успешно, поэтому он всегда остается синхронизированным с данными.
Этот подход лучше всего работает с данными, предназначенными только для добавления (append-only), такими как события, журналы, записи аудита и другие неизменяемые факты.
ClickHouse хранит минимальные и максимальные значения для числовых столбцов в каждой части данных. Начиная с версии 26.9, он может использовать эту статистику для ответов на запросы min, max и count без чтения данных базового столбца.
Давайте попробуем это на таблице журналов Nginx, которую мы использовали ранее. Мы будем использовать response_bytes вместо timestamp. Поскольку timestamp является первым столбцом в ключе сортировки таблицы, ClickHouse уже может ответить на этот запрос, используя существующие метаданные.
Мы добавим префикс EXPLAIN к нашему запросу, чтобы увидеть план выполнения:
Если мы посмотрим на последнюю строку, то увидим, что вместо чтения столбца response_bytes ClickHouse подготавливает результат на основе статистики столбца.
Мы можем отключить эту оптимизацию с помощью настройки use_statistics_for_min_max_aggregation, и теперь ClickHouse должен будет просканировать столбец response_bytes для вычисления результата, как показано в следующем запросе:
В ClickHouse 26.9 появилась новая системная таблица system.session_query_ids, которая отслеживает все идентификаторы запросов в текущем сеансе в порядке их выполнения.
Мы можем сделать запрос к этой таблице следующим образом:
Таблица system.query_log включает query_id для каждой записи, что означает, что теперь мы можем проверить, какие запросы мы только что выполнили, без необходимости вручную указывать идентификаторы запросов при обращении к этой таблице:
ClickHouse 26.9 позволяет устанавливать ограничения на то, насколько большой может стать отдельная таблица, а также на то, сколько таблиц можно создать в базе данных.
Это полезно для многопользовательских, временных и демонстрационных сред, где мы не хотим, чтобы одна рабочая нагрузка потребляла все ресурсы.
Начнем с создания таблицы, которая может содержать максимум три строки:
Мы вставим три строки:
Если мы вставим еще одну строку, она все равно будет успешно добавлена:
Лимит проверяется относительно текущего размера таблицы при запуске INSERT. Это означает, что операция INSERT, которая увеличивает количество строк в таблице с трех до четырех, может завершиться. Следующий INSERT видит, что таблица уже превысила лимит, и отклоняется:
Мы также можем ограничить таблицу по ее сжатому или несжатому размеру, используя max_table_size_bytes_compressed и max_table_size_bytes_uncompressed.
Мы также можем установить ограничение на количество таблиц в базе данных. Давайте создадим базу данных, которая может содержать две таблицы:
Мы можем создать первые две таблицы как обычно:
Но если мы попытаемся создать третью таблицу, ClickHouse отклонит ее:
Концептуально DISTINCT должен отслеживать значения, которые он уже видел. В ClickHouse есть несколько оптимизаций, которые сокращают эту работу, но запрос с высокой кардинальностью все равно может потребовать поддержания большого набора данных в оперативной памяти.
ClickHouse 26.9 может выгружать этот хеш-набор на диск, точно так же, как GROUP BY и ORDER BY, вместо того чтобы позволять ему расти до тех пор, пока в запросе не закончится память.
Давайте посмотрим, как это выглядит, вернув все уникальные значения в последовательности из 100 миллионов чисел, используя max_memory_usage для ограничения запроса 150 МБ памяти:
Запрос не может быть обработан, так как недостаточно памяти. Мы можем разрешить DISTINCT выгружать свое промежуточное состояние на диск, установив max_bytes_before_external_distinct:
В этот раз ClickHouse начинает записывать данные DISTINCT во временные файлы, когда достигает примерно 25 МБ. Весь запрос может использовать до 150 МБ, оставляя достаточно памяти для чтения и объединения этих файлов в конце.
Есть еще один важный момент, который следует учитывать при использовании этой функции. Выгрузка на диск снижает использование памяти, но не устраняет потребность в ней полностью. ClickHouse по-прежнему нуждается в памяти для буферов, конвейера запросов и объединения тех временных файлов, которые были выгружены на диск.
Давайте посмотрим, что произойдет, если мы уменьшим общий лимит памяти для запроса до 100 МБ, сохраняя порог выгрузки на диск на уровне 25 МБ:
Данные были успешно выгружены, но у ClickHouse закончилась память во время чтения временных файлов обратно. Мы можем понять по BufferingFromFileSource, что ошибка произошла во время обработки выгруженных файлов, а не во время создания исходного набора в памяти.
Чтобы исправить это, нам нужно увеличить max_memory_usage обратно до 150 МБ.
ClickHouse автоматически включает внешний DISTINCT, когда max_bytes_ratio_before_external_distinct установлен на 0.5. Это означает, что DISTINCT начинает выгрузку, когда достигает половины доступной памяти.
ClickHouse автоматически включает внешний DISTINCT, когда max_bytes_ratio_before_external_distinct установлен на 0.5. Это означает, что DISTINCT начинает выгрузку, когда достигает половины доступной памяти.
ClickHouse 26.9 добавляет синтаксис скобок для доступа к путям в значении JSON. Это упрощает написание вложенных путей для работы с ключами, содержащими такие символы, как точки или пробелы.
Давайте посмотрим, как это работает на примере в оперативной памяти:
