ClickHouse リリース 26.9

9 月になり、ClickHouse 26.9 が数多くの新機能とともにリリースされました。

ClickHouse 26.9 リリースには、56 件の新機能 🍁、135 件のパフォーマンス最適化 🍎、464 件のバグ修正 🐿️ が含まれています。

本リリースでは、LIMIT の境界条件指定、追記専用マテリアライズドビューのインクリメンタルリフレッシュ、高カーディナリティの DISTINCT クエリにおけるディスクスピルが導入されました。

また、有効期限付きアクセストークン、min・max・count クエリの高速化、PromQL サポートの拡張、利便性を高めるさまざまな改善についても見ていきます。

新しいコントリビューター

26.9 のすべての新しいコントリビューターの皆さまを心より歓迎します。ClickHouse コミュニティの成長には目を見張るものがあり、ClickHouse をこれほど支持される存在にしてくださった皆さまの貢献にいつも感謝しています。

新しいコントリビューターのお名前は以下のとおりです。

Aaron Harlap, Actuele AI, Alex Francoeur, Alex Prabhat Bara, AlexF, Anand Kumar Shaw, Anton Kovalenko, Aparajita Pandey, Brandon Pereira, Claude, Denys Stetsenko, Dmitrii Bezrukov, Evandro Leopoldino Gonçalves, Friedrich ten Hagen, George Viamontes, Gülçin Yıldırım Jelinek, Hamza Wasim, Hank Hoffmeier, Héctor Pablos, Itamar Tempelhof, Ivan N. Taranov, Ivan Tkachev, Ivan Tkatchev, Jithin Zachariah, Jordan Bertasso, Jords, Joshua, Juanjo, Kelly Toole, Lucas, Luis Neves, Luís Lizardo, Marat Dulin, Mike Shi, Navneet Kumar, Pablo Francisco Pérez Hidalgo, Paul Annesley, Philip Li, Pratham Nayak, Pratheesh, SamWolfberg, Sankalp Thakur, Sebastian Vercruyssse, Serhiy Bzhezytskyy, Takayuki Enomoto, Thien Phan, Vadim Ilves, XanderYoon, Yongqiang Tian, alexprabhat99, anand-tradesea, aparajita, bakhtiiartashbolotov, cuishuang, jithinzac, kasimtj, key-arg, kyungryun, linsen, maederm, mariahlynnenagy, miao tang, mosya415, ngagejason, sakshichitnis27, sleepingeight, statxc, t, tars, zhanglangning

ヒント: このリストをどのように生成しているか興味がある方は、こちらをご覧ください。

また、プレゼンテーションのスライドも確認できます。

DateTime と Time の算術演算

コントリビューター: Yarik Briukhovetskyi

ClickHouse 26.9 以降、DateTime 値の加算・減算において、Time 値をオフセットとして使用できるようになりました。計算結果は元の DateTime 値のタイムゾーンを保持します。

簡単な例を見てみましょう。

1SELECT
2    now() AS now,
3    now + toTime('02:00:00'),
4    toTime('04:00:00') + now,
5    now64() AS now64,
6    now64 - toTime('02:00:00'),
7    now64 - toTime64('02:00:00.417', 3)
8FORMAT Vertical;

1Row 1:
2──────
3now:                      2026-09-21 13:49:06
4plus(now, to⋯02:00:00')): 2026-09-21 15:49:06
5plus(toTime(⋯:00'), now): 2026-09-21 17:49:06
6now64:                    2026-09-21 13:49:06.440
7minus(now64,⋯02:00:00')): 2026-09-21 11:49:06.440
8minus(now64,⋯0.417', 3)): 2026-09-21 11:49:06.023

計算結果が戻り値の型でサポートされる範囲外になった場合、date_time_overflow_behavior の設定によって、ClickHouse が例外をスローするか、最も近い境界値にクランプするか、オーバーフローをチェックしないかが決まります。

DateTime に格納できる最大値は 2106-02-07 06:28:15 です。この時刻に 1 秒を加算するとどうなるか確認してみましょう。

1SELECT
2      toDateTime('2106-02-07 06:28:15', 'UTC')
3      + toTime('00:00:01');

1┌─plus(toDateT⋯00:00:01'))─┐
2│      1970-01-01 00:00:00 │
3└──────────────────────────┘

date_time_overflow_behavior のデフォルト値は ignore であるため、予想どおり DateTime の最小値へとオーバーフローしました。しかし、値がオーバーフローした場合には例外を発生させたいこともあります。

1SELECT toDateTime('2106-02-07 06:28:15', 'UTC') + toTime('00:00:01')
2SETTINGS date_time_overflow_behavior = 'throw';

1Received exception:
2Code: 321. DB::Exception: Value 4294967296 is out of bounds of type DateTime: In scope SELECT toDateTime('2106-02-07 06:28:15', 'UTC') + toTime('00:00:01') SETTINGS date_time_overflow_behavior = 'throw'. (VALUE_IS_OUT_OF_RANGE_OF_DATA_TYPE)

あるいは、saturate を使用することもできます。その場合、その型の最大値が返されます。

1SELECT toDateTime('2106-02-07 06:28:10', 'UTC') + toTime('00:00:10')
2SETTINGS date_time_overflow_behavior = 'saturate';

1┌─plus(toDateT⋯00:00:10'))─┐
2│      2106-02-07 06:28:15 │
3└──────────────────────────┘

最後に、初期値と計算後の値のタイムゾーンを確認してみましょう。

1SELECT
2    now() AS now,
3    timezoneOf(now),
4    now + toTime('02:00:00') AS future,
5    timezoneOf(future)
6FORMAT Vertical;

1Row 1:
2──────
3now:                2026-09-21 14:37:21
4timezoneOf(now):    Europe/London
5future:             2026-09-21 16:37:21
6timezoneOf(future): Europe/London

PromQL のプライベートプレビュー

コントリビューター: Vitaly Baranov、Nikita Mikhaylov、Valery Petrov、Minh Vu

ClickHouse 26.9 では、対応関数の拡充、Prometheus HTTP API エンドポイントの追加、TimeSeries テーブルに対する直接の SELECT クエリのサポートにより、PromQL サポートが拡張されました。

PromQL と TimeSeries テーブルエンジンは ClickHouse Cloud でプライベートプレビューとして利用可能になり、メトリクスを ClickHouse に保存して ClickStack、Grafana、clickhouse-client、SQL から照会できるようになりました。

詳細については、ブログ記事「ClickHouseの新しいTimeSeriesエンジンのご紹介」をご覧ください。

CREATE TOKEN

コントリビューター: Alexey Milovidov

ClickHouse 26.9 では CREATE TOKEN が導入されました。これにより、メインのパスワードを公開したり変更したりすることなく、アプリケーション、スクリプト、CI ジョブ、エージェント向けに有効期限付きの認証情報を作成できます。

トークンはユーザーの既存の権限のサブセットに制限できるため、認証情報が漏洩した際の影響を軽減できます。

動作を見てみましょう。まず、小さなテーブルを作成します。

1CREATE TABLE ourTable
2(
3    id UInt8
4);
5
6INSERT INTO ourTable VALUES (1);

次に、alexey というユーザーを作成します。

1CREATE USER alexey IDENTIFIED WITH sha256_password BY 'main-password';
2GRANT SELECT, INSERT ON ourTable TO alexey;
3GRANT CREATE TOKEN ON *.* TO alexey;

alexey はこのテーブルに対する SELECT および INSERT 権限を持っており、自身のトークンを作成することもできます。

続いて、alexey として接続し、有効期間が 30 日間で ourTable に対する SELECT クエリのみを実行できるトークンを作成します。

1CREATE TOKEN
2VALID FOR INTERVAL 30 DAY
3GRANTS (SELECT ON ourTable);

この文を実行すると、生成されたトークンとその有効期限が返されます。

1┌─token────────────────────────────┬─────────valid_until─┐
2│ NXuRnBywn4HcHCIyBWC2WHT2Cfn4xQLb │ 2026-10-21 15:07:57 │
3└──────────────────────────────────┴─────────────────────┘

トークンは一度しか表示されないため、必ず控えておいてください。

このトークンを使って接続し、SELECT クエリを実行できます。

1./clickhouse client \
2--user alexey \
3--password 'NXuRnBywn4HcHCIyBWC2WHT2Cfn4xQLb' \
4--query "SELECT * FROM ourTable"

予想どおり正常に動作しました。では、このトークンを使ってテーブルに挿入しようとするとどうなるでしょうか。

1./clickhouse client \
2--user alexey \
3--password 'NXuRnBywn4HcHCIyBWC2WHT2Cfn4xQLb' \
4--query "INSERT INTO ourTable VALUES (2)"

1Code: 497. DB::Exception: alexey: Not enough privileges. To execute this query, it's necessary to have the grant INSERT(id) ON db.`table`. (ACCESS_DENIED)

トークンを使用して認証された場合、alexey は SELECT アクセス権しか持たないため、エラーになります。

トークンによってユーザーがすでに持っている以上の権限が付与されることはなく、有効期限が切れた場合やユーザーが削除された場合には機能しなくなります。VALID UNTIL または VALID FOR を指定しない場合、デフォルトの有効期間は 30 分です。

境界条件付き LIMIT

コントリビューター: Zakhar Kravchuk、Nihal Miaji

ClickHouse 26.9 では、ソートされた結果ストリーム内の値に基づいて出力を開始・終了する境界条件により、LIMIT が拡張されました。私たちの知る限り、この機能は現在他のどのデータベースにも存在しません。

AFTER: 条件に一致する行を含めます。
UNTIL: 条件に一致する行の手前で停止します。
ALL: 条件が一致するたびに境界を適用します。

以下のさまざまな組み合わせを試して、各クエリがどの行を返すか確認してみてください。

この機能はログデータの分析に特に役立ちます。ブログ記事「列指向ストレージによる Nginx ログの 170 倍圧縮」で使用された Nginx データセットを使って見てみましょう。

まず、テーブルを作成します。

1CREATE TABLE nginx_logs
2(
3    timestamp DateTime,
4    ip String,
5    method LowCardinality(String),
6    path String,
7    status UInt16,
8    response_bytes UInt64,
9    referer String,
10    user_agent String
11)
12ENGINE = MergeTree
13ORDER BY (timestamp, ip, path);

次に、データを取り込みます。

1INSERT INTO nginx_logs
2WITH extractGroups(
3    line,
4    '^(\\S+) - \\S+ \\[([^\\]]+)\\] "(\\S+) (.*) [^ ]+" (\\d+) (\\d+) "([^"]*)" "(.*)"$'
5) AS fields
6SELECT
7    assumeNotNull(parseDateTimeBestEffortOrNull(fields[2])) AS timestamp,
8    fields[1] AS ip,
9    fields[3] AS method,
10    fields[4] AS path,
11    toUInt16(fields[5]) AS status,
12    toUInt64(fields[6]) AS response_bytes,
13    fields[7] AS referer,
14    fields[8] AS user_agent
15FROM s3(
16    'https://datasets-documentation.s3.eu-west-3.amazonaws.com/http_logs/nginx-66.log.gz',
17    LineAsString
18)
19WHERE length(fields) = 8
20  AND parseDateTimeBestEffortOrNull(fields[2]) IS NOT NULL;

では、データの概要を手短に確認します。

1SELECT
2    count() AS rows,
3    min(timestamp) AS first_timestamp,
4    max(timestamp) AS last_timestamp,
5    countIf(status >= 500) AS server_errors
6FROM nginx_logs;

1Row 1:
2──────
3rows:            66514081 -- 66.51 million
4first_timestamp: 2019-01-24 00:00:00
5last_timestamp:  2019-02-24 00:00:00
6server_errors:   69857

次のクエリは、最初の 5xx レスポンスから開始して 5 つのリクエストを返します。AFTER は該当行を含むため、条件を満たすリクエストが含まれます。

1SELECT timestamp, path, status
2FROM nginx_logs
3WHERE ip = '91.243.160.31'
4  AND timestamp >= '2019-01-24 00:00:00'
5  AND timestamp < '2019-02-03 00:00:00'
6ORDER BY timestamp, ip, path, method, status, response_bytes
7LIMIT 5 AFTER status >= 500;

1┌───────────timestamp─┬─path─────────────────────────────────────────────────────────┬─status─┐
2│ 2019-01-24 06:54:01 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
3│ 2019-01-24 06:54:02 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
4│ 2019-01-24 06:54:06 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
5│ 2019-01-24 06:54:15 │ /product/552/1168/مایکروفر-رومیزی-ال-جی-مدل-MS93SCR          │    200 │
6│ 2019-01-24 06:54:16 │ /image/552/product/50x50                                     │    200 │
7└─────────────────────┴──────────────────────────────────────────────────────────────┴────────┘

UNTIL は該当行を含みません。このクエリは、最初のサーバーエラーから開始し、ステータスが 500 未満の最初のレスポンスの手前で停止します。

1SELECT timestamp, path, status
2FROM nginx_logs
3WHERE ip = '91.243.160.31'
4  AND timestamp >= '2019-01-24 00:00:00'
5  AND timestamp < '2019-02-03 00:00:00'
6ORDER BY timestamp, ip, path, method, status, response_bytes
7LIMIT 100
8    AFTER status >= 500
9    UNTIL status < 500;

1┌───────────timestamp─┬─path─────────────────────────────────────────────────────────┬─status─┐
2│ 2019-01-24 06:54:01 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
3│ 2019-01-24 06:54:02 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
4│ 2019-01-24 06:54:06 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
5└─────────────────────┴──────────────────────────────────────────────────────────────┴────────┘

AFTER 境界は 1 回だけ適用されますが、ALL を使用すると、別の行が一致するたびに境界が再適用されます。このクエリは、すべてのサーバーエラーと、その後に続く 2 つのリクエストを返します。

1SELECT timestamp, path, status
2FROM nginx_logs
3WHERE ip = '91.243.160.31'
4  AND timestamp >= '2019-01-24 00:00:00'
5  AND timestamp < '2019-02-03 00:00:00'
6ORDER BY timestamp, ip, path, method, status, response_bytes
7LIMIT 3 AFTER status >= 500 ALL;

1┌───────────timestamp─┬─path─────────────────────────────────────────────────────────┬─status─┐
2│ 2019-01-24 06:54:01 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
3│ 2019-01-24 06:54:02 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
4│ 2019-01-24 06:54:06 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
5│ 2019-01-24 06:54:15 │ /product/552/1168/مایکروفر-رومیزی-ال-جی-مدل-MS93SCR          │    200 │
6│ 2019-01-24 06:54:16 │ /image/552/product/50x50                                     │    200 │
7│ 2019-01-28 23:27:00 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
8│ 2019-01-28 23:27:01 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
9│ 2019-01-28 23:27:05 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
10│ 2019-01-28 23:27:14 │ /product/552/1168/مایکروفر-رومیزی-ال-جی-مدل-MS93SCR          │    200 │
11│ 2019-01-28 23:27:15 │ /image/552/product/50x50                                     │    200 │
12│ 2019-02-02 13:43:29 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
13│ 2019-02-02 13:43:30 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
14│ 2019-02-02 13:43:34 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
15│ 2019-02-02 13:43:43 │ /product/552/1168/مایکروفر-رومیزی-ال-جی-مدل-MS93SCR          │    200 │
16│ 2019-02-02 13:43:44 │ /image/552/product/50x50                                     │    200 │
17└─────────────────────┴──────────────────────────────────────────────────────────────┴────────┘

この期間中、行 2、7、12 で 3 つのインシデントが個別に発生しています。各バースト内では、500 レスポンスが発生するたびに 3 行の境界が再適用されます。

そのため、連続した障害によってアクティブなウィンドウが延長され、最後の障害の後に 5xx 以外のリクエストが 2 回連続して発生するまで続きます。この例では、どちらも成功を表す 200 レスポンスです。

また、ALL で開始境界を再適用しつつ、UNTIL で各範囲を終了させることもできます。

1SELECT timestamp, path, status
2FROM nginx_logs
3WHERE ip = '91.243.160.31'
4  AND timestamp >= '2019-01-24 00:00:00'
5  AND timestamp < '2019-02-03 00:00:00'
6ORDER BY timestamp, ip, path, method, status, response_bytes
7LIMIT 100
8    AFTER status >= 500 ALL
9    UNTIL status < 500;

1┌───────────timestamp─┬─path─────────────────────────────────────────────────────────┬─status─┐
2│ 2019-01-24 06:54:01 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
3│ 2019-01-24 06:54:02 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
4│ 2019-01-24 06:54:06 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
5│ 2019-01-28 23:27:00 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
6│ 2019-01-28 23:27:01 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
7│ 2019-01-28 23:27:05 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
8│ 2019-02-02 13:43:29 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
9│ 2019-02-02 13:43:30 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
10│ 2019-02-02 13:43:34 │ /product/28579/57435/اجاق-گاز-صفحه-ای-داتیس-مدل-DG-503-Ultra │    500 │
11└─────────────────────┴──────────────────────────────────────────────────────────────┴────────┘

先ほどのクエリとは異なり、この出力には各障害バーストの後の成功リクエストは含まれません。UNTIL は 5xx 以外の最初のレスポンスで範囲を閉じ、ALL は次のバーストのスキャンを継続します。

インクリメンタル・リフレッシャブルマテリアライズドビュー

コントリビューター: Smita Kulkarni

ClickHouse 26.9 では、リフレッシャブルマテリアライズドビューに APPEND INCREMENTAL が追加されました。リフレッシュのたびにソーステーブル全体をスキャンする代わりに、ClickHouse は前回の更新以降にコミットされた行のみを処理します。

これを使用して、追記専用データを別の ClickHouse テーブルへ増分コピーしたり、MergeTree テーブルから Iceberg データレイクへイベントストリームをレプリケーションしたりできます。

Iceberg でこの機能を使用する方法を見てみましょう。

ClickHouse で注文イベントの追記専用ストリームを作成し、それを定期的に Iceberg テーブルにコピーすることで、更新ごとに新しくコミットされた行のみが処理される様子を示します。

まず、ClickHouse テーブルを作成します。

1CREATE TABLE order_events
2(
3    event_id UInt64,
4    event_time DateTime,
5    order_id UInt64,
6    event_type LowCardinality(String),
7    country LowCardinality(String),
8    amount Decimal(10, 2)
9)
10ORDER BY (event_time, order_id, event_id)
11SETTINGS
12    enable_block_number_column = 1,
13    enable_block_offset_column = 1,
14    add_minmax_index_for_block_number_column = 1,
15    add_minmax_index_for_block_offset_column = 1,
16    part_minmax_index_columns = 'with_block_number_offset';

ブロック番号とブロックオフセットのカラムは、前回の更新以降にコミットされた行を識別するために ClickHouse が使用するカーソルを提供します。

次に、Iceberg への挿入を有効にし、ローカルファイルシステム上に Iceberg テーブルを作成します。

1SET allow_insert_into_iceberg = 1;
2CREATE TABLE lake_order_events
3(
4    event_id UInt64,
5    event_time DateTime,
6    order_id UInt64,
7    event_type String,
8    country String,
9    amount Decimal(10, 2)
10)
11ENGINE = IcebergLocal('lake_order_events', 'Parquet');

lake_order_events ディレクトリには、Iceberg のメタデータ、マニフェスト、および Parquet データファイルが含まれます。

最後に、新しくコミットされたイベントを 1 時間ごとに Iceberg にコピーするマテリアライズドビューを作成します。

1CREATE MATERIALIZED VIEW order_events_to_iceberg
2REFRESH EVERY 1 HOUR APPEND INCREMENTAL
3TO lake_order_events
4AS
5SELECT event_id, event_time, order_id, event_type, country, amount
6FROM order_events;

データを取り込みます。

1INSERT INTO order_events VALUES
2    (1, '2026-09-22 09:05:00', 1001, 'placed', 'UK',       0),
3    (2, '2026-09-22 09:17:00', 1002, 'placed', 'Germany',  0),
4    (3, '2026-09-22 09:20:00', 1001, 'paid',   'UK',      89.99),
5    (4, '2026-09-22 09:31:00', 1002, 'paid',   'Germany', 129.00);

これらのイベントは、マテリアライズドビューが 1 時間ごとにトリガーされた際に Iceberg テーブルにコピーされますが、確認を早めるために手動で更新をトリガーします。

1SYSTEM REFRESH VIEW order_events_to_iceberg;
2SYSTEM WAIT VIEW order_events_to_iceberg;

そして、Iceberg テーブルを照会してみます。

1SELECT * FROM lake_order_events;

1┌─event_id─┬─────────────────event_time─┬─order_id─┬─event_type─┬─country─┬─amount─┐
2│        1 │ 2026-09-22 09:05:00.000000 │     1001 │ placed     │ UK      │      0 │
3│        2 │ 2026-09-22 09:17:00.000000 │     1002 │ placed     │ Germany │      0 │
4│        3 │ 2026-09-22 09:20:00.000000 │     1001 │ paid       │ UK      │  89.99 │
5│        4 │ 2026-09-22 09:31:00.000000 │     1002 │ paid       │ Germany │    129 │
6└──────────┴────────────────────────────┴──────────┴────────────┴─────────┴────────┘

すべてのレコードがコピーされました。次に、注文の変更をシミュレートするために行をいくつか追加してみましょう。

1INSERT INTO order_events VALUES
2    (5, '2026-09-22 10:03:00', 1001, 'shipped',  'UK',        0),
3    (6, '2026-09-22 10:11:00', 1002, 'refunded', 'Germany', -129.00),
4    (7, '2026-09-22 10:28:00', 1003, 'placed',   'France',     0);

マテリアライズドビューを手動で再度更新し、Iceberg テーブルをもう一度照会します。

1┌─event_id─┬─────────────────event_time─┬─order_id─┬─event_type─┬─country─┬─amount─┐
2│        1 │ 2026-09-22 09:05:00.000000 │     1001 │ placed     │ UK      │      0 │
3│        2 │ 2026-09-22 09:17:00.000000 │     1002 │ placed     │ Germany │      0 │
4│        3 │ 2026-09-22 09:20:00.000000 │     1001 │ paid       │ UK      │  89.99 │
5│        4 │ 2026-09-22 09:31:00.000000 │     1002 │ paid       │ Germany │    129 │
6│        5 │ 2026-09-22 10:03:00.000000 │     1001 │ shipped    │ UK      │      0 │
7│        6 │ 2026-09-22 10:11:00.000000 │     1002 │ refunded   │ Germany │   -129 │
8│        7 │ 2026-09-22 10:28:00.000000 │     1003 │ placed     │ France  │      0 │
9└──────────┴────────────────────────────┴──────────┴────────────┴─────────┴────────┘

3 つの新しいイベントが追加されていることが確認できます。

Iceberg ターゲットの場合、ClickHouse はスナップショットのサマリー内にインクリメンタルカーソルを保存します。したがって、カーソルと新しく追記されたデータは、同じ Iceberg スナップショットの一部としてコミットされます。これは system.iceberg_history を照会することで確認できます。

1SELECT
2    made_current_at, operation,
3    summary['added-records'] AS added_records,
4    summary['total-records'] AS total_records,
5    summary['total-data-files'] AS total_data_files,
6    summary['clickhouse.refresh-cursor'] != '' AS has_refresh_cursor
7FROM system.iceberg_history
8WHERE table = 'lake_order_events'
9ORDER BY made_current_at;

1┌─────────made_current_at─┬─operation─┬─added_records─┬─total_records─┬─total_data_files─┬─has_refresh_cursor─┐
2│ 2026-09-22 11:03:47.549 │ APPEND    │ 4             │ 4             │ 1                │                  1 │
3│ 2026-09-22 11:04:36.247 │ APPEND    │ 3             │ 7             │ 2                │                  1 │
4└─────────────────────────┴───────────┴───────────────┴───────────────┴──────────────────┴────────────────────┘

1 回目の更新で 4 件のレコードが追加され、2 回目では 3 件の新しいイベントのみが追加されて、合計が 4 件から 7 件になりました。また、両方のスナップショットに更新カーソルが含まれていることもわかります。

ClickHouse は、新しく追記されたデータとともに、このカーソルを Iceberg スナップショット内に保存します。ClickHouse が再起動した場合でも、次の更新は同じイベントを再処理するのではなく、その位置から再開します。カーソルは追記が成功したときにのみ進むため、常にデータと同期した状態が保たれます。

このアプローチは、イベント、ログ、監査レコード、その他の不変のファクトデータなど、追記専用のデータに最適です。

カラム統計からの min、max、count

コントリビューター: Alexey Milovidov

ClickHouse は、各データパート内に数値系カラムの最小値と最大値を保持しています。26.9 からは、基盤となるカラムデータを読み取ることなく、これらの統計情報を使用して min、max、count クエリに応答できるようになりました。

先ほど使用した Nginx ログテーブルで試してみましょう。timestamp ではなく response_bytes を使用します。timestamp はテーブルのソートキーの最初のカラムであるため、ClickHouse はすでに既存のメタデータからそのクエリに応答できます。

クエリプランを確認できるように、クエリの先頭に EXPLAIN を付けます。

1EXPLAIN
2SELECT
3    min(response_bytes),
4    max(response_bytes),
5    count()
6FROM nginx_logs;

1┌─explain──────────────────────────────────────────────────────────┐
2│ Output: min(response_bytes), max(response_bytes), count()        │
3│                                                                  │
4│ Aggregating                                                      │
5│ │  Keys:                                                         │
6│ │  Aggregates: min(response_bytes), max(response_bytes), count() │
7│ │  Skip merging: 0                                               │
8│ └──ReadFromPreparedSource (_statistics_min_max_projection)       │
9└──────────────────────────────────────────────────────────────────┘

最後の行を見ると、ClickHouse が response_bytes カラムを読み取る代わりに、カラム統計から結果を準備していることがわかります。

この最適化は use_statistics_for_min_max_aggregation 設定で無効化できます。無効にすると、次のクエリに示すように、ClickHouse は結果を計算するために response_bytes カラムをスキャンする必要があります。

1EXPLAIN
2SELECT
3    min(response_bytes),
4    max(response_bytes),
5    count()
6FROM nginx_logs
7SETTINGS use_statistics_for_min_max_aggregation = 0;

1┌─explain──────────────────────────────────────────────────────────┐
2│ Output: min(response_bytes), max(response_bytes), count()        │
3│                                                                  │
4│ Aggregating                                                      │
5│ │  Keys:                                                         │
6│ │  Aggregates: min(response_bytes), max(response_bytes), count() │
7│ │  Skip merging: 0                                               │
8│ └──ReadFromMergeTree (default.nginx_logs)                        │
9│       Read type: Default                                         │
10│       Parts: 5 | Granules: 8122                                  │
11│       Output: response_bytes                                     │
12└──────────────────────────────────────────────────────────────────┘

`system.session_query_ids`

コントリビューター: Vladimir Cherkasov

ClickHouse 26.9 では新しいシステムテーブル system.session_query_ids が導入されました。このテーブルは、現在のセッション内のすべてのクエリ ID を実行順に追跡します。

このテーブルは次のように照会できます。

1SELECT * FROM system.session_query_ids;

1┌─sequence_number─┬─query_id─────────────────────────────┐
2│               1 │ 8ebdec91-0636-44e7-9d1a-66974c2d0fe3 │
3│               2 │ 471e8bef-2042-4394-9a08-3538f4ebcf85 │
4│               3 │ f9757bd2-8fe3-4b14-b681-8e938a396880 │
5│               4 │ 36903bb2-9f85-420b-b37b-66f0d23ce41e │
6│               5 │ 4127be18-3e58-45f6-8153-5ff9a0d04675 │
7│               6 │ a81309ab-3498-4ba9-9217-8145406a168d │
8└─────────────────┴──────────────────────────────────────┘

system.query_log テーブルには各エントリに query_id が含まれているため、そのテーブルを照会する際にクエリ ID を手動で指定することなく、直前に実行したクエリを確認できるようになりました。

1SELECT query, query_duration_ms FROM system.query_log
2WHERE query_id IN (SELECT query_id FROM system.session_query_ids)
3AND type = 'QueryFinish' 
4ORDER BY event_time_microseconds;

1┌─query─────────────────────────────────────────────────────────────┬─query_duration_ms─┐
2│ SELECT * FROM lake_order_events;                                  │                10 │
3│ system flush logs;                                                │                 0 │
4│ SELECT query, query_duration_ms FROM system.query_log            ↴│                 3 │
5│↳WHERE query_id IN (SELECT query_id FROM system.session_query_ids)↴│                   │
6│↳  AND type = 'QueryFinish' ORDER BY event_time_microseconds;      │                   │
7│ SELECT * FROM system.session_query_ids;                           │                 0 │
8│ set output_format_pretty_row_numbers=0;                           │                 0 │
9│ SELECT * FROM system.session_query_ids;                           │                 0 │
10└───────────────────────────────────────────────────────────────────┴───────────────────┘

テーブルサイズとテーブル数の制限

コントリビューター: Alexey Milovidov

ClickHouse 26.9 では、個々のテーブルが肥大化できる上限サイズや、データベース内に作成できるテーブルの数に制限を設定できるようになりました。

これは、単一のワークロードがすべてのリソースを消費するのを防ぎたいマルチテナント環境、一時的な環境、デモ環境などで役立ちます。

まず、最大 3 行まで格納できるテーブルを作成してみましょう。

1CREATE TABLE limited_events
2(
3    id UInt64,
4    message String
5)
6ENGINE = MergeTree
7ORDER BY id
8SETTINGS max_table_size_rows = 3;

3 行を挿入します。

1INSERT INTO limited_events VALUES
2    (1, 'started'),
3    (2, 'processing'),
4    (3, 'finished');

もう 1 行挿入しても、まだ成功します。

1INSERT INTO limited_events VALUES
2    (4, 'one past limit');
3
4SELECT count()
5FROM limited_events;

1┌─count()─┐
2│       4 │
3└─────────┘

制限のチェックは、INSERT の開始時点におけるテーブルの現在のサイズに対して行われます。つまり、テーブルを 3 行から 4 行に増やす INSERT は完了できます。次の INSERT ではテーブルがすでに上限を超えていることが検出され、拒否されます。

1INSERT INTO limited_events VALUES
2    (5, 'rejected');

1Code: 1016. DB::Exception: Table size limit exceeded: the total number of rows in active data parts of table default.limited_events is 4, which exceeds the 'max_table_size_rows' setting value (3). (TABLE_SIZE_LIMIT_EXCEEDED)

また、max_table_size_bytes_compressed および max_table_size_bytes_uncompressed を使用して、圧縮後または非圧縮時のサイズによってテーブルを制限することもできます。

データベース内のテーブル数にも制限を設定できます。2 つのテーブルを保持できるデータベースを作成してみましょう。

1CREATE DATABASE tenant
2ENGINE = Atomic
3SETTINGS max_tables = 2;

最初の 2 つのテーブルは通常どおり作成できます。

1CREATE TABLE tenant.events (id UInt64)
2ENGINE = MergeTree
3ORDER BY id;
4
5CREATE TABLE tenant.users (id UInt64)
6ENGINE = MergeTree
7ORDER BY id;

しかし、3 つ目のテーブルを作成しようとすると、ClickHouse はそれを拒否します。

1CREATE TABLE tenant.audit_log (id UInt64)
2ENGINE = MergeTree
3ORDER BY id;

1Code: 724. DB::Exception: Too many tables in database `tenant`. The limit (database setting `max_tables`) is set to 2, the current number is 2. (TOO_MANY_TABLES)

外部メモリでの DISTINCT

コントリビューター: Nihal Z. Miaji

概念上、DISTINCT はすでに出現した値を追跡し続ける必要があります。ClickHouse にはこの処理を軽減する複数の最適化が備わっていますが、カーディナリティが高いクエリでは、依然としてメモリ上に大規模なセットを保持しなければならない場合があります。

ClickHouse 26.9 では、クエリがメモリ不足になるまでハッシュセットを拡大させ続ける代わりに、GROUP BY や ORDER BY と同様にこのセットをディスクにスピルできるようになりました。

1 億個の数値のシーケンスからすべての重複しない値を返しつつ、max_memory_usage を使用してクエリのメモリを 150 MB に制限した場合の挙動を見てみましょう。

1SELECT DISTINCT number
2FROM numbers_mt(100_000_000)
3FORMAT `NULL`
4SETTINGS max_memory_usage = 150_000_000

1Received exception:
2Code: 241. DB::Exception: Query memory limit exceeded: would use 244.33 MiB (attempt to allocate chunk of 127.00 MiB), maximum: 143.05 MiB: While executing ExternalDistinctTransform. (MEMORY_LIMIT_EXCEEDED)

メモリが不足しているため、クエリを処理できません。max_bytes_before_external_distinct を設定することで、DISTINCT の中間状態をディスクにスピルさせることができます。

1SELECT DISTINCT number
2FROM numbers_mt(100_000_000)
3FORMAT `NULL`
4SETTINGS
5    max_memory_usage = 150_000_000,
6    max_bytes_before_external_distinct = 25_000_000;

10 rows in set. Elapsed: 1.676 sec. Processed 100.00 million rows, 800.00 MB (59.65 million rows/s., 477.21 MB/s.)
2Peak memory usage: 105.63 MiB.

今回は、ClickHouse は約 25 MB に達した時点で DISTINCT データのテンポラリファイルへの書き出しを開始します。クエリ全体では最大 150 MB を使用できるため、最終的にそれらのファイルを読み取ってマージするのに十分なメモリが残されています。

この機能を使用する際には、もう 1 点留意すべき重要な点があります。ディスクへのスピルによってメモリ使用量は削減されますが、メモリがまったく不要になるわけではありません。バッファ、クエリパイプライン、ディスクにスピルされたテンポラリファイルのマージ処理には、引き続きメモリが必要です。

ディスクへのスピル閾値を 25 MB に維持したまま、クエリ全体の制限を 100 MB に引き下げるとどうなるか見てみましょう。

1SELECT DISTINCT number
2FROM numbers_mt(100_000_000)
3FORMAT `NULL`
4SETTINGS
5    max_memory_usage = 100_000_000,
6    max_bytes_before_external_distinct = 25_000_000;

1Received exception:
2Code: 241. DB::Exception: Query memory limit exceeded: would use 98.94 MiB (attempt to allocate chunk of 4.13 MiB), maximum: 95.37 MiB: While executing BufferingFromFileSource. (MEMORY_LIMIT_EXCEEDED)

データは正常にスピルされましたが、テンポラリファイルを読み戻す際に ClickHouse がメモリ不足に陥りました。BufferingFromFileSource から、エラーが発生したのは元のインメモリセットの構築中ではなく、スピルされたファイルの処理中であることがわかります。

これを解決するには、max_memory_usage を 150 MB に戻す必要があります。

max_bytes_ratio_before_external_distinct が 0.5 に設定されている場合、ClickHouse は外部 DISTINCT を自動的に有効化します。これは、利用可能なメモリの半分に達した時点で DISTINCT がスピルを開始することを意味します。

JSON サブカラムのブラケット構文

コントリビューター: Pavel Kruglov

ClickHouse 26.9 では、JSON 値内のパスにアクセスするためのブラケット(大括弧)構文が追加されました。これにより、ネストされたパスの記述が容易になり、ドットやスペースなどの文字を含むキーを扱いやすくなります。

インメモリの例を使って、どのように機能するか見てみましょう。

1WITH '{
2    "user": {"name": "Alex"},
3    "release.version": "26.9",
4    "first name": "Alexey",
5    "tags": ["database", "analytics"]
6}'::JSON AS json
7SELECT
8    json.user.name AS dot_notation,
9    json['user']['name'] AS bracket_notation,
10    json['release.version'] AS release_version,
11    json['first name'] AS first_name;

1┌─dot_notation─┬─bracket_notation─┬─release_version─┬─first_name─┐
2│ Alex         │ Alex             │ 26.9            │ Alexey     │
3└──────────────┴──────────────────┴─────────────────┴────────────┘

今すぐ始める

自社データで ClickHouse を試してみませんか？ ClickHouse Cloud をわずか数分で利用開始でき、300 ドル分の無料クレジットを獲得できます。

サインアップ

ClickHouse リリース 26.9

新しいコントリビューター

DateTime と Time の算術演算

コントリビューター: Yarik Briukhovetskyi

PromQL のプライベートプレビュー

コントリビューター: Vitaly Baranov、Nikita Mikhaylov、Valery Petrov、Minh Vu

CREATE TOKEN

コントリビューター: Alexey Milovidov

境界条件付き LIMIT

コントリビューター: Zakhar Kravchuk、Nihal Miaji

インクリメンタル・リフレッシャブルマテリアライズドビュー

コントリビューター: Smita Kulkarni

カラム統計からの min、max、count

コントリビューター: Alexey Milovidov

`system.session_query_ids`

コントリビューター: Vladimir Cherkasov

テーブルサイズとテーブル数の制限

コントリビューター: Alexey Milovidov

外部メモリでの DISTINCT

コントリビューター: Nihal Z. Miaji

JSON サブカラムのブラケット構文

コントリビューター: Pavel Kruglov

今すぐ始める

Subscribe to our newsletter

最近の記事

FountainがClickHouse Cloud上でデータプレーンを再構築し、現場向け超知能「Cue」を強化した方法

NVMe 上の Postgres: 性能、そしてトランザクションとアナリティクスの統合

Apache Airflow 向けの公式 ClickHouse プロバイダーが利用可能に

ClickStackの新機能 - 2026年8月

Follow us

ClickHouse リリース 26.9

新しいコントリビューター #

DateTime と Time の算術演算 #

コントリビューター: Yarik Briukhovetskyi #

PromQL のプライベートプレビュー #

コントリビューター: Vitaly Baranov、Nikita Mikhaylov、Valery Petrov、Minh Vu #

CREATE TOKEN #

コントリビューター: Alexey Milovidov #

境界条件付き LIMIT #

コントリビューター: Zakhar Kravchuk、Nihal Miaji #

インクリメンタル・リフレッシャブルマテリアライズドビュー #

コントリビューター: Smita Kulkarni #

カラム統計からの min、max、count #

コントリビューター: Alexey Milovidov #

system.session_query_ids #

コントリビューター: Vladimir Cherkasov #

テーブルサイズとテーブル数の制限 #

コントリビューター: Alexey Milovidov #

外部メモリでの DISTINCT #

コントリビューター: Nihal Z. Miaji #

JSON サブカラムのブラケット構文 #

コントリビューター: Pavel Kruglov #

今すぐ始める

Subscribe to our newsletter

最近の記事

FountainがClickHouse Cloud上でデータプレーンを再構築し、現場向け超知能「Cue」を強化した方法

NVMe 上の Postgres: 性能、そしてトランザクションとアナリティクスの統合

Apache Airflow 向けの公式 ClickHouse プロバイダーが利用可能に

ClickStackの新機能 - 2026年8月

Follow us

新しいコントリビューター

DateTime と Time の算術演算

コントリビューター: Yarik Briukhovetskyi

PromQL のプライベートプレビュー

コントリビューター: Vitaly Baranov、Nikita Mikhaylov、Valery Petrov、Minh Vu

CREATE TOKEN

コントリビューター: Alexey Milovidov

境界条件付き LIMIT

コントリビューター: Zakhar Kravchuk、Nihal Miaji

インクリメンタル・リフレッシャブルマテリアライズドビュー

コントリビューター: Smita Kulkarni

カラム統計からの min、max、count

コントリビューター: Alexey Milovidov

`system.session_query_ids`

コントリビューター: Vladimir Cherkasov

テーブルサイズとテーブル数の制限

コントリビューター: Alexey Milovidov

外部メモリでの DISTINCT

コントリビューター: Nihal Z. Miaji

JSON サブカラムのブラケット構文

コントリビューター: Pavel Kruglov