Перейти к основному содержимому
Перейти к основному содержимому

Ограничения на сложность запросов

Ограничения на сложность запросов являются частью настроек. Они используются для обеспечения более безопасного выполнения из пользовательского интерфейса. Почти все ограничения применяются только к SELECT. Для распределенной обработки запросов ограничения применяются на каждом сервере отдельно.

ClickHouse проверяет ограничения для частей данных, а не для каждой строки. Это означает, что вы можете превысить значение ограничения по размеру части данных.

Ограничения на "максимальное количество чего-либо" могут принимать значение 0, что означает "неограничено". Большинство ограничений также имеют настройку 'overflow_mode', определяющую, что делать, когда предельное значение превышено. Она может принимать одно из двух значений: throw или break. Ограничения на агрегацию (group_by_overflow_mode) также имеют значение any.

throw – Выдать исключение (по умолчанию).

break – Остановить выполнение запроса и вернуть частичный результат, как если бы исходные данные закончились.

any (только для group_by_overflow_mode) – Продолжать агрегацию для ключей, попавших в набор, но не добавлять новые ключи в набор.

max_memory_usage

Максимальное количество ОЗУ, которое можно использовать для выполнения запроса на одном сервере.

Настройка по умолчанию – неограниченная (установлена в 0).

Значение по умолчанию в облаке: зависит от объема ОЗУ на реплике.

Настройка не учитывает объем доступной памяти или общий объем памяти на машине. Ограничение применяется к одному запросу на одном сервере. Вы можете использовать SHOW PROCESSLIST, чтобы увидеть текущее потребление памяти для каждого запроса. Кроме того, пик потребления памяти отслеживается для каждого запроса и записывается в журнал.

Потребление памяти не отслеживается для состояний некоторых агрегатных функций.

Потребление памяти также ограничивается параметрами max_memory_usage_for_user и max_server_memory_usage.

max_memory_usage_for_user

Максимальное количество ОЗУ, которое можно использовать для выполнения запросов пользователей на одном сервере.

Значения по умолчанию определены в Settings.h. По умолчанию объем не ограничен (max_memory_usage_for_user = 0).

Смотрите также описание max_memory_usage.

Например, если вы хотите установить max_memory_usage_for_user на 1000 байт для пользователя с именем clickhouse_read, вы можете использовать следующую команду:

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

max_rows_to_read

Следующие ограничения могут проверяться на каждом блоке (вместо каждой строки). То есть ограничения могут быть нарушены незначительно.

Максимальное количество строк, которые могут быть прочитаны из таблицы при выполнении запроса.

max_bytes_to_read

Максимальное количество байт (несжатых данных), которые могут быть прочитаны из таблицы при выполнении запроса.

read_overflow_mode

Что делать, когда объем считанных данных превышает одно из ограничений: 'throw' или 'break'. По умолчанию, throw.

max_rows_to_read_leaf

Следующие ограничения могут проверяться на каждом блоке (вместо каждой строки). То есть ограничения могут быть нарушены незначительно.

Максимальное количество строк, которые могут быть прочитаны из локальной таблицы на узле-листе при выполнении распределенного запроса. В то время как распределенные запросы могут выполнять множество подзапросов к каждому шард (лист) – это ограничение будет проверяться только на этапе чтения на узловых листьях и игнорироваться на этапе объединения результатов на корневом узле. Например, кластер состоит из 2 шардов и каждый шард содержит таблицу с 100 строками. Тогда распределенный запрос, который должен прочитать все данные из обеих таблиц с настройкой max_rows_to_read=150 не выполнится, так как всего будет 200 строк. В то время как запрос с max_rows_to_read_leaf=150 выполнится, поскольку узловые листья будут читать максимум 100 строк.

max_bytes_to_read_leaf

Максимальное количество байт (несжатых данных), которые могут быть прочитаны из локальной таблицы на узле-листе при выполнении распределенного запроса. Хотя распределенные запросы могут выполнять множество подзапросов к каждому шард (лист) – это ограничение будет проверяться только на этапе чтения на узловых листьях и игнорироваться на этапе объединения результатов на корневом узле. Например, кластеризуется из 2 шардов и каждый шард содержит таблицу с 100 байтами данных. Тогда распределенный запрос, который должен прочитать все данные из обеих таблиц с настройкой max_bytes_to_read=150, не выполнится, так как всего будет 200 байт. В то время как запрос с max_bytes_to_read_leaf=150 выполнится, так как узловые листья будут читать максимум 100 байт.

read_overflow_mode_leaf

Что делать, когда объем считанных данных превышает одно из ограничений для листа: 'throw' или 'break'. По умолчанию, throw.

max_rows_to_group_by

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

group_by_overflow_mode

Что делать, когда количество уникальных ключей для агрегации превышает лимит: 'throw', 'break' или 'any'. По умолчанию, throw. Использование значения 'any' позволяет выполнить аппроксимацию GROUP BY. Качество этой аппроксимации зависит от статистической природы данных.

max_bytes_before_external_group_by

Включает или отключает выполнение операторов GROUP BY во внешней памяти. Смотрите GROUP BY во внешней памяти.

Возможные значения:

  • Максимальный объем ОЗУ (в байтах), который может быть использован одним GROUP BY оператором.
  • 0 — GROUP BY во внешней памяти отключен.

Значение по умолчанию: 0.

Значение по умолчанию в облаке: половина объема памяти на реплику.

max_bytes_ratio_before_external_group_by

Соотношение доступной памяти, разрешенной для GROUP BY, при достижении которого используется внешняя память для агрегации.

Например, если установить на 0.6, GROUP BY позволит использовать 60% доступной памяти (на сервер/user/слияния) в начале выполнения, после этого начнет использовать внешнюю агрегацию.

Значение по умолчанию: 0.5.

max_bytes_before_external_sort

Включает или отключает выполнение операторов ORDER BY во внешней памяти. Смотрите Подробности реализации ORDER BY

  • Максимальный объем ОЗУ (в байтах), который может быть использован одним ORDER BY оператором. Рекомендуемое значение – половина доступной системной памяти.
  • 0 — ORDER BY во внешней памяти отключен.

Значение по умолчанию: 0.

Значение по умолчанию в облаке: половина объема памяти на реплику.

max_bytes_ratio_before_external_sort

Соотношение доступной памяти, разрешенной для ORDER BY, при достижении которого используется внешняя сортировка.

Например, если установить на 0.6, ORDER BY позволит использовать 60% доступной памяти (на сервер/user/слияния) в начале выполнения, после этого начнет использовать внешнюю сортировку.

Значение по умолчанию: 0.5.

max_rows_to_sort

Максимальное количество строк перед сортировкой. Это позволяет ограничить потребление памяти при сортировке.

max_bytes_to_sort

Максимальное количество байт перед сортировкой.

sort_overflow_mode

Что делать, если количество строк, полученных перед сортировкой, превышает одно из ограничений: 'throw' или 'break'. По умолчанию, throw.

max_result_rows

Ограничение на количество строк в результате. Также проверяется для подзапросов и на удаленных серверах при выполнении частей распределенного запроса. Ограничение не применяется, когда значение равно 0.

Значение по умолчанию: 0.

Значение по умолчанию в облаке: 0.

max_result_bytes

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

result_overflow_mode

Что делать, если объем результата превышает одно из ограничений: 'throw' или 'break'.

Использование 'break' похоже на использование LIMIT. Break прерывает выполнение только на уровне блока. Это означает, что количество возвращаемых строк превышает max_result_rows, кратное max_block_size и зависит от max_threads.

Значение по умолчанию: throw.

Значение по умолчанию в облаке: throw.

Пример:

Результат:

max_execution_time

Максимальное время выполнения запроса в секундах. На данный момент оно не проверяется для одной из фаз сортировки или при слиянии и финализации агрегатных функций.

Параметр max_execution_time может быть немного сложным для понимания. Он работает на основе интерполяции относительно текущей скорости выполнения запроса (это поведение контролируется timeout_before_checking_execution_speed). ClickHouse остановит запрос, если предполагаемое время выполнения превышает указанное max_execution_time. По умолчанию, timeout_before_checking_execution_speed установлен на 10 секунд. Это означает, что после 10 секунд выполнения запроса ClickHouse начнет оценивать общее время выполнения. Если, например, max_execution_time установлен на 3600 секунд (1 час), ClickHouse завершит запрос, если предполагаемое время превышает этот лимит в 3600 секунд. Если вы установите timeout_before_checking_execution_speed на 0, ClickHouse будет использовать реальное время как основу для max_execution_time.

timeout_overflow_mode

Что делать, если запрос выполняется дольше max_execution_time или предполагаемое время выполнения больше, чем max_estimated_execution_time: throw или break. По умолчанию, throw.

max_execution_time_leaf

Сходная семантика с max_execution_time, но применяется только на узле-листе для распределенных или удаленных запросов.

Например, если мы хотим ограничить время выполнения на узле-листе до 10s, но без ограничения на начальном узле, вместо наличия max_execution_time в настройках вложенного подзапроса:

Мы можем использовать max_execution_time_leaf как настройки запроса:

timeout_overflow_mode_leaf

Что делать, когда запрос на узле-листе выполняется дольше max_execution_time_leaf: throw или break. По умолчанию, throw.

min_execution_speed

Минимальная скорость выполнения в строках в секунду. Проверяется на каждом блоке данных, когда истекает 'timeout_before_checking_execution_speed'. Если скорость выполнения ниже, выбрасывается исключение.

min_execution_speed_bytes

Минимальное количество выполняемых байт в секунду. Проверяется на каждом блоке данных, когда истекает 'timeout_before_checking_execution_speed'. Если скорость выполнения ниже, выбрасывается исключение.

max_execution_speed

Максимальное количество строк выполнения в секунду. Проверяется на каждом блоке данных, когда истекает 'timeout_before_checking_execution_speed'. Если скорость выполнения высокая, она будет уменьшена.

max_execution_speed_bytes

Максимальное количество выполняемых байт в секунду. Проверяется на каждом блоке данных, когда истекает 'timeout_before_checking_execution_speed'. Если скорость выполнения высокая, она будет уменьшена.

timeout_before_checking_execution_speed

Проверяет, что скорость выполнения не слишком низкая (не меньше 'min_execution_speed'), после того как истекло указанное время в секундах.

max_estimated_execution_time

Максимальное предполагаемое время выполнения запроса в секундах. Проверяется на каждом блоке данных, когда истекает 'timeout_before_checking_execution_speed'.

max_columns_to_read

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

max_temporary_columns

Максимальное количество временных колонок, которые должны быть сохранены в ОЗУ одновременно при выполнении запроса, включая постоянные колонки. Если временных колонок больше, чем это количество, выбрасывается исключение.

max_temporary_non_const_columns

То же самое, что и 'max_temporary_columns', но без учета постоянных колонок. Обратите внимание, что постоянные колонки формируются довольно часто при выполнении запроса, но они требуют практически нулевых вычислительных ресурсов.

max_subquery_depth

Максимальная глубина вложенности подзапросов. Если вложенность подзапросов превышает, выбрасывается исключение. По умолчанию 100.

max_pipeline_depth

Максимальная глубина конвейера. Соответствует количеству преобразований, через которые проходит каждый блок данных во время обработки запроса. Считается в пределах одного сервера. Если глубина конвейера больше, выбрасывается исключение. По умолчанию 1000.

max_ast_depth

Максимальная глубина вложенности синтаксического дерева запроса. Если превышена, выбрасывается исключение. На данный момент она не проверяется во время разбора, а только после разбора запроса. То есть слишком глубокое синтаксическое дерево может быть создано во время разбора, но запрос завершится неудачно. По умолчанию 1000.

max_ast_elements

Максимальное количество элементов в синтаксическом дереве запроса. Если превышено, выбрасывается исключение. Аналогично предыдущей настройке, она проверяется только после разбора запроса. По умолчанию 50 000.

max_rows_in_set

Максимальное количество строк для набора данных в операторе IN, созданном из подзапроса.

max_bytes_in_set

Максимальное количество байт (несжатых данных), использованных набором в операторе IN, созданным из подзапроса.

set_overflow_mode

Что делать, когда объем данных превышает одно из ограничений: 'throw' или 'break'. По умолчанию, throw.

max_rows_in_distinct

Максимальное количество различных строк при использовании DISTINCT.

max_bytes_in_distinct

Максимальное количество байт, использованных хэш-таблицей при использовании DISTINCT.

distinct_overflow_mode

Что делать, когда объем данных превышает одно из ограничений: 'throw' или 'break'. По умолчанию, throw.

max_rows_to_transfer

Максимальное количество строк, которые могут быть переданы на удаленный сервер или сохранены во временной таблице при использовании GLOBAL IN.

max_bytes_to_transfer

Максимальное количество байт (несжатых данных), которые могут быть переданы на удаленный сервер или сохранены во временной таблице при использовании GLOBAL IN.

transfer_overflow_mode

Что делать, когда объем данных превышает одно из ограничений: 'throw' или 'break'. По умолчанию, throw.

max_rows_in_join

Ограничивает количество строк в хэш-таблице, которая используется при объединении таблиц.

Эта настройка применяется к SELECT ... JOIN операциям и таблице Join.

Если запрос содержит несколько объединений, ClickHouse проверяет эту настройку для каждого промежуточного результата.

ClickHouse может предпринять разные действия, когда предел будет достигнут. Используйте настройку join_overflow_mode, чтобы выбрать действие.

Возможные значения:

  • Положительное целое число.
  • 0 — Неограниченное количество строк.

Значение по умолчанию: 0.

max_bytes_in_join

Ограничивает размер в байтах хэш-таблицы, используемой при объединении таблиц.

Эта настройка применяется к SELECT ... JOIN операциям и таблице Join.

Если запрос содержит объединения, ClickHouse проверяет эту настройку для каждого промежуточного результата.

ClickHouse может предпринять разные действия, когда предел будет достигнут. Используйте настройки join_overflow_mode, чтобы выбрать действие.

Возможные значения:

  • Положительное целое число.
  • 0 — Контроль памяти отключен.

Значение по умолчанию: 0.

join_overflow_mode

Определяет, какое действие выполняет ClickHouse, когда достигнется любое из следующих ограничений для объединения:

Возможные значения:

  • THROW — ClickHouse выдает исключение и прерывает операцию.
  • BREAK — ClickHouse прерывает операцию и не выбрасывает исключение.

Значение по умолчанию: THROW.

Смотрите также

max_partitions_per_insert_block

Ограничивает максимальное количество партиций в одном вставляемом блоке.

  • Положительное целое число.
  • 0 — Неограниченное количество партиций.

Значение по умолчанию: 100.

Подробности

При вставке данных ClickHouse вычисляет количество партиций в вставляемом блоке. Если количество партиций больше max_partitions_per_insert_block, ClickHouse либо регистрирует предупреждение, либо выдает исключение в зависимости от throw_on_max_partitions_per_insert_block. Исключения имеют следующий текст:

"Слишком много партиций для одного INSERT блока (partitions_count партиций, лимит — " + toString(max_partitions) + "). Лимит контролируется настройкой 'max_partitions_per_insert_block'. Большое количество партиций — это общая ошибка. Это приведет к серьезному негативному влиянию на производительность, включая медленный запуск сервера, медленные запросы INSERT и медленные запросы SELECT. Рекомендуемое общее количество партиций для таблицы — менее 1000..10000. Обратите внимание, что партиционирование не предназначено для ускорения запросов SELECT (ORDER BY ключа достаточно, чтобы сделать диапазонные запросы быстрыми). Партиции предназначены для манипуляции данными (DROP PARTITION и др.)."

throw_on_max_partitions_per_insert_block

Позволяет вам контролировать поведение при достижении max_partitions_per_insert_block.

  • true - Когда блок вставки достигает max_partitions_per_insert_block, то выдается исключение.
  • false - Регистрирует предупреждение, когда достигается max_partitions_per_insert_block.

Значение по умолчанию: true

max_temporary_data_on_disk_size_for_user

Максимальное количество данных, потребляемых временными файлами на диске в байтах для всех одновременно выполняемых пользовательских запросов. Ноль означает неограниченно.

Значение по умолчанию: 0.

max_temporary_data_on_disk_size_for_query

Максимальное количество данных, потребляемых временными файлами на диске в байтах для всех одновременно выполняемых запросов. Ноль означает неограниченно.

Значение по умолчанию: 0.

max_sessions_for_user

Максимальное количество одновременных сессий для каждого аутентифицированного пользователя на сервере ClickHouse.

Пример:

Значение по умолчанию: 0 (неограниченное количество одновременных сессий).

max_partitions_to_read

Ограничивает максимальное количество партиций, которые можно получить в одном запросе.

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

Возможные значения:

  • Любое положительное целое число.

Значение по умолчанию: -1 (неограниченное).

Вы также можете указать настройку MergeTree max_partitions_to_read в настройках таблиц.