mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-11-14 03:25:15 +00:00
67c2e50331
* update presentations * CLICKHOUSE-2936: redirect from clickhouse.yandex.ru and clickhouse.yandex.com * update submodule * lost files * CLICKHOUSE-2981: prefer sphinx docs over original reference * CLICKHOUSE-2981: docs styles more similar to main website + add flags to switch language links * update presentations * Less confusing directory structure (docs -> doc/reference/) * Minify sphinx docs too * Website release script: fail fast + pass docker hash on deploy * Do not underline links in docs * shorter * cleanup docker images * tune nginx config * CLICKHOUSE-3043: get rid of habrastorage links * Lost translation * CLICKHOUSE-2936: temporary client-side redirect * behaves weird in test * put redirect back * CLICKHOUSE-3047: copy docs txts to public too * move to proper file * remove old pages to avoid confusion * Remove reference redirect warning for now * Refresh README.md * Yellow buttons in docs * Use svg flags instead of unicode ones in docs * fix test website instance * Put flags to separate files * wrong flag * Copy Yandex.Metrica introduction from main page to docs * Yet another home page structure change, couple new blocks (CLICKHOUSE-3045) * Update Contacts section * CLICKHOUSE-2849: more detailed legal information * CLICKHOUSE-2978 preparation - split by files * More changes in Contacts block * Tune texts on index page * update presentations * One more benchmark * Add usage sections to index page, adapted from slides * Get the roadmap started, based on slides from last ClickHouse Meetup * CLICKHOUSE-2977: some rendering tuning * Get rid of excessive section in the end of getting started * Make headers linkable * CLICKHOUSE-2981: links to editing reference - https://github.com/yandex/ClickHouse/issues/849 * CLICKHOUSE-2981: fix mobile styles in docs * Ban crawling of duplicating docs * Open some external links in new tab * Ban old docs too * Lots of trivial fixes in english docs * Lots of trivial fixes in russian docs * Remove getting started copies in markdown * Add Yandex.Webmaster * Fix some sphinx warnings * More warnings fixed in english docs * More sphinx warnings fixed * Add code-block:: text * More code-block:: text * These headers look not that well * Better switch between documentation languages * merge use_case.rst into ya_metrika_task.rst * Edit the agg_functions.rst texts * Add lost empty lines * Lost blank lines * Add new logo sizes * update presentations * Next step in migrating to new documentation * Fix all warnings in en reference * Fix all warnings in ru reference * Re-arrange existing reference * Move operation tips to main reference * Fix typos noticed by milovidov@ * Get rid of zookeeper.md * Looks like duplicate of tutorial.html * Fix some mess with html tags in tutorial * No idea why nobody noticed this before, but it was completely not clear whet to get the data * Match code block styling between main and tutorial pages (in favor of the latter) * Get rid of some copypaste in tutorial * Normalize header styles * Move example_datasets to sphinx * Move presentations submodule to website * Move and update README.md * No point in duplicating articles from habrahabr here * Move development-related docs as is for now * doc/reference/ -> docs/ (to match the URL on website) * Adapt links to match the previous commit * Adapt development docs to rst (still lacks translation and strikethrough support) * clean on release * blacklist presentations in gulp * strikethrough support in sphinx * just copy development folder for now * fix weird introduction in style article * Style guide translation (WIP) * Finish style guide translation to English * gulp clean separately * Update year in LICENSE * Initial CONTRIBUTING.md * Fix remaining links to old docs in tutorial * Some tutorial fixes * Typo * Another typo * Update list of authors from yandex-team accoding to git log
177 lines
14 KiB
ReStructuredText
177 lines
14 KiB
ReStructuredText
Ограничения на сложность запроса
|
||
================================
|
||
Ограничения на сложность запроса - часть настроек.
|
||
Используются, чтобы обеспечить более безопасное исполнение запросов из пользовательского интерфейса.
|
||
Почти все ограничения действуют только на SELECT-ы.
|
||
При распределённой обработке запроса, ограничения действуют на каждом сервере по-отдельности.
|
||
|
||
Ограничения вида "максимальное количество чего-нибудь" могут принимать значение 0, которое обозначает "не ограничено".
|
||
Для большинства ограничений также присутствует настройка вида overflow_mode - что делать, когда ограничение превышено.
|
||
Оно может принимать одно из двух значений: ``throw`` или ``break``; а для ограничения на агрегацию (group_by_overflow_mode) есть ещё значение ``any``.
|
||
|
||
``throw`` - кинуть исключение (по умолчанию).
|
||
|
||
``break`` - прервать выполнение запроса и вернуть неполный результат, как будто исходные данные закончились.
|
||
|
||
``any (только для group_by_overflow_mode)`` - продолжить агрегацию по ключам, которые успели войти в набор, но не добавлять новые ключи в набор.
|
||
|
||
.. _query_complexity_readonly:
|
||
|
||
readonly
|
||
--------
|
||
При значении 0 можно выполнять любые запросы.
|
||
При значении 1 можно выполнять только запросы на чтение (например, SELECT и SHOW). Запросы на запись и изменение настроек (INSERT, SET) запрещены.
|
||
При значении 2 можно выполнять запросы на чтение (SELECT, SHOW) и изменение настроек (SET).
|
||
|
||
Включив режим readonly, вы уже не сможете выключить его в текущей сессии.
|
||
|
||
При использовании метода GET HTTP интерфейса, автоматически выставляется readonly = 1. То есть, для запросов, модифицирующие данные, можно использовать только метод POST. Сам запрос при этом можно отправлять как в теле POST-а, так и в параметре URL.
|
||
|
||
max_memory_usage
|
||
----------------
|
||
Максимальное количество потребляемой памяти при выполнении запроса на одном сервере. По умолчанию - 10 GB.
|
||
|
||
Настройка не учитывает объём свободной памяти или общий объём памяти на машине.
|
||
Ограничение действует на один запрос, в пределах одного сервера.
|
||
Текущее потребление оперативки для каждого запроса можно посмотреть с помощью SHOW PROCESSLIST.
|
||
Также отслеживается пиковое потребление оперативки для каждого запроса, и выводится в лог.
|
||
|
||
Некоторые случаи потребления оперативки не отслеживаются:
|
||
* большие константы (например, очень длинная константная строка);
|
||
* состояния некоторых агрегатных функций;
|
||
|
||
Потребление оперативки не полностью учитывается для состояний агрегатных функций min, max, any, anyLast, argMin, argMax от аргументов String и Array.
|
||
|
||
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. Если скорость выполнения запроса оказывается меньше, то кидается исключение.
|
||
|
||
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
|
||
----------------
|
||
Максимальное количество элементов синтаксического дерева запроса. Если превышено - кидается исключение.
|
||
Аналогично, проверяется уже после парсинга запроса. По умолчанию: 10 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.
|