Настройка ClickHouse

Содержание

Настройка сервера

Для настройки сервера ClickHouse используется XML-файл /etc/clickhouse-server/config.xml.

Настройка журналов

Для настройки журналирования используется секция clickhouse/logger:

<clickhouse>
    <logger>
        <level>warning</level>
        <log>/var/log/clickhouse-server/clickhouse-server.log</log>
        <errorlog>/var/log/clickhouse-server/clickhouse-server.err.log</errorlog>
        <size>1000M</size>
        <count>10</count>
    </logger>
</clickhouse>

Назначение опций:

• level - уровень журналирования: test - для использования только разработчиками, trace, debug, information, notice, warning, error, critical, fatal, none - отключение журналирования,
• log - файл журнала со всеми сообдениями уровня level,
• errorlog - файл журнала ошибок,
• size - размер одного файла журнала, по достижении которого ClickHouse продолжит ведение журнала в новом файле,
• count - количество архивных файлов журнала.

Также имеется возможность вести журнал через syslog. Подробности см. в официальной документации.

Документация ClickHouse / Конфигурационные параметры сервера / logger

Настройка доступа по протоколу MySQL

Для включения доступа к серверу ClickHouse по протоколу MySQL можно добавить в секцию clickhouse опцию mysql_port:

<clickhouse>
    <mysql_port>9004</mysql_port>
</clickhouse>

Документация ClickHouse / Конфигурационные параметры сервера / mysql_port

Настройка прослушиваемых адресов

Для настройки прослушиваемых IP-адресов предназначена опция listen_host, которую можно указывать более одного раза:

<clickhouse>
    <listen_host>::1</listen_host>
</clickhouse>

Возможные варианты:

• :: - прослушивание всех адресов IPv4 и IPv6,
• 0.0.0.0 - прослушивание всех адресов только IPv4,
• ::1 - прослушивание локального петлевого интерфейса IPv6,
• 127.0.0.1 - прослушивание локального петлевого интерфейса IPv4.

По умолчанию клиент ClickHouse предпочитает использовать IPv6-адреса. Если сервер настроен на прослушивание только адресов IPv4, то подключиться без явного указания адреса IPv4 в таком случае не получится. Если вы не собираетесь использовать адреса IPv6, то для отключения IPv6, достаточно присвоить следующей переменной ядра значение 1:

net.ipv6.conf.all.disable_ipv6 = 1

После этого нужно перезапустить сервер ClickHouse, чтобы он закрыл сокет на адресе IPv6 и открыл сокет только на адресе IPv4:

# systemctl restart clickhouse-server

Документация ClickHouse / Конфигурационные параметры сервера / listen_host

Размер кэша несжатых данных

Для включения использования кэша несжатых данных и для настройки его размера предназначены следующие опции:

<clickhouse>
    <use_uncompressed_cache>0</use_uncompressed_cache>
    <uncompressed_cache_size>8589934592</uncompressed_cache_size>
</clickhouse>

Обратите внимание, что по умолчанию кэш несжатых данных отключен, а при включении его размер по умолчанию составит 8 гигабайт максимум. Кэш используется только для таблиц семейства MergeTree. Размер кэша будет увеличиваться по мере его наполнения, а по достижении максимального размера из него начнут удаляться наименее востребованные данные.

Документация ClickHouse / Конфигурационные параметры сервера / use_uncompressed_cache

Документация ClickHouse / Конфигурационные параметры сервера / uncompressed_cache_size

Размер кэша засечек

Для настройки размера кэша засечек используется опция mark_cache_size из секции clickhouse:

<clickhouse>
    <mark_cache_size>5368709120</mark_cache_size>
</clickhouse>

По умолчанию размер кэша ограничен 5 гигабайтами. Засечки являются разновидностью индексов, которые используются для таблиц семейства MergeTree. Каждая засечка в индексе соответствует некоторому количеству строк, упорядоченных по первичному ключу. Для поиска интересующих данных ClickHouse ищет засечки, между которыми могут находиться интересующие строки, после чего считывает и фильтрует сами строки. Размер кэша будет увеличиваться по мере его наполнения, а по достижении максимального размера из него начнут удаляться нименее востребованные засечки.

Документация ClickHouse / Конфигурационные параметры сервера / mark_cache_size

Настройка журнала запросов

Для отключения всех журналов, которые ClickHouse ведёт в таблицах базы данных, кроме таблиц query_log и query_thread_log, можно воспользоваться такими опциями:

<clickhouse>
    <asynchronous_metric_log remove="1"/>
    <metric_log remove="1"/>
    <part_log remove="1" />
    <session_log remove="1"/>
    <text_log remove="1" />
    <trace_log remove="1"/>
</clickhouse>

Для отключения журналов, которые ClickHouse ведёт в таблицах query_log и query_thread_log, можно воспользоваться такими опциями, которые отключат ведение журналов на уровне настроек по умолчанию для всех пользователей:

<clickhouse>
    <profiles>
        <default>
            <log_queries>0</log_queries>
            <log_query_threads>0</log_query_threads>
        </default>
    </profiles>
</clickhouse>

Для настройки таблицы, в которой будет вестись журнал запросов, предназначена секция yandex/query_log файла конфигурации:

<clickhouse>
    <query_log>
        <database>system</database>
        <table>query_log</table>
        <engine>Engine = MergeTree PARTITION BY event_date ORDER BY event_time TTL event_date + INTERVAL 30 day</engine>
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
    </query_log>
</clickhouse>

Назначение опций:

• database - имя базы данных, в которой находится таблица журнала запросов,
• table - имя таблицы журнала запросов,
• partition_by - ключ секционирования таблицы, нельзя указывать вместе с опцией engine,
• ttl - настройки времени хранения записей в таблице, нельзя указывать вместе с опцией engine,
• engine - настройки таблицы семейства MergeTree, нельзя указывать вместе с опцией partition_by,
• flush_interval_milliseconds - интервал, с которым записи из буфера будут помещаться в таблицу.

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

• toStartOfHour(event_time) - почасовые секции,
• event_date - посуточные секции,
• toMonday(event_date) - понедельные секции, каждая секция начинается с понедельника и заканчивается воскресеньем,
• toYYYYMM(event_date) - помесячные секции.

Значения опции ttl можно указывать, например, в следующем виде: event_date + INTERVAL 30 DAY DELETE.

Для настройки таблицы, в которой будет вестись журнал выполнения запросов отдельными потоками, предназначена секция yandex/query_thread_log, которая настраивается полностью аналогично предыдущей таблице.

Документация ClickHouse / Конфигурационные параметры сервера / query_log

Altinity Knowledge Base / System tables eat my disk

Настройка количества потоков для работы с фрагментами

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

Оценить количество фрагментов можно с помощью такого запроса:

SELECT COUNT(*)
FROM system.parts;

В процессе работы ClickHouse помещает в отдельные файлы фрагментов таблиц данные из каждого запроса INSERT, а затем в фоновом режиме объединяет такие фрагменты. Результирующий фрагмент помечается как активный, а исходные фрагменты помечаются неактивными. Далее, опять же в фоновом режиме, происходит удаление неактивных фрагментов. По умолчанию удаление неактивных фрагментов выполняется количеством потоков, равному количеству ядер процессоров. Хотя, как правило, с удалением неактивных фрагментов может справиться даже один поток, в некоторых случаях может понадобиться увеличить количество потоков. Сделать это можно с помощью параметра конфигурации max_part_removal_threads.

Оценить соотношение количества и объёма активных и неактивных фрагментов можно с помощью следующего запроса:

SELECT active, COUNT(*), SUM(bytes_on_disk) / 1024 / 1024 / 1024
FROM system.parts
GROUP BY active;

Для настройки обоих параметров можно воспользоваться фрагментом конфигурации следующего типа:

<clickhouse>
    <merge_tree>
        <max_part_loading_threads>16</max_part_loading_threads>
        <max_part_removal_threads>16</max_part_removal_threads>
    </merge_tree>
</clickhouse>

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

ALTER TABLE db.table MODIFY SETTING old_parts_lifetime = 60;

Vu Dao. Clickhouse Server - Troubleshooting

Настройка асинхронной вставки данных

В процессе работы ClickHouse помещает в отдельные файлы фрагментов таблиц данные из каждого запроса INSERT, а затем в фоновом режиме объединяет такие фрагменты. Рекомендуется, чтобы один запрос на вставку содержал не менее 1000 строк. Если это не так, то вставки приводят к неоправданно высокому росту нагрузки на дисковую подсистему. Избежать этого можно одним из двух способов: использовать буферные таблицы или асинхронную вставку данных. Если важно, чтобы вставленные данные немедленно становились доступными для запросов на выборку, то в таком случае стоит использовать буферные таблицы. Здесь обсуждается асинхронная вставка данных, при которой данные, попавшие в буфер, остаются недоступными для запросов на выборку данных до того момента, как они не будут записаны.

Включить асинхронную вставку можно при помощи параметра конфигурации async_insert. 0 - асинхронная вставка не используется, 1 - данные перед вставкой в таблицу накапливаются.

При асинхронной вставки можно также поменять поведение потока, который выполняет вставку данных. Если параметр конфигурации wait_for_async_insert принимает значение 0, то поток ждёт момента, когда накопленные в буфере данные будут записаны на диск. При значении 1 поток не дожидается записи накопленных данных на диск и сообщает клиенту об успешной вставке данных. С одной стороны это позволяет снизить количество одновременно работающих потоков, а стало быть снизить нагрузку на процессор и снизить потребление оперативной памтяи, а с другой стороны в таком режиме невозможно узнать об ошибке, если данные по каким-либо причином всё-таки не были записаны на диск.

Для управления моментом записи накопленных данных на диск предназначены два параметра конфигурации: async_insert_max_data_size - указывает минимальный объём накопленных данных в байтах, прежде чем данные будут записаны на диск, и async_insert_busy_timeout_ms - указывает минимальный интервал времени в миллисекундах, по прошествии которого накопленные данные будут записаны даже в том случае, если не был достигнут необходимый для их записи объём. По умолчанию запись на диск происходит при накоплении 100000 байт данных или по прошествии 200 миллисекунд.

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

<clickhouse>
    <profiles>
        <default>
            <async_insert>1</async_insert>
            <wait_for_async_insert>0</wait_for_async_insert>
            <async_insert_max_data_size>10485760</async_insert_max_data_size>
            <async_insert_busy_timeout_ms>1000</async_insert_busy_timeout_ms>
        </default>
    </profiles>
</clickhouse>

Tom Schreiber, Tony Bonuccelli. Asynchronous Data Inserts in ClickHouse

Буферные таблицы

В процессе работы ClickHouse помещает в отдельные файлы фрагментов таблиц данные из каждого запроса INSERT, а затем в фоновом режиме объединяет такие фрагменты. Рекомендуется, чтобы один запрос на вставку содержал не менее 1000 строк. Если это не так, то вставки приводят к неоправданно высокому росту нагрузки на дисковую подсистему. Избежать этого можно одним из двух способов: использовать буферные таблицы или асинхронную вставку данных. Если важно, чтобы вставленные данные немедленно становились доступными для запросов на выборку, то в таком случае стоит использовать буферные таблицы.

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

Рассмотрим пример основной таблицы:

CREATE TABLE history_uint
(
    itemid UInt64,
    clock UInt32,
    ns UInt32,
    value UInt64
) ENGINE = MergeTree()
PARTITION BY toYYYYMMDD(toDateTime(clock))
ORDER BY (itemid, clock);

Переименуем её и создадим вместо неё буферную таблицу:

RENAME TABLE history_uint TO real_history_uint;

CREATE TABLE history_uint
(
    itemid UInt64,
    clock UInt32,
    ns UInt32,
    value UInt64
) ENGINE = Buffer(zabbix, real_history_uint, 8, 30, 60, 8192, 65536, 262144, 67108864);

Рассмотрим по порядку все поля, который указываются при создании буфернйо таблицы для её настройки:

• zabbix - имя базы данных, в которой находится реальная таблица,
• real_history_uint - имя реальной таблицы, для которой буферная таблица выполняет буферизацию данных,
• 8 - количество слоёв буфера,
• 30 секунд - минимальное время, которое должно пройти со момента предыдущей записи в реальную таблицу, прежде чем буферная таблица запишет данные в реальную таблицу,
• 60 секунд - максимальное время с момента предыдущей записи в реальную таблицу, по прошествии которого операция записи будет выполнена вне зависимости от всех остальных условий,
• 8192 строк - минимальное количество записей, которое должно быть в буферной таблице, прежде чем буферная таблица запишет данные в реальную таблицу,
• 65536 строк - максимальное количество записей, которое должно быть в буферной таблице, по достижении которого операция записи будет выполнена вне зависимости от всех остальных условий,
• 256 килобайт - минимальный объём данных, который должен накопиться в буферной таблице, прежде чем буферная таблица запишет данные в реальную таблицу,
• 64 мегабайта - максимальный объём данных, который должен накопиться в буферной таблице, по достижении которого операция записи будет выполнена вне зависимости от всех остальных условий.

Итак, буферная таблица ждёт либо выполнения одного из условий максимума, либо выполнения всех условий минимума, после чего данные будут записаны в реальную таблицу.

ClickHouse Engines / Движки таблиц / Специальные движки таблиц / Buffer

Деление таблиц на секции

ClickHouse изначально предназначен для сбора данных, имеющих привязку ко времени. Как правило, интерес к таким данных убывает с течением времени. Наиболее востребованными оказываются самые свежие данные, а самые старые данные могут вовсе не представлять интереса. Чтобы не тратить впустую место на дисках, можно не хранить вечно устаревшие данные.

Для настройки времени хранения данных в таблицах предназначен параметр TTL. Например, для настройки хранения данных в течение трёх месяцев от отметки времени в поле date_create в таблице, можно воспользоваться таким выражением:

TTL date_create + toIntervalMonth(3)

Для указания интервало времени предназначены следующие функции:

• toIntervalYear() - интервал в годах,
• toIntervalMonth() - интервал в месяцах,
• toIntervalDay() - интервал в сутках,
• toIntervalHour() - интервал в часах,
• toIntervalMinute() - интервал в минутах,
• toIntervalSecond() - интервал в секундах.

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

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

PARTITION BY toYYYYMMDD(datetime)

Для задания имён секция можно пользоваться следующими функциями:

• toYYYYMM(timestamp) - создаёт секции с именами вида ГГГГММ, где ГГГГ - 4 цифры года, а ММ - 2 цифры номер месяца, начиная с 01,
• toYYYYMMDD(timestamp) - создаёт секции с именами вида ГГГГММДД, где ГГГГ - 4 цифры года, ММ - 2 цифры номер месяца, начиная с 01, а ДД - 2 цифры числа месяца,
• toDate(timestamp) - создаёт секции с именами вида ГГГГ-ММ-ДД, где ГГГГ - 4 цифры года, ММ - 2 цифры номер месяца, начиная с 01, а ДД - 2 цифры числа месяца,
• toStartOfInterval(timestamp, toIntervalHour(1)) - создаёт секции с именами вида ГГГГ-ММ-ДД ЧЧ:мм:СС, где ГГГГ - 4 цифры года, ММ - 2 цифры номер месяца, начиная с 01, ДД - 2 цифры числа месяца, ЧЧ - 2 цифры часов, мм - 2 цифры минут, СС - 2 цифры секунд. Второй аргумент функции указывает интервал, в качестве которого можно использовать число, сгенерированное одно из уже перечисленных выше функций.

Если время в таблице хранится не в естественном для ClickHouse формате DateTime, а в виде целого числа с количеством секунд от начала 1970 года, как это принято в системах, подобных Unix, то преобразовать такую отметку времени в формат DateTime можно с помощью функции toDateTime(clock).

При выборе размера секции таблицы следует учитывать время, в течение которого данные будут в ней храниться. Размер секции точно не должен быть больше, чем время хранения, в противном случае ClickHouse будет вычищать из одной секции таблицы устаревшие данные, путем отбора актуальных данных и формирования из них новых фрагментов. Количество потоков, занимающихся удалением из таблиц устаревших данных, настраивается с помощью опции max_part_removal_threads, которая была описана выше.

Также не стоит создавать слишком мелкие секции, если сравнивать их со временем хранения данных, т.к. при чрезмерном дроблении данных на секции будет создано слишком большое количество файлов с фрагментами таблицы, в результате чего вырастет время выполнения запросов и запуска сервера. Количество одновременно открытых файлов ограничивается операционной системой, а из-за большого количества фрагментов серверу ClickHouse придётся слишком часто закрывать файлы с фрагментами, ставшие не нужными, и вместо них открывать файлы с фрагментами, которые нужны для завершения выполнения запроса.

Также при выборе размера секции стоит учитывать временные интервалы, по которым чаще всего происходит выборка. Оптимально, если большинство выполняемых запросов будут просматривать одну или две секции. При большем количестве секций, подлежащих просмотру, стоит подумать о том, чтобы увеличить размер одной секции, чтобы уменьшить количество файлов фрагментов, которые нужно просмотреть в процессе выполнения запроса, и результаты которых нужно ещё и объединить. Если же большинство запросов обращаются только к маленькой части одной секции, то стоит подумать о том, чтобы сделать секции более мелкими, т.к. при просмотре одной большой секции приходится просматривать большое количество данных, которые в итоге оказываются невостребованными. Особенно на описанные тут рекомендации стоит обратить внимание в том случае, если отметка времени не является первым полем в выражении ORDER BY, настраивающем порядок сортировки данных в секциях таблиц.

Оптимальное количество секций - от нескольких штук до нескольких сотен.

Удаление устаревших секций целиком

ClickHouse вычищает из таблиц устаревшие данные, путем отбора актуальных данных и формирования из них новых фрагментов. Количество потоков, занимающихся удалением из таблиц устаревших данных, настраивается с помощью опции max_part_removal_threads, которая была описана выше. Устаревшие данные можно удалять из таблиц не по мере устаревания каждой отдельной записи, а вместе со всей секцией целиком, когда в ней не останется актуальных данных. Таким образом можно снизить нагрузку на диски и на процессор, поскольку потокам удаления устаревших данных нужно будет удалять устаревшие секции целиком, не выполняя фильтрацию и запись актуальных данных в новый фрагмент.

Настроить удаление устаревших секций целиком можно с помощью запросов следующего вида:

ALTER TABLE db.table MODIFY SETTING ttl_only_drop_parts = 1;

Сортировка данных в таблицах

Представим, что имеется таблица следующего вида:

CREATE TABLE customer_notice
(
    `customer_id` UInt64,
    `date_create` DateTime,
    ...
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(date_create)
ORDER BY (date_create, customer_id)
TTL date_create + toIntervalMonth(3)
SETTINGS index_granularity = 8192;

Настройка ORDER BY используется для сортировки данных перед их записью в файл-фрагмент таблицы и фактически явлется разрежённым кластерным индексом. Кластерный индекс - это такой индекс, который хранится вместе с данными и используется для упорядоченного досутпа к ним. Разрежённый индекс содержит значения не для каждой строки данных, а для интервалов строк.

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

Поскольку таблица уже поделена на секции по месяцам, то может оказаться выгодным поменять порядок сортировки на customer_id, date_create и тогда при поиске данных сначала будут отобраны секции таблицы, соотвествующие интервалу дат, затем внутри них будут отобраны строки, соответствующие одному определённому идентификатору заказчика и интервалу дат. Отбрасывать лишние данные в этом случае не придётся, т.к. необходимые данные будут расположены одним непрерывным блоком.

Если в таблице не много данных, то можно перенести их в таблицу с новым порядком сортировки одним запросом вида INSERT INTO ... SELECT FROM, следующим образом:

CREATE TABLE customer_notice_new
(
    `customer_id` UInt64,
    `date_create` DateTime,
    ...
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(date_create)
ORDER BY (customer_id, date_create)
TTL date_create + toIntervalMonth(3)
SETTINGS index_granularity = 8192;

INSERT INTO customer_notice_new(customer_id, date_create, ...)
SELECT customer_id, date_create, ... FROM customer_notice;

RENAME TABLE customer_notice TO customer_notice_bak;

RENAME TABLE customer_notice_new TO customer_notice;

Если же данных много и содержимое старой таблицы не умещается в оперативной памяти сервера ClickHouse целиком, то такой запрос придётся поделить на серию запросов с указанием интервалов дат в критерии фильтрации WHERE date_create BETWEEN ... AND ... и перенести, таким образом, данные по частям.

Настройка пользователей

Включение управления доступом через SQL-запросы

По умолчанию список пользователей и их права настраиваются с помощью файла /etc/clickhouse-server/users.xml. Однако ClickHouse умеет хранить эту информацию в базе данных. Для включения этой функциональности нужно вписать в файл конфигурации, в секцию, соответствующую пользователю default, следующую опцию:

<access_management>1</access_management>

Далее нужно перезапустить сервер ClickHouse:

# systemctl restart clickhouse-server

Goodbye XML, hello SQL! ClickHouse User Management Goes Pro

Заведение пользователей

Какой бы ни использовался метод управления пользователями - через файл /etc/clickhouse-server/users.xml или через SQL-запросы, может пригодиться вычислить хэш от пароля пользователя. Хэш в формате password_sha256_hex или sha256_hash можно вычислить одним из двух следующих способов:

В командной строке с помощью утилиты sha256sum:

$ echo -n '<password>' | sha256sum | tr -d '-'
dd81ca61fb57a4ff454c1cf89335a1f5e96afa849dfad4e0116b6ec35309fdea

В клиенте ClickHouse с помощью функций hex и SHA256:

SELECT HEX(SHA256('<password>'));

Далее полученный хэш пароля можно вписать в файл /etc/clickhouse-server/users.xml следующим образом (пример соответствует пользователю с именем default):

<yandex>
    <users>
        <default>
            <password_sha256_hex>dd81ca61fb57a4ff454c1cf89335a1f5e96afa849dfad4e0116b6ec35309fdea</password_sha256_hex>
        </default>
    <users>
</yandex>

Или этот же хэш пароля можно вписать в SQL-запрос для создания пользователя или изменения его пароля:

CREATE USER default IDENTIFIED WITH sha256_hash BY 'dd81ca61fb57a4ff454c1cf89335a1f5e96afa849dfad4e0116b6ec35309fdea';
ALTER USER default IDENTIFIED WITH sha256_hash BY 'dd81ca61fb57a4ff454c1cf89335a1f5e96afa849dfad4e0116b6ec35309fdea';

Creating Users and Roles in ClickHouse

Проверка учётной записи

Для проверки учётной записи можно воспользоваться клиентом ClickHouse для командной строки:

$ echo 'SELECT 1;' | clickhouse-client -h 192.168.1.2 -d db -u user --password 'p4$$w0rd'

Если на проверяемом узле не установлен клиент ClickHouse для командной строки, то для проверки учётной записи можно воспользоваться утилитой curl и сервером HTTP, встроенным в сервер ClickHouse:

$ echo 'SELECT 1;' | curl --data-binary @- -u 'user:p4$$w0rd' 'http://192.168.1.2:8123/?database=db'

В обеих командах:

• 192.168.1.2 - IP-адрес или доменное имя сервера ClickHouse,
• db - название базы данных, к которой есть доступ у проверяемого пользователя,
• user - имя проверяемого пользователя,
• p4$$w0rd - пароль проверяемого пользователя.

Drivers and Interfaces / HTTP Interface

Настройка клиента

Для настройки консольного клиента ClickHouse для входа без пароля можно создать в домашнем каталоге подкаталог .clickhouse-client и поместить внутрь него файл config.xml со следующим содержимым:

<config>
    <host>192.168.1.2</host>
    <port>9000</port>
    <user>user</user>
    <password>p4$$w0rd</password>
    <database>db</database>
    <!-- <format>PrettyCompactMonoBlock</format>
    <multiline>1</multiline>
    <multiquery>1</multiquery>
    <stacktrace>1</stacktrace>
    <pager>less -SR</pager>
    <max_parser_depth>2500</max_parser_depth> -->
</config>

Где:

• 192.168.1.2 - IP-адрес или доменное имя сервера ClickHouse, к которому клиент будет подключаться по умолчанию,
• 9000 - порт сервера ClickHouse, на котором он принимает подключения от клиентов, работающих по его двоичному протоколу,
• db - название базы данных, к которой пользователь будет подключен по умолчанию,
• user - имя пользователя,
• p4$$w0rd - пароль пользователя.

В файле конфигурации можно указать значение для любой опции командной строки: несколько примеров приведено в закомментированном блоке между символами <!-- и -->.

Clients and Drivers / Command-Line Client