Ограничения на сложность запросов
Ограничения на сложность запросов являются частью настроек.
Они используются для обеспечения более безопасного выполнения из пользовательского интерфейса.
Почти все ограничения применяются только к 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 в настройках таблиц.