Итак, мы наконец-то добрались до настроек пользователей. На самом деле большинство настроек пользователь задает сам при подключении к кликхаусу. Помните мы выполняли запрос для включения логирования - SET log_query = 1. В данном случае мы задаем настройку для пользователя - log_query = 1. Но действовать она будет только в рамках той сессии, в которой работает пользователь. В файле users.xml мы можем указать дефолтные параметры настроек для пользователя, чтобы он каждый раз не вводил их вручную или не тратил время на их применение.
На самом деле профили и настройки вынесены на клиента для более гибкого управления конфигурацией. Клиент сам может в случае необходимости поменять какие-то значения для корректной работы. То есть важно понимать, что профили используются именно для задания настроек по умолчанию, а не лимитирования. Для лимитирования пользователя используются квоты - их мы рассмотрим в следующем задании.
Ниже приведен пример конфигурации профилей, которые вы можете потом указывать в настройках пользователей.
<yandex>
<profiles>
<default>
<use_uncompressed_cache>0</use_uncompressed_cache>
<load_balancing>random</load_balancing>
</default>
<myprofile>
<max_memory_usage>20000000000</max_memory_usage>
<max_rows_to_read>1000000000</max_rows_to_read>
<max_bytes_to_read>100000000000</max_bytes_to_read>
<max_result_rows>1000000</max_result_rows>
<max_execution_time>600</max_execution_time>
<max_columns_to_read>30</max_columns_to_read>
<readonly>1</readonly>
</myprofile>
</profiles>
</yandex>
Давайте рассмотрим некоторые настройки из него.
Максимально допустимое количество памяти, которое может быть использовано для выполнения запроса. По-умолчанию в основной конфигурации выставлено значение в 10Гб. Данный параметр не учитывает количество имеющейся свободной памяти на машине, а используется для ограничение запроса пользователя если он вдруг введет запрос, который использует больше 10 Gb оперативной памяти. Мы так же советуем всем выставлять данный параметр для всех пользователей достаточно низким, а тем кому действительно надо поднимать его в отдельном профиле. Например, это может быть сервис, который пересчитывает статистику за неделю и ему действительно требуется использовать много памяти. Кстати, вы можете посмотреть потребление памяти для каждого запроса через SHOW PROCESSLIST.
Максимальное количество строк, которое можно прочитать при выполнении запроса.
Максимальное количество байт, которое можно прочитать при выполнении запроса.
Максимальное количество строк, которое будет выдано запросом после его выполнения.
Максимальное количество времени (в секундах), которое дается на выполнение запроса.
Максимальное количество доступных колонок для чтения при выполнении запроса.
Режим, который обеспечивает доступ только на чтение. Для его активации укажите в значении 1.
Как вы могли заметить - профили по сути описывают стандартные настройки для пользователя, который может их изменить в процессе работы. Среди профилей есть default, который обязателен и используется при запуске сервера.
В данном случае мы создали новый myprofile, в котором указали некоторые параметры, отличные от тех, что идут по умолчанию.
Чтобы применить настройки, нужно установить настройку profile. Команда выглядит следующим образом:
SET profile = 'myprofile';
Проверить, применились ли они, мы можем, посмотрев в системную таблицу system.settings и найдя значение нужного параметра. Если у вас не хватает прав на просмотр системных таблиц для default пользователя, убедитесь, что в настройках пользователей включен параметр <access_management>.
Давайте попробуем создать отдельный профиль нашему пользователю test и проверить его работу. Добавляем опции в users.xml:
<test>
<max_memory_usage>20000000000</max_memory_usage>
<max_rows_to_read>1000000000</max_rows_to_read>
<max_bytes_to_read>100000000000</max_bytes_to_read>
<max_result_rows>1</max_result_rows>
<max_execution_time>600</max_execution_time>
<max_columns_to_read>30</max_columns_to_read>
<readonly>0</readonly>
</test>
Здесь мы указали одну очень маленькую опцию - max_result_rows, которая не будет возвращать больше 1 строки нашему пользователю. А так же отключили режим только для чтения для нашего пользователя. Давайте теперь изменим параметр для нашего пользователя и зададим ему профиль по умолчанию <profile>test</profile>, а так же уберем фильтр на вывод строк из таблицы. То есть просто удалим вот этот блок в описании пользователя:
<databases>
<database_name>
<table_name>
<filter>role = 'user'</filter>
<table_name>
</database_name>
</databases>
Теперь можно рестартовать кликхаус и тестировать:
clickhouse-client -u test
ClickHouse client version 21.2.5.5 (official build).
Connecting to localhost:9000 as user test.
Connected to ClickHouse server version 21.2.5 revision 54447.
ch1.ru-central1.internal :) Cannot load data for command line suggestions: Code: 396, e.displayText() = DB::Exception: Received from localhost:9000. DB::Exception: Limit for result exceeded, max rows: 1.00, current rows: 922.00. (version 21.2.5.5 (official build))
ch1.ru-central1.internal :) select * from logs.data;
→ Progress: 3.00 rows, 64.00 B (29.54 rows/s., 630.16 B/s.) 99%
0 rows in set. Elapsed: 0.102 sec.
Received exception from server (version 21.2.5):
Code: 396. DB::Exception: Received from localhost:9000. DB::Exception: Limit for result exceeded, max rows: 1.00, current rows: 3.00.
ch1.ru-central1.internal :)
Смотрите как интересно - сразу при подключении мы получили ошибку от кликхауса. Произошло это потому что кликхаус хочет подгрузить данные для автодополнения команд из внутренней таблицы, но лимит на количество строк для чтения у нас выставлен в единицу, а список дополнений - 922 штуки. Отсюда и ошибка.
Та же ошибка возникает при попытке прочитать таблицу logs.data, которая содержит три строки (помните мы убрали фильтр на них). Давайте попробуем поменять данные найстройки прямо в текущей сессии:
ch1.ru-central1.internal :) set max_result_rows = 100;
Ok.
ch1.ru-central1.internal :) select * from logs.data;
SELECT *
FROM logs.data
Query id: 232c3e85-bcc4-4e9a-8217-c643e46d642a
┌──────────────────ev─┬─a─┬─role──┐
│ 2021-03-09 12:00:00 │ 1 │ admin │
│ 2021-03-09 12:01:00 │ 2 │ user │
│ 2021-03-09 12:02:00 │ 3 │ test │
└─────────────────────┴───┴───────┘
3 rows in set. Elapsed: 0.002 sec.
ch1.ru-central1.internal :)
Как видите - наш запрос успешно отработал. То есть пользователь может изменить свои дефолтные настройки при возникновении каких-либо ошибок. По-другому дело обстоит если у профиля задана опция readonly = true - она запрещает изменение текущие настроек пользователя. Давайте попробуем включить ее в конфигурации для профиля test и воспроизвести наш пример <readonly>1</readonly>:
ch1.ru-central1.internal :) set max_result_rows = 100;
0 rows in set. Elapsed: 0.001 sec.
Received exception from server (version 21.2.5):
Code: 164. DB::Exception: Received from localhost:9000. DB::Exception: Cannot modify 'max_result_rows' setting in readonly mode.
ch1.ru-central1.internal :)
Ага! То есть кликхаус не дает нам поменять наши конфигурационные параметры при работе в readonly режиме. Так же он не даст нам изменить настройку readonly в readonly режиме :)