mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-11-14 11:33:46 +00:00
216 lines
16 KiB
Markdown
216 lines
16 KiB
Markdown
# Ограничения на сложность запроса
|
||
|
||
Ограничения на сложность запроса - часть настроек.
|
||
Используются, чтобы обеспечить более безопасное исполнение запросов из пользовательского интерфейса.
|
||
Почти все ограничения действуют только на SELECT-ы.
|
||
При распределённой обработке запроса, ограничения действуют на каждом сервере по-отдельности.
|
||
|
||
Ограничения проверяются на каждый блок обработанных данных, а не на каждую строку. В связи с этим, ограничения могут быть превышены на размер блока.
|
||
|
||
Ограничения вида "максимальное количество чего-нибудь" могут принимать значение 0, которое обозначает "не ограничено".
|
||
Для большинства ограничений также присутствует настройка вида overflow_mode - что делать, когда ограничение превышено.
|
||
Оно может принимать одно из двух значений: `throw` или `break`; а для ограничения на агрегацию (group_by_overflow_mode) есть ещё значение `any`.
|
||
|
||
`throw` - кинуть исключение (по умолчанию).
|
||
|
||
`break` - прервать выполнение запроса и вернуть неполный результат, как будто исходные данные закончились.
|
||
|
||
`any (только для group_by_overflow_mode)` - продолжить агрегацию по ключам, которые успели войти в набор, но не добавлять новые ключи в набор.
|
||
|
||
## max_memory_usage {#settings_max_memory_usage}
|
||
|
||
Максимальный возможный объем оперативной памяти для выполнения запроса на одном сервере.
|
||
|
||
В конфигурационном файле по умолчанию, ограничение равно 10 ГБ.
|
||
|
||
Настройка не учитывает объём свободной памяти или общий объём памяти на машине.
|
||
Ограничение действует на один запрос, в пределах одного сервера.
|
||
Текущее потребление памяти для каждого запроса можно посмотреть с помощью `SHOW PROCESSLIST`.
|
||
Также отслеживается и выводится в лог пиковое потребление памяти для каждого запроса.
|
||
|
||
Потребление памяти не отслеживается для состояний некоторых агрегатных функций.
|
||
|
||
Потребление памяти не полностью учитывается для состояний агрегатных функций `min`, `max`, `any`, `anyLast`, `argMin`, `argMax` от аргументов `String` и `Array`.
|
||
|
||
Потребление памяти ограничивается также параметрами `max_memory_usage_for_user` и `max_memory_usage_for_all_queries`.
|
||
|
||
## max_memory_usage_for_user
|
||
|
||
Максимальный возможный объем оперативной памяти для запросов пользователя на одном сервере.
|
||
|
||
Значения по умолчанию определены в файле [Settings.h](https://github.com/yandex/ClickHouse/blob/master/dbms/src/Core/Settings.h#L288). По умолчанию размер не ограничен (`max_memory_usage_for_user = 0`).
|
||
|
||
Смотрите также описание настройки [max_memory_usage](#settings_max_memory_usage).
|
||
|
||
## max_memory_usage_for_all_queries
|
||
|
||
Максимальный возможный объем оперативной памяти для всех запросов на одном сервере.
|
||
|
||
Значения по умолчанию определены в файле [Settings.h](https://github.com/yandex/ClickHouse/blob/master/dbms/src/Core/Settings.h#L289). По умолчанию размер не ограничен (`max_memory_usage_for_all_queries = 0`).
|
||
|
||
Смотрите также описание настройки [max_memory_usage](#settings_max_memory_usage).
|
||
|
||
## max_rows_to_read
|
||
|
||
Следующие ограничения могут проверяться на каждый блок (а не на каждую строку). То есть, ограничения могут быть немного нарушены.
|
||
При выполнении запроса в несколько потоков, следующие ограничения действуют в каждом потоке по-отдельности.
|
||
|
||
Максимальное количество строчек, которое можно прочитать из таблицы при выполнении запроса.
|
||
|
||
## max_bytes_to_read
|
||
|
||
Максимальное количество байт (несжатых данных), которое можно прочитать из таблицы при выполнении запроса.
|
||
|
||
## read_overflow_mode
|
||
|
||
Что делать, когда количество прочитанных данных превысило одно из ограничений: throw или break. По умолчанию: throw.
|
||
|
||
## max_rows_to_group_by
|
||
|
||
Максимальное количество уникальных ключей, получаемых в процессе агрегации. Позволяет ограничить потребление оперативки при агрегации.
|
||
|
||
## group_by_overflow_mode
|
||
|
||
Что делать, когда количество уникальных ключей при агрегации превысило ограничение: throw, break или any. По умолчанию: throw.
|
||
Использование значения any позволяет выполнить GROUP BY приближённо. Качество такого приближённого вычисления сильно зависит от статистических свойств данных.
|
||
|
||
## max_rows_to_sort
|
||
|
||
Максимальное количество строк до сортировки. Позволяет ограничить потребление оперативки при сортировке.
|
||
|
||
## max_bytes_to_sort
|
||
|
||
Максимальное количество байт до сортировки.
|
||
|
||
## sort_overflow_mode
|
||
|
||
Что делать, если количество строк, полученное перед сортировкой, превысило одно из ограничений: throw или break. По умолчанию: throw.
|
||
|
||
## max_result_rows
|
||
|
||
Ограничение на количество строк результата. Проверяются также для подзапросов и на удалённых серверах при выполнении части распределённого запроса.
|
||
|
||
## max_result_bytes
|
||
|
||
Ограничение на количество байт результата. Аналогично.
|
||
|
||
## result_overflow_mode
|
||
|
||
Что делать, если объём результата превысил одно из ограничений: throw или break. По умолчанию: throw.
|
||
Использование break по смыслу похоже на LIMIT.
|
||
|
||
## max_execution_time
|
||
|
||
Максимальное время выполнения запроса в секундах.
|
||
На данный момент не проверяется при одной из стадий сортировки а также при слиянии и финализации агрегатных функций.
|
||
|
||
## timeout_overflow_mode
|
||
|
||
Что делать, если запрос выполняется дольше max_execution_time: 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_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_partitions_per_insert_block
|
||
|
||
Ограничивает максимальное количество партиций в одном вставленном блоке.
|
||
|
||
Возможные значения:
|
||
|
||
- Положительное целое число.
|
||
- 0 — неограниченное количество разделов.
|
||
|
||
Значение по умолчанию: 100.
|
||
|
||
**Подробности**
|
||
|
||
При вставке данных, ClickHouse вычисляет количество партиций во вставленном блоке. Если число партиций больше, чем `max_partitions_per_insert_block`, ClickHouse генерирует исключение со следующим текстом:
|
||
|
||
> "Too many partitions for single INSERT block (more than " + toString(max_parts) + "). The limit is controlled by 'max_partitions_per_insert_block' setting. Large number of partitions is a common misconception. It will lead to severe negative performance impact, including slow server startup, slow INSERT queries and slow SELECT queries. Recommended total number of partitions for a table is under 1000..10000. Please note, that partitioning is not intended to speed up SELECT queries (ORDER BY key is sufficient to make range queries fast). Partitions are intended for data manipulation (DROP PARTITION, etc)."
|
||
|
||
[Оригинальная статья](https://clickhouse.yandex/docs/ru/operations/settings/query_complexity/) <!--hide-->
|