前提条件
- 稼働中の ClickHouse server インスタンス
curlがインストールされていること。Ubuntu または Debian では、sudo apt install curlを実行するか、インストール方法についてはこのドキュメントを参照してください。
概要
clickhouse-server は次のポートで待ち受けます。
- HTTP はポート 8123
- HTTPS はポート 8443 (有効にした場合)
GET / リクエストを送信すると、文字列 “Ok.” とともに 200 のレスポンスコードが返されます。
http_server_default_response で定義されているデフォルト値で、必要に応じて変更できます。
あわせて参照してください: HTTPレスポンスコードに関する注意点。
Webユーザーインターフェイス
GET /ping リクエストを使用してください。このハンドラーは常に “Ok.” を返します (末尾に改行付き) 。バージョン 18.12.13 以降で利用できます。レプリカの遅延を確認するには、関連項目として /replicas_status も参照してください。
HTTP/HTTPS 経由でのクエリ
- リクエストを URL の ‘query’ パラメータとして送信する
- POST メソッドを使用する
- クエリの先頭を ‘query’ パラメータで送り、残りを POST で送信する
URL のサイズはデフォルトで 1 MiB に制限されています。これは
http_max_uri_size 設定で変更できます。SELECT 1 を送信しています。スペースには URL エンコード %20 を使用している点に注意してください。
command
Response
-nv (非冗長) および -O- パラメータを指定した wget を使用し、結果をターミナルに出力します。
この場合、スペースを URL エンコードする必要はありません。
command
command
response
curl コマンドはやや扱いづらく、空白は URL エスケープする必要があります。
wget はすべて自動的にエスケープしてくれますが、keep-alive と Transfer-Encoding: chunked を使用する HTTP 1.1 では正常に動作しないため、使用は推奨していません。
TabSeparated フォーマットで返されます。
別のフォーマットを指定するには、クエリで FORMAT 句を使用します。例:
command
Response
TabSeparated 以外のデフォルトフォーマットを指定するには、default_format URL パラメータを使用できます。X-ClickHouse-Format ヘッダーを使用すると、レスポンスのフォーマットを明示的に指定できます。これは output_format 設定のエイリアスであるため、クエリ内の FORMAT 句もオーバーライドします。INSERT のリクエストボディの解析方法が変更されることはありません。その場合は input_format または format を使用してください。
{name:Type} のように、パラメータ名と型を中かっこで囲んで指定します。パラメータの値は param_name で渡します。
URL パス経由でテーブルにアクセスし、クエリを構築する
パスルーティングを有効にする
- HTTP インターフェイスがパス形式のリクエストをクエリハンドラーにルーティングできるようにする、サーバーレベルの
http_allow_path_requests構成設定を有効にします。
- 必要なユーザーごとの設定を有効にします。
ルーティングは認証前に行われるため、ユーザーごとの設定に依存できません。
http_allow_path_requestsが無効な場合、不明なパスには認証前に404が返されます。ルーティングと認証の後は、ユーザーごとの設定によってパスの解釈方法が決まるため、ユーザー、ロール、またはプロファイル単位でこの機能を選択的に有効にできます。ファイルとしてテーブルにアクセスする
http_allow_table_as_file を有効にすると、/table.format.compression へのリクエストは SELECT * FROM table として処理されます。/database/table.format.compression を使用するには、http_allow_database_as_path を有効にします。
hits.csv と hits.CSV は同等です。
明示的に指定した format または output_format URL パラメータは、パス内のフォーマットを上書きします。一方、default_format は上書きしません。これは、他の指定でフォーマットが選択されていない場合にのみ使用するフォーマットを指定するものであり、パスの拡張子のほうが優先されるためです。明示的に指定した compression パラメータは、パス内の圧縮と一致している必要があります。値が競合する場合は例外が発生します。
クエリを構築する
SETTINGS 句、またはユーザープロファイルで指定できます。
既存のクエリを変更する
?query=SELECT a, b FROM hits&filter=a > 0&sort=-b&limit=10 は次のように実行されます。
predefined_query_handler、または URL パラメータのみを追加できるクライアントなど、別の場所で定義されたクエリの結果をページング、ソート、絞り込む場合に便利です。
FORMAT 句やクエリ内の ORDER BY と併用でき、INSERT が書き込む行を変更することもありません。INSERT ... SELECT ステートメントに指定した構築設定は、ソースの SELECT ではなく、そのステートメント自体の (空の) 結果を形成します。ソースを形成するには、設定を SELECT 自体の SETTINGS 句に指定します。
フォーマットと圧縮のオーバーライド
フォーマット設定は、ネイティブクライアントや
clickhouse-local など、他のプロトコルでも使用できます。input_format と output_format は、それぞれ --input-format および --output-format オプションに対応します。--format オプションは、clickhouse-local では双方向の format 設定に対応しますが、clickhouse-client では従来どおり出力専用として扱われ、output_format に対応します。
compression は HTTP レスポンスの整形に固有で、クエリ実行前に処理されます。HTTP URL パラメータ、パス拡張子、またはユーザープロファイルで指定してください。クエリ内の SETTINGS 句では使用できません。
バイナリまたは圧縮された HTTP レスポンスには、Content-Disposition: attachment; filename=… ヘッダーが含まれます。ファイル名は URL パスから導出され、パスから取得できない場合は result.<format>.<compression> が使用されます。
クエリでパステーブルを使用する
query パラメータも指定した場合、パステーブルは implicit_table_at_top_level を介して公開されます。FROM 句のない SELECT はパステーブルから読み取ります。
FROM 句が含まれている場合、パス部分ではダウンロードするファイル名のみを指定します。
HTTP/HTTPS 経由の INSERT クエリ
INSERT クエリでは、データの送信に POST メソッドを使用する必要があります。この場合、クエリの先頭部分を URL パラメーターに記述し、挿入するデータは POST で渡せます。挿入するデータとしては、たとえば MySQL のタブ区切りの dump を使用できます。このように、INSERT クエリは MySQL の LOAD DATA LOCAL INFILE の代替として使用できます。
例
INSERT クエリを使用します。
INSERT INTO t VALUES の記述時に使用するものと同じ ‘Values’ フォーマットを指定できます:
並列クエリ処理のため、データは順不同で出力されます
圧縮
clickhouse-compressor プログラムが必要です。これは clickhouse-client パッケージとともにデフォルトでインストールされます。
データの insert 効率を高めるには、http_native_compression_disable_checksumming_on_decompress 設定を使用して、サーバー側のチェックサム検証を無効にしてください。
URL に compress=1 を指定すると、サーバーは送信するデータを圧縮します。URL に decompress=1 を指定すると、サーバーは POST method で渡されたデータを展開します。
HTTP 圧縮 を使用することもできます。ClickHouse は次の圧縮方式をサポートしています。
gzipbrdeflatexzzstdlz4bz2snappy
POST リクエストを送信するには、リクエスト header に Content-Encoding: compression_method を追加してください。
ClickHouse にレスポンスを圧縮させるには、リクエストに Accept-Encoding: compression_method header を追加してください。
すべての圧縮方式で、http_zlib_compression_level 設定を使用してデータの圧縮レベルを設定できます。
一部の HTTP クライアントは、デフォルトでサーバーからのデータを展開する場合があります (
gzip および deflate) 。そのため、圧縮設定を正しく使用していても、展開後のデータを受け取ることがあります。例
デフォルトデータベース
database URL パラメータまたは X-ClickHouse-Database ヘッダーで、デフォルトのデータベースを指定できます。
default という名前のデータベースです。別の方法として、テーブル名の前にドット区切りでデータベース名を付けて、いつでもデータベースを指定できます。
認証
- HTTP Basic認証を使用する方法。
userおよびpasswordの URL パラメータ内
- ‘X-ClickHouse-User’ および ‘X-ClickHouse-Key’ ヘッダーを使用する
default が使用されます。パスワードが指定されていない場合は、空のパスワードが使用されます。
また、URL パラメータを使って、単一のクエリの処理に対する設定や、設定プロファイル全体を指定することもできます。
たとえば:
HTTPプロトコルでClickHouseセッションを使用する
session_id GET パラメータを追加する必要があります。セッションIDには任意の文字列を使用できます。
デフォルトでは、セッションは60秒間非アクティブな状態が続くと終了します。このタイムアウト (秒単位) を変更するには、サーバー設定の default_session_timeout を変更するか、リクエストに session_timeout GET パラメータを追加します。
セッションの状態を確認するには、session_check=1 パラメータを使用します。1つのセッション内で同時に実行できるクエリは1つだけです。
クエリの進行状況に関する情報は、X-ClickHouse-Progress レスポンスヘッダーで受け取ることができます。これを行うには、send_progress_in_http_headers を有効にします。
以下はヘッダーシーケンスの例です:
実行中のリクエストは、HTTP接続が失われても自動的には停止しません。パースとデータのフォーマットはサーバー側で行われるため、ネットワーク越しでは非効率になる場合があります。
次のオプションパラメーターがあります。
HTTP インターフェイスでは、クエリのために外部データ (外部一時テーブル) を渡すこともできます。詳細については、“クエリ処理用の外部データ” を参照してください。
レスポンスのバッファリング
buffer_sizewait_end_of_query
buffer_size は、サーバーのメモリ内で結果をバッファリングするバイト数を決定します。結果のボディがこのしきい値を超える場合、バッファはHTTPチャネルに書き込まれ、残りのデータはHTTPチャネルに直接送信されます。
レスポンス全体が確実にバッファリングされるようにするには、wait_end_of_query=1 を設定します。この場合、メモリに格納されないデータは、一時サーバーファイルにバッファリングされます。
たとえば:
クエリパラメータでロールを設定する
SET ROLE とステートメントを一緒に送信することはできません。
role クエリパラメータを使用してください。
SET ROLE my_role を実行するのと同じです。
さらに、複数の role クエリパラメータを指定することも可能です。
?role=my_role&role=my_other_role は、ステートメントの前に SET ROLE my_role, my_other_role を実行するのと同じように機能します。
HTTPレスポンスコードに関する注意点
Native、TSV、JSON など、どのフォーマットを使用しているかに関係ありません。エラーメッセージは常にレスポンスストリームの途中に現れます。
この問題は、wait_end_of_query=1 (レスポンスのバッファリング) を有効にすることで緩和できます。この場合、HTTP ヘッダー の送信はクエリ全体の処理が完了するまで遅延されます。ただし、これでも問題が完全に解決するわけではありません。結果は依然として http_response_buffer_size の範囲内に収まる必要があり、さらに send_progress_in_http_headers などの設定によって ヘッダー の送信遅延が妨げられることもあるためです。
ClickHouse では、このような例外は http_write_exception_in_output_format=0 (デフォルト) の場合、使用するフォーマット (Native、TSV、JSON など) に関係なく、以下のような一貫した例外フォーマットになります。そのため、クライアント側でエラーメッセージを簡単にパースして抽出できます。
<TAG> は 16 バイトのランダムなタグで、X-ClickHouse-Exception-Tag レスポンスヘッダーで送信されるタグと同じものです。
<error message> は実際の例外メッセージです (正確な長さは <message_length> で確認できます) 。上で説明した例外ブロック全体のサイズは最大 16 KiB です。
以下は JSON フォーマットの例です
CSVフォーマットの同様の例です
パラメータ付きクエリ
例
URL パラメータ内のタブ
escaped フォーマットとして解析されます。これには、たとえば NULL を \N として曖昧さなく解析できるといった利点があります。つまり、タブ文字は \t (または \ とタブ文字) としてエンコードする必要があります。たとえば、次の例では abc と 123 の間に実際のタブが含まれており、入力文字列は 2 つの値に分割されます。
%09 を使って実際のタブ文字をエンコードしようとしても、正しくパースされません:
\t は %5C%09 にエンコードする必要があります。例:
事前定義済み HTTP インターフェイス
http_handlers は複数の rule を含むように設定します。ClickHouse は受信した HTTP リクエストを rule で事前定義された種類に照らして照合し、最初に一致したルールのハンドラーを実行します。一致に成功すると、ClickHouse は対応する事前定義済みクエリを実行します。
config.xml
http_handlers の設定オプションは次のとおりです。
rule では、以下のパラメータを設定できます。
methodheadersurlfull_urlhandler
-
methodは、HTTPリクエストの method 部分の照合を担当します。methodは、HTTPプロトコルにおける [method] (https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods) の定義に完全に準拠しています。これは任意の設定です。設定ファイルで定義されていない場合、 HTTPリクエストの method 部分は照合されません。 -
urlは、HTTPリクエストの URL 部分 (パスとクエリ文字列) の照合を担当します。urlにregex:プレフィックスが付いている場合は、RE2 の正規表現を使用します。 これは任意の設定です。設定ファイルで定義されていない場合、HTTPリクエストの URL 部分は照合されません。 -
full_urlはurlと同じですが、schema://host:port/path?query_stringのような完全な URL を含みます。 注意: ClickHouse は “virtual hosts” をサポートしていないため、hostは IP アドレスです (Hostヘッダーの値ではありません) 。 -
empty_query_string- リクエストにクエリ文字列 (?query_string) が含まれていないことを保証します -
headersは、HTTPリクエストのヘッダー部分の照合を担当します。RE2 の正規表現と互換性があります。これは任意の 設定です。設定ファイルで定義されていない場合、HTTPリクエストのヘッダー部分は照合されません。 -
handlerには主要な処理部分が含まれます。 指定できるtypeは次のとおりです: また、次のパラメータがあります:query—predefined_query_handlertype で使用し、ハンドラーが呼び出されたときにクエリを実行します。query_param_name—dynamic_query_handlertype で使用し、HTTPリクエストパラメータからquery_param_nameの値に対応する値を抽出して実行します。status—statictype で使用し、レスポンスのステータスコードを指定します。content_type— 任意の type で使用し、レスポンスの content-type を指定します。http_response_headers— 任意の type で使用し、レスポンスヘッダーの map を指定します。content type の設定にも使用できます。response_content—statictype で使用し、クライアントに送信するレスポンス内容を指定します。プレフィックス ‘file://’ または ‘config://’ を使用する場合は、file または設定から内容を取得してクライアントに送信します。user- クエリの実行に使用する user です (default user はdefaultです) 。 注意: この user の password を指定する必要はありません。
type の設定方法については、次で説明します。
predefined_query_handler
predefined_query_handler では、Settings と query_params の値を設定できます。predefined_query_handler 型では query を設定できます。
query の値は predefined_query_handler 用の事前定義済みクエリで、HTTP リクエストが一致すると ClickHouse によって実行され、その結果が返されます。これは必須の設定です。
次の例では、max_threads および max_final_threads の設定値を定義し、その後 system table にクエリして、これらの設定が正しく適用されたかどうかを確認します。
query、play、ping などのデフォルトの handlers を維持するには、<defaults/> ルールを追加してください。仮想パラメータ _request_body
predefined_query_handler は特殊な仮想パラメータ _request_body もサポートしています。
これは、生の HTTP リクエストボディを文字列として保持します。
これにより、任意のデータフォーマットを受け付け、それをクエリ内で処理できる柔軟な REST API を作成できます。
たとえば、_request_body を使用して、POST リクエストで JSON データを受け取り、それをテーブルに挿入する REST エンドポイント を実装できます。
1 つの
predefined_query_handler でサポートされる query は 1 つだけです。dynamic_query_handler
dynamic_query_handler では、クエリを HTTP リクエストのパラメータとして記述します。predefined_query_handler との違いは、predefined_query_handler ではクエリを設定ファイルに記述する点です。query_param_name は dynamic_query_handler で設定できます。
ClickHouse は、HTTP リクエストの URL から query_param_name に対応する値を取り出して実行します。query_param_name のデフォルト値は /query です。これは任意の設定です。設定ファイルに定義がない場合、このパラメータは渡されません。
この機能を試すために、次の例では max_threads と max_final_threads の値を定義し、設定が正常に反映されたかどうかを確認する queries を実行します。
例:
static
static では、content_type、status、および response_content を返せます。response_content では、指定した内容を返せます。
例えば、“Say Hi!” というメッセージを返すには:
http_response_headers を使うと、content_type の代わりにコンテンツタイプを設定できます。
redirect
redirect は location に 302 リダイレクトします
たとえば、ClickHouse play の play に set user を自動的に追加するには、次のようにします:
HTTP レスポンスヘッダー
http_response_headers 設定で指定でき、ヘッダー名とその値を表すキー・バリューのペアを受け付けます。この機能は、カスタムのセキュリティヘッダーや CORS ポリシー、その他 ClickHouse HTTP インターフェイス全体で必要となる HTTP ヘッダー要件に対応する際に特に便利です。
たとえば、次のものに対してヘッダーを設定できます。
- 通常のクエリエンドポイント
- Web UI
- ヘルスチェック
common_http_response_headers を指定することもできます。これらは、設定で定義されたすべての HTTP ハンドラーに適用されます。
ヘッダーは、設定された各ハンドラーの HTTP レスポンスに含まれます。
以下の例では、すべてのサーバーからのレスポンスに 2 つのカスタムヘッダー X-My-Common-Header と X-My-Custom-Header が含まれます。
HTTP streaming 中の例外発生時に有効な JSON/XML レスポンス
http_write_exception_in_output_format (デフォルトでは無効) を使用します。この設定により、ClickHouse は指定したフォーマットで例外を書き出します (現在は XML および JSON* フォーマットをサポートしています) 。
例: