HTTP-интерфейс
Предварительные требования
Для примеров, приведённых в этой статье, вам потребуется:
- работающий сервер ClickHouse
- установленный
curl. В Ubuntu или Debian выполните командуsudo apt install curlили обратитесь к этой документации за инструкциями по установке.
Обзор
HTTP-интерфейс позволяет использовать ClickHouse на любой платформе и из любого языка программирования в виде REST API. HTTP-интерфейс более ограничен, чем нативный интерфейс, но обладает более широкой поддержкой языков программирования.
По умолчанию clickhouse-server прослушивает следующие порты:
- порт 8123 для HTTP
- порт 8443 для HTTPS (может быть включен)
Если выполнить запрос GET / без каких-либо параметров, возвращается код ответа 200 вместе со строкой «Ok.»:
"Ok." — значение по умолчанию, заданное в http_server_default_response, и при необходимости его можно изменить.
См. также: Особенности кодов ответа HTTP.
Веб-интерфейс
ClickHouse включает веб-интерфейс, доступ к которому можно получить по следующему адресу:
Веб-интерфейс поддерживает отображение прогресса во время выполнения запроса, отмену запроса и потоковую передачу результатов. В нем есть скрытая возможность отображения диаграмм и графиков для конвейеров (пайплайнов) запросов.
После успешного выполнения запроса появляется кнопка загрузки, которая позволяет скачать результаты запроса в различных форматах, включая CSV, TSV, JSON, JSONLines, Parquet, Markdown или любой пользовательский формат, поддерживаемый ClickHouse. Функция загрузки использует кэш запросов для эффективного получения результатов без повторного выполнения запроса. Она скачает все результаты, даже если в интерфейсе была показана только одна страница из многих.
Веб-интерфейс разработан для профессионалов, таких как вы.

В скриптах проверки работоспособности используйте запрос GET /ping. Этот обработчик всегда возвращает строку "Ok." (с символом перевода строки в конце). Доступно начиная с версии 18.12.13. См. также /replicas_status для проверки задержки реплики.
Выполнение запросов по HTTP/HTTPS
Для выполнения запросов по HTTP/HTTPS есть три варианта:
- отправить запрос как параметр URL
query; - использовать метод POST;
- отправить начало запроса в параметре
query, а остальную часть — с помощью POST.
Размер URL по умолчанию ограничен 1 МиБ, это можно изменить с помощью настройки http_max_uri_size.
Если запрос выполнен успешно, вы получаете код ответа 200 и результат в теле ответа. Если произошла ошибка, вы получаете код ответа 500 и текст с описанием ошибки в теле ответа.
Запросы с использованием GET являются «только для чтения». Это означает, что для запросов, которые модифицируют данные, вы можете использовать только метод POST. Вы можете отправить сам запрос либо в теле POST-запроса, либо в параметре URL. Рассмотрим несколько примеров.
В примере ниже для отправки запроса SELECT 1 используется curl. Обратите внимание на использование URL-кодирования для пробела: %20.
В этом примере wget используется с параметрами -nv (неподробный вывод) и -O- для вывода результата в терминал.
В этом случае нет необходимости URL-кодировать пробел:
В этом примере мы перенаправляем сырой HTTP-запрос в netcat:
Как видно, команда curl несколько неудобна тем, что пробелы необходимо URL-кодировать.
Хотя wget кодирует всё сам, мы не рекомендуем его использовать, поскольку он плохо работает по HTTP/1.1 при использовании keep-alive и Transfer-Encoding: chunked.
Если часть запроса передаётся в параметре, а часть — в POST, между этими двумя частями данных вставляется символ перевода строки. Например, это не сработает:
По умолчанию данные возвращаются в формате TabSeparated.
Чтобы запросить любой другой формат, в запросе используется предложение FORMAT. Например:
Вы можете использовать URL-параметр default_format или заголовок X-ClickHouse-Format, чтобы указать формат по умолчанию, отличный от TabSeparated.
Вы можете использовать метод POST для параметризованных запросов. Параметры задаются с помощью фигурных скобок с именем и типом параметра, например {name:Type}. Значения параметров передаются через param_name:
Запросы INSERT по HTTP/HTTPS
Для запросов INSERT используется метод POST. В этом случае вы можете записать начальную часть запроса в параметр URL, а данные для вставки передать через POST. Данные для вставки могут представлять собой, например, дамп из MySQL с разделителем табуляции. Таким образом, запрос INSERT заменяет в MySQL команду LOAD DATA LOCAL INFILE.
Примеры
Чтобы создать таблицу:
Чтобы использовать привычный запрос INSERT для вставки данных:
Для отправки данных отдельно от запроса:
Можно указать любой формат данных. Например, можно указать формат 'Values' — тот же, что используется при выполнении INSERT INTO t VALUES:
Чтобы вставить данные из дампа с разделителями табуляции, укажите соответствующий формат:
Чтобы просмотреть содержимое таблицы:
Данные выводятся в случайном порядке из-за параллельной обработки запросов
Чтобы удалить таблицу:
Для успешных запросов, не возвращающих таблицу данных, возвращается пустое тело ответа.
Сжатие
Сжатие можно использовать для уменьшения сетевого трафика при передаче больших объёмов данных или для создания дампов, которые сразу сохраняются в сжатом виде.
Вы можете использовать внутренний формат сжатия ClickHouse при передаче данных. Сжатые данные имеют нестандартный формат, и для работы с ними требуется программа clickhouse-compressor. Она устанавливается по умолчанию вместе с пакетом clickhouse-client.
Чтобы повысить эффективность вставки данных, отключите проверку контрольных сумм на стороне сервера с помощью настройки http_native_compression_disable_checksumming_on_decompress.
Если вы укажете compress=1 в URL, сервер будет сжимать данные, которые он вам отправляет. Если вы укажете decompress=1 в URL, сервер будет распаковывать данные, которые вы передаёте методом POST.
Вы также можете использовать HTTP-сжатие. ClickHouse поддерживает следующие методы сжатия:
gzipbrdeflatexzzstdlz4bz2snappy
Чтобы отправить сжатый POST-запрос, добавьте заголовок запроса Content-Encoding: compression_method.
Чтобы ClickHouse сжимал ответ, добавьте к запросу заголовок Accept-Encoding: compression_method.
Вы можете настроить уровень сжатия данных с помощью настройки http_zlib_compression_level для всех методов сжатия.
Некоторые HTTP-клиенты могут по умолчанию распаковывать данные с сервера (для gzip и deflate), и вы можете получить распакованные данные, даже если используете настройки сжатия корректно.
Примеры
Чтобы отправить сжатые данные на сервер:
Чтобы получить с сервера сжатый архив данных:
Чтобы получать от сервера сжатые данные и сразу же их распаковывать, используйте gunzip:
База данных по умолчанию
Вы можете использовать параметр URL database или заголовок X-ClickHouse-Database, чтобы указать базу данных, используемую по умолчанию.
По умолчанию используется база данных, указанная в настройках сервера. Изначально это база данных default. При необходимости вы можете явно указать базу данных, добавив её имя перед именем таблицы через точку.
Аутентификация
Имя пользователя и пароль можно указать одним из трёх способов:
- С помощью базовой HTTP-аутентификации.
Например:
- В параметрах URL
userиpassword
Мы не рекомендуем использовать этот способ, так как параметры могут быть записаны в журнал веб‑прокси и сохранены в кэше браузера
Например:
- Использование заголовков 'X-ClickHouse-User' и 'X-ClickHouse-Key'
Например:
Если имя пользователя не указано, используется имя default. Если пароль не указан, используется пустой пароль.
Вы также можете использовать URL‑параметры, чтобы задать любые настройки для обработки одного запроса или целых профилей настроек.
Например:
Дополнительные сведения см.:
Использование сессий ClickHouse в протоколе HTTP
В протоколе HTTP также можно использовать сессии ClickHouse. Для этого необходимо добавить к запросу параметр session_id в GET. В качестве идентификатора сессии можно использовать любую строку.
По умолчанию сессия завершается через 60 секунд бездействия. Чтобы изменить этот таймаут (в секундах), измените настройку default_session_timeout в конфигурации сервера или добавьте к запросу параметр session_timeout в GET.
Чтобы проверить состояние сессии, используйте параметр session_check=1. В рамках одной сессии одновременно может выполняться только один запрос.
Вы можете получать информацию о прогрессе выполнения запроса в заголовках ответа X-ClickHouse-Progress. Для этого включите send_progress_in_http_headers.
Ниже приведён пример последовательности заголовков:
Возможные поля заголовка:
| Поле заголовка | Описание |
|---|---|
read_rows | Количество прочитанных строк. |
read_bytes | Объём прочитанных данных в байтах. |
total_rows_to_read | Общее количество строк для чтения. |
written_rows | Количество записанных строк. |
written_bytes | Объём записанных данных в байтах. |
elapsed_ns | Время выполнения запроса в наносекундах. |
memory_usage | Объём памяти в байтах, используемый запросом. |
Выполняющиеся запросы не останавливаются автоматически при потере HTTP‑соединения. Разбор и форматирование данных выполняются на стороне сервера, и использование сети может быть неэффективным.
Существуют следующие необязательные параметры:
| Параметр | Описание |
|---|---|
query_id (optional) | Можно передать как идентификатор запроса (произвольная строка). replace_running_query |
quota_key (optional) | Можно передать как ключ квоты (произвольная строка). «Quotas» |
HTTP‑интерфейс позволяет передавать внешние данные (внешние временные таблицы) для обработки запросов. Дополнительные сведения см. в разделе «External data for query processing».
Буферизация ответа
Буферизацию ответа можно включить на стороне сервера. Для этого предусмотрены следующие параметры URL:
buffer_sizewait_end_of_query
Можно использовать следующие параметры настроек:
buffer_size определяет количество байт результата, которое будет буферизовано в памяти сервера. Если тело результата больше этого порога, буфер записывается в HTTP‑канал, а оставшиеся данные отправляются напрямую в HTTP‑канал.
Чтобы обеспечить буферизацию всего ответа, установите wait_end_of_query=1. В этом случае данные, которые не помещаются в память, будут буферизованы во временном серверном файле.
Например:
Используйте буферизацию, чтобы избежать ситуаций, когда ошибка обработки запроса возникает после того, как код ответа и HTTP‑заголовки уже отправлены клиенту. В этом случае сообщение об ошибке оказывается в конце тела ответа, и на стороне клиента ошибка может быть обнаружена только при разборе ответа.
Установка роли с помощью параметров запроса
Эта функция была добавлена в ClickHouse 24.4.
В некоторых сценариях может потребоваться сначала установить предоставленную роль, а уже затем выполнять саму команду.
Однако отправить SET ROLE и команду вместе невозможно, поскольку многокомандные запросы не допускаются:
Приведённая выше команда вызывает ошибку:
Чтобы обойти это ограничение, воспользуйтесь параметром запроса role:
Это эквивалентно выполнению SET ROLE my_role перед выполнением запроса.
Кроме того, можно указать несколько параметров запроса role:
В этом случае ?role=my_role&role=my_other_role работает аналогично выполнению SET ROLE my_role, my_other_role перед выполнением запроса.
Особенности кодов ответа HTTP
Из-за ограничений протокола HTTP код ответа 200 не гарантирует, что запрос был выполнен успешно.
Вот пример:
Причина такого поведения связана с природой протокола HTTP. Сначала отправляется HTTP-заголовок с кодом 200, затем тело HTTP-ответа, и уже после этого ошибка добавляется в это тело в виде обычного текста.
Это поведение не зависит от используемого формата, будь то Native, TSV или JSON: сообщение об ошибке всегда будет находиться в середине потока ответа.
Вы можете частично устранить эту проблему, включив wait_end_of_query=1 (Буферизация ответа). В этом случае отправка HTTP-заголовка откладывается до тех пор, пока весь запрос не будет обработан. Однако это не полностью решает проблему, потому что результат всё равно должен поместиться в http_response_buffer_size, а другие настройки, такие как send_progress_in_http_headers, могут нарушать задержку отправки заголовка.
Единственный способ перехватить все ошибки — проанализировать тело HTTP-ответа до его разбора с использованием требуемого формата.
Подобные исключения в ClickHouse имеют единообразный формат, как показано ниже, независимо от используемого формата (например, Native, TSV, JSON и т. д.), при http_write_exception_in_output_format=0 (значение по умолчанию). Это упрощает разбор и извлечение сообщений об ошибках на стороне клиента.
Где <TAG> — это 16-байтовый случайный тег, который совпадает с тегом, отправленным в заголовке ответа X-ClickHouse-Exception-Tag.
<error message> — это фактическое сообщение об исключении (точную длину можно найти в <message_length>). Весь блок исключения, описанный выше, может достигать 16 КиБ.
Вот пример в формате JSON
Вот похожий пример, но в формате CSV
Запросы с параметрами
Вы можете создавать запросы с параметрами и передавать для них значения из соответствующих параметров HTTP-запроса. Для получения дополнительной информации см. раздел Запросы с параметрами для CLI.
Пример
Табуляция в параметрах URL
Параметры запроса интерпретируются в «экранированном» формате. Это даёт некоторые преимущества, например возможность однозначно интерпретировать \N как null. Это означает, что символ табуляции должен быть закодирован как \t (либо как \ и символ табуляции). Например, в следующем примере между abc и 123 содержится фактический символ табуляции, и входная строка разбивается на два значения:
Однако если вы попытаетесь закодировать символ табуляции как %09 в параметре URL, он не будет корректно разобран:
Если вы используете параметры URL-запроса, вам нужно закодировать \t как %5C%09. Например:
Предопределённый HTTP-интерфейс
ClickHouse поддерживает выполнение ряда специфических запросов через HTTP-интерфейс. Например, вы можете записать данные в таблицу следующим образом:
ClickHouse также поддерживает предопределённый HTTP-интерфейс, который может упростить интеграцию со сторонними инструментами, такими как Prometheus exporter. Рассмотрим пример.
Прежде всего добавьте этот раздел в файл конфигурации сервера.
http_handlers настраивается так, чтобы содержать несколько правил (rule). ClickHouse будет сопоставлять полученные HTTP-запросы с предопределённым типом в rule, и обработчик запускается для первого правила, которому запрос соответствует. Затем, если сопоставление прошло успешно, ClickHouse выполнит соответствующий предопределённый запрос.
Теперь вы можете запрашивать данные в формате Prometheus по этому URL:
Параметры конфигурации для http_handlers задаются следующим образом.
rule позволяет настроить следующие параметры:
methodheadersurlfull_urlhandler
Каждый из них рассматривается ниже.
-
methodотвечает за сопоставление части метода HTTP-запроса.methodполностью соответствует определению [method]
(https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods) в протоколе HTTP. Это необязательный параметр конфигурации. Если он не определён в
конфигурационном файле, сопоставление с частью метода HTTP-запроса не выполняется. -
urlотвечает за сопоставление части URL (путь и строка запроса) HTTP-запроса. Еслиurlначинается с префиксаregex:, ожидаются регулярные выражения RE2. Это необязательный параметр конфигурации. Если он не определён в конфигурационном файле, сопоставление с частью URL HTTP-запроса не выполняется. -
full_urlаналогиченurl, но включает полный URL, т.е.schema://host:port/path?query_string. Обратите внимание, ClickHouse не поддерживает «виртуальные хосты», поэтомуhost— это IP-адрес (а не значение заголовкаHost). -
empty_query_string— обеспечивает отсутствие строки запроса (?query_string) в запросе. -
headersотвечают за сопоставление части заголовков HTTP-запроса. Поддерживают регулярные выражения RE2. Это необязательный параметр конфигурации. Если он не определён в конфигурационном файле, сопоставление с частью заголовков HTTP-запроса не выполняется. -
handlerсодержит основную логику обработки.Для него могут быть заданы следующие значения
type:А также следующие параметры:
query— использовать с типомpredefined_query_handler, выполняет запрос при вызове обработчика.query_param_name— использовать с типомdynamic_query_handler, извлекает и выполняет значение, соответствующее значениюquery_param_nameв параметрах HTTP-запроса.status— использовать с типомstatic, код статуса ответа.content_type— использовать с любым типом, тип содержимого (Content-Type) ответа.http_response_headers— использовать с любым типом, отображение (map) заголовков ответа. Может также использоваться для задания типа содержимого.response_content— использовать с типомstatic, содержимое ответа, отправляемое клиенту; при использовании префиксаfile://илиconfig://содержимое берётся из файла или конфигурации и отправляется клиенту.user— пользователь, от имени которого выполняется запрос (пользователь по умолчанию —default). Обратите внимание, вам не нужно указывать пароль для этого пользователя.
Способы конфигурирования для разных значений type рассматриваются далее.
predefined_query_handler
predefined_query_handler поддерживает установку значений параметров Settings и query_params. В типе predefined_query_handler можно задать параметр query.
Значение query — это предопределённый запрос predefined_query_handler, который выполняется ClickHouse при совпадении HTTP‑запроса и возвращает результат выполнения. Это обязательная настройка.
В следующем примере задаются значения настроек max_threads и max_final_threads, после чего выполняется запрос к системной таблице, чтобы проверить, были ли эти настройки успешно применены.
Чтобы сохранить обработчики по умолчанию, такие как query, play, ping, добавьте правило <defaults/>.
Например:
В одном predefined_query_handler может использоваться только один query.
dynamic_query_handler
В dynamic_query_handler запрос передаётся в параметре HTTP‑запроса. В отличие от predefined_query_handler, где запрос задаётся в конфигурационном файле. Параметр query_param_name можно настроить в dynamic_query_handler.
ClickHouse извлекает и выполняет значение, соответствующее query_param_name в URL HTTP‑запроса. Значение по умолчанию для query_param_name — /query. Это необязательная настройка. Если в конфигурационном файле она не задана, параметр не передаётся.
Чтобы поэкспериментировать с этой функциональностью, в следующем примере задаются значения max_threads и max_final_threads, а затем с помощью запросов проверяется, были ли настройки успешно применены.
Пример:
static
static может возвращать content_type, status и response_content. response_content может возвращать указанное содержимое.
Например, чтобы вернуть сообщение «Say Hi!»:
http_response_headers можно использовать для задания типа содержимого вместо content_type.
Находит в конфигурации содержимое, отправляемое клиенту.
Чтобы определить содержимое файла, отправляемое клиенту:
redirect
redirect выполнит перенаправление с кодом 302 на location.
Например, так можно автоматически добавить SET USER к play для ClickHouse Play:
Заголовки HTTP-ответа
ClickHouse позволяет настраивать произвольные заголовки HTTP-ответов, которые могут быть применены к любым обработчикам, доступным для конфигурирования. Эти заголовки можно задавать с помощью настройки http_response_headers, которая принимает пары ключ-значение, представляющие имена заголовков и их значения. Эта возможность особенно полезна для реализации пользовательских заголовков безопасности, политик CORS или любых других требований к HTTP-заголовкам во всем HTTP-интерфейсе ClickHouse.
Например, вы можете настроить заголовки для:
- Обычных конечных точек (endpoint) для запросов
- Web UI
- Health check.
Также можно задать common_http_response_headers. Они будут применяться ко всем HTTP-обработчикам, определенным в конфигурации.
Заголовки будут включены в HTTP-ответ для каждого настроенного обработчика.
В примере ниже каждый ответ сервера будет содержать два пользовательских заголовка: X-My-Common-Header и X-My-Custom-Header.
Корректный JSON/XML‑ответ при возникновении исключения во время HTTP‑потоковой передачи
Во время выполнения запроса по HTTP может произойти исключение, когда часть данных уже была отправлена. Обычно исключение отправляется клиенту в виде обычного текста.
Даже если для вывода данных использовался определённый формат, результат может оказаться некорректным с точки зрения заданного формата данных.
Чтобы этого избежать, вы можете использовать настройку http_write_exception_in_output_format (по умолчанию отключена), которая укажет ClickHouse записывать исключение в заданном формате (в настоящее время поддерживаются форматы XML и JSON*).
Примеры: