ClickHouse リリース 26.5

また 1 か月が経ち、新しいリリースの時期がやってきました。

ClickHouse 26.5 リリースには、38 個の新機能 🌹、51 件のパフォーマンス最適化 🦋、224 件のバグ修正 🐞 が含まれています。

今回のリリースでは記録的な数のパフォーマンス最適化が行われました。注目すべき機能として、JOIN を経由する ORDER BY … LIMIT のプッシュダウン (最大 20 倍高速化)、不要なグループの構築を回避する新しい GROUP BY … LIMIT ショートカット、ローカルファイルシステムに対して SQL を直接実行できる新しい filesystem テーブル関数などが追加されています。

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

26.5 のすべての新しいコントリビューターを心より歓迎します。ClickHouse コミュニティの成長にはいつも身が引き締まる思いであり、ClickHouse をこれほど支持される存在にしてくれた皆さんの貢献に深く感謝しています。

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

Abhinav Agarwal, Ahaan, Alex Kuleshov, Ashrith Bandla, Asish Kumar, Callum C, Felix Bernhard, Flavio Malavazi, Ian Rakhmatullin, Ilya Perstenev, JackFielding, Joe Redfern, Larry Snizek, Luc Leray, Rahul Nair, Roy Sindre Norangshol, Venkata Vineel, Vincent Voyer, Yue, Yue Ni, functioncrafter, ibrahim karimeddin, mohaidoss, perst20, peter15914, sayondeep, zhangzhibiao, zxuhan7

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

プレゼンテーションのスライドもご覧いただけます。

JOIN を経由する ORDER BY … LIMIT のプッシュダウン

貢献者: Alexey Milovidov

「ClickHouse はすべてのバージョンで最適化されており、さらに最適化を進めています。最適化に終わりはありません」 – Alexey Milovidov (ClickHouse リリース 26.5 ウェビナーにて)

より多くの処理を JOIN の前へ移動

最近のリリースにおいて、ClickHouse は JOIN を通過するデータ量を減らすため、より多くの処理を着実に JOIN の前へ移動させてきました。たとえば、ClickHouse はすでに JOIN クエリ内の複雑な OR 条件をプッシュダウンして JOIN が発生する前により早い段階で各テーブルをフィルタリングします。また、JOIN の右側から作成され、JOIN が実行される前に左側に適用されるランタイムフィルターもサポートしています。

今回のリリースはそのテーマを引き継ぎつつ、異なる種類の処理をプッシュダウンします。WHERE 述語ではなく、分析ワークロードで頻繁に現れるパターンである ORDER BY … LIMIT 句です。

「結合してから制限」から「制限してから結合」へ

LEFT JOIN クエリの最も外側の SELECT が ORDER BY … LIMIT で終わり、かつソートキーが左側テーブルのカラムのみに依存している場合、ClickHouse はその ORDER BY … LIMIT を JOIN の下へプッシュできます。

同じことが、ソートキーが右側テーブルのカラムのみに依存している場合の RIGHT JOIN クエリにも適用されます。

たとえば、TPC-H テーブルに対して実行される次のクエリは、顧客情報が付加された直近 100 件の注文を要求します。

1SELECT
2    o_orderkey,
3    o_orderdate,
4    o_totalprice,
5    c_name,
6    c_mktsegment
7FROM orders
8LEFT JOIN customer ON o_custkey = c_custkey
9ORDER BY
10    o_orderdate DESC,
11    o_orderkey DESC
12LIMIT 100;

ここで ORDER BY は、LEFT JOIN で保持される側の orders のカラムのみを使用しています。つまり、ClickHouse は制限を適用する前に、すべての注文を顧客と結合する必要がありません。

最適化がない場合、プランはコストの高い結合を先に実行せざるを得ません。

Blog-release-26.05.001.png

新しい最適化により、ClickHouse は処理の順序を逆にできます。まず orders から上位 100 行を特定し、そのわずかな行のみを customer と結合します。

Blog-release-26.05.002.png

この変化は、EXPLAIN で取得したクエリプランでも確認できます。最適化を有効にすると、customer テーブルとの結合の前に、orders テーブル側で Limit と Sorting のステップがプランに含まれます。

1Join
2
3  ...
4
5    Limit
6
7      Sorting
8
9        ReadFromMergeTree (sf100.orders)
10
11  ...
12
13ReadFromMergeTree (sf100.customer)

嬉しい副次効果として、ClickHouse はプッシュダウンされた ORDER BY … LIMIT の部分をすでにファーストクラスのクエリパターンとして扱います。Top-N 最適化に関する解説記事で取り上げたように、ClickHouse はこのパターンのためのエンジンレベルの最適化をいくつも蓄積してきました。

この最適化は、デフォルトで有効になっている新しい query_plan_top_k_through_join 設定によって制御されます。

ベンチマーク: 20 倍高速化、メモリ消費量は 175 分の 1

その効果を評価するため、32 vCPU と 128 GiB の RAM を備えた AWS EC2 m6i.8xlarge インスタンス上でスケールファクター 100 の TPC-H スキーマを作成してロードしました。

まず、query_plan_top_k_through_join = 0 を設定して新しい ORDER BY … LIMIT プッシュダウンを無効にした状態でクエリを実行しました。クエリを 3 回実行し、最も速かった実行をベースラインとして使用しました。

1Elapsed: 2.153 sec. Processed 165.00 million rows, 3.23 GB (76.65 million rows/s., 1.50 GB/s.)
2Peak memory usage: 1.87 GiB.
3
4Elapsed: 1.878 sec. Processed 165.00 million rows, 3.23 GB (87.87 million rows/s., 1.72 GB/s.)
5Peak memory usage: 1.88 GiB.
6
7Elapsed: 2.197 sec. Processed 165.00 million rows, 3.23 GB (75.10 million rows/s., 1.47 GB/s.)
8Peak memory usage: 1.87 GiB.

次に、query_plan_top_k_through_join = 1 を設定して最適化を有効にし、同じクエリを実行しました。

1Elapsed: 0.093 sec. Processed 165.22 million rows, 2.18 GB (1.78 billion rows/s., 23.45 GB/s.)
2Peak memory usage: 11.46 MiB.
3
4Elapsed: 0.092 sec. Processed 165.22 million rows, 2.18 GB (1.80 billion rows/s., 23.70 GB/s.)
5Peak memory usage: 13.72 MiB.
6
7
8Elapsed: 0.092 sec. Processed 165.22 million rows, 2.18 GB (1.79 billion rows/s., 23.53 GB/s.)
9Peak memory usage: 10.98 MiB.

各設定の最速の実行結果を比較すると、その差は歴然です。

設定	最速実行時間	ピークメモリ	読み取りデータ量
プッシュダウン無効	1.878 秒	1.88 GiB	3.23 GB
プッシュダウン有効	0.092 秒	10.98 MiB	2.18 GB
改善度	20.4 倍高速	メモリ約 175 分の 1	読み取りデータ量 1.5 分の 1

このベンチマークではすでに、実行時間が 20.4 倍改善し、ピークメモリ使用量が約 175 分の 1 に削減されています。

これらの数値は固定の上限ではありません。得られる恩恵は、入力テーブルのサイズ、結合される行の幅、選択されたカラム、および LIMIT 値によって左右されます。

ORDER BY なしの GROUP BY … LIMIT

貢献者: Amos Bird

Top-N 最適化を GROUP BY に拡張

ClickHouse はすでに Top-N クエリをファーストクラスのクエリパターンとして扱っています。Top-N 最適化に関する解説記事で取り上げたように、ClickHouse はストリーミング実行、インオーダー読み取り、遅延読み取り、データスキッピングに基づく Top-N プルーニングなど、ORDER BY … LIMIT を伴うクエリ向けのエンジンレベルの最適化をいくつも蓄積してきました。

今回のリリースでは、同じアイデアを別の形状、すなわち ORDER BY のない GROUP BY … LIMIT クエリにまで拡張しています。

キーでグループ化してから LIMIT を適用するものの、ORDER BY も HAVING 句もウィンドウ関数も持たないクエリを考えてみてください。この場合、クエリは最小のキー、最大のキー、最も頻出するキー、あるいは特定の順序のキーを求めているわけではありません。単に重複しない任意の N 個のグルーピングキーを求めているだけです。

たとえば、前のセクションのベンチマーク用に TPC-H データセットをすでにロードしているため、ここでも再利用できます。次のクエリは、lineitem テーブルから重複しない任意の 100 個の注文キーを要求します。

1SELECT l_orderkey
2FROM lineitem
3GROUP BY l_orderkey
4LIMIT 100;

「すべてをグループ化してから制限」から「N グループのみを保持」へ

TPC-H スケールファクター 100 では、lineitem には 6 億行と、1 億 5,000 万個の異なる l_orderkey の値が含まれています。

新しい最適化がない場合、ClickHouse はこのクエリを通常の GROUP BY として扱います。入力をスキャンする際、新しい l_orderkey が現れるたびに集約ハッシュテーブルに新しいエントリが作成されます。集約結果が構築された後に初めて、LIMIT 100 によって出力が 100 行に削減されます。

Blog-release-26.05.003.png

今回のリリースにより、ClickHouse はこの特別なパターンを認識し、結果に影響を与えないグループの構築を回避します。この最適化は、デフォルトで有効になっている新しい optimize_trivial_group_by_limit_query 設定によって制御されます。

対象となるクエリに対して、ClickHouse は内部的に集約制限を LIMIT + OFFSET に設定し、group_by_overflow_mode = 'any' を使用します。実際には、集約ハッシュテーブルに最初の 100 個の重複しない l_orderkey 値が含まれると、新しいキーは新しいグループとして追加される代わりに無視されます。

Blog-release-26.05.004.png

スキャン自体は入力を処理し続けますが、メインメモリ内の集約状態は極めて小さなまま保たれます。1 億 5,000 万個に向かって肥大化することなく、100 グループにとどまります。

ベンチマーク: 11.9 倍高速化、メモリ消費量は 185 分の 1

その効果を評価するため、32 vCPU と 128 GiB の RAM を備えた AWS EC2 m6i.8xlarge インスタンス上でクエリを再度実行しました。まず、optimize_trivial_group_by_limit_query = 0 を設定して最適化を無効にし、3 回の実行のうち最も速かったものをベースラインとして使用しました。

1Elapsed: 0.853 sec. Processed 600.04 million rows, 2.40 GB (703.29 million rows/s., 2.81 GB/s.)
2Peak memory usage: 8.60 GiB.
3
4Elapsed: 0.806 sec. Processed 600.04 million rows, 2.40 GB (744.07 million rows/s., 2.98 GB/s.)
5Peak memory usage: 8.58 GiB.
6
7Elapsed: 0.809 sec. Processed 600.04 million rows, 2.40 GB (742.06 million rows/s., 2.97 GB/s.)
8Peak memory usage: 8.57 GiB.

次に、optimize_trivial_group_by_limit_query = 1 を設定して最適化を有効にし、同じクエリを実行しました。

1Elapsed: 0.069 sec. Processed 600.04 million rows, 2.40 GB (8.76 billion rows/s., 35.03 GB/s.)
2Peak memory usage: 47.54 MiB.
3
4Elapsed: 0.070 sec. Processed 600.04 million rows, 2.40 GB (8.54 billion rows/s., 34.16 GB/s.)
5Peak memory usage: 47.54 MiB.
6
7Elapsed: 0.068 sec. Processed 600.04 million rows, 2.40 GB (8.79 billion rows/s., 35.17 GB/s.)
8Peak memory usage: 47.55 MiB.

各設定の最速の実行結果は次のとおりです。

設定	最速実行時間	処理行数	読み取りデータ量	ピークメモリ
最適化無効	0.806 秒	6 億 4 万行	2.40 GB	8.58 GiB
最適化有効	0.068 秒	6 億 4 万行	2.40 GB	47.55 MiB
改善度	11.9 倍高速	同等	同等	メモリ約 185 分の 1

最適化されたクエリは 11.9 倍高速 であり、ピークメモリ使用量は 約 185 分の 1 に抑えられています。

filesystem テーブル関数

貢献者: Ilya Perstenev, Ilya Yatsishin, Alexey Milovidov

ClickHouse 25.6 では filesystem テーブル関数も導入され、ディレクトリをクエリ可能なテーブルとして一覧表示および分析できるようになりました。

filesystem によって公開される完全なスキーマは、ファイルシステムの内省に期待される項目を網羅しています。

1DESCRIBE filesystem();

1┌─name──────────────┬─type───────────────────────────────────────────────┐
2│ path              │ String                                             │
3│ name              │ String                                             │
4│ type              │ Enum8('none' = 0, 'not_found' = 1, 'regular' = 2, ⋯│
5│ size              │ Nullable(UInt64)                                   │
6│ depth             │ UInt16                                             │
7│ modification_time │ Nullable(DateTime64(6))                            │
8│ is_symlink        │ Bool                                               │
9│ content           │ Nullable(String)                                   │
10│ owner_read        │ Bool                                               │
11│ owner_write       │ Bool                                               │
12│ owner_exec        │ Bool                                               │
13│ group_read        │ Bool                                               │
14│ group_write       │ Bool                                               │
15│ group_exec        │ Bool                                               │
16│ others_read       │ Bool                                               │
17│ others_write      │ Bool                                               │
18│ others_exec       │ Bool                                               │
19│ set_gid           │ Bool                                               │
20│ set_uid           │ Bool                                               │
21│ sticky_bit        │ Bool                                               │
22│ file              │ String                                             │
23└───────────────────┴────────────────────────────────────────────────────┘

clickhouse-local を使用して引数なしで呼び出すと、カレントディレクトリ内のファイルが一覧表示されます。

1SELECT path, name FROM filesystem();

1┌─path──────────────────────────────────────────────┬─name──────────────────────┐
2│ /Users/markhneedham/projects/release-posts/26.5   │ clickhouse                │
3│ /Users/markhneedham/projects/release-posts/26.5   │ .claude                   │
4└───────────────────────────────────────────────────┴───────────────────────────┘

この関数は、ClickHouse を起動したユーザーと同じファイルシステム領域へのアクセス権を持ちます。ClickHouse Server 経由で呼び出すと、user_files ディレクトリ内のファイルが一覧表示されます。

私のマシンには大きな動画ファイルがたくさんあり、それらを見つけるために普段は私 (というか Claude!) が大量の Unix コマンドを実行しなければなりませんでした。この新しい関数を使えば、以下のようなシンプルなクエリで済みます。

1SELECT path, name, formatReadableSize(size), modification_time
2FROM filesystem('/Users/markhneedham/projects/videos')
3WHERE type = 'regular' AND name LIKE '%.braw'
4ORDER BY size DESC
5LIMIT 3
6FORMAT Vertical;

1Row 1:
2──────
3path:                     /Users/markhneedham/projects/videos/20260212-Sample
4name:                     A001_10150625_C183 2.braw
5formatReadableSize(size): 26.75 GiB
6modification_time:        2025-10-15 06:25:08.529999
7
8Row 2:
9──────
10path:                     /Users/markhneedham/projects/videos/20260217-AsyncInserts
11name:                     A001_09290151_C176.braw
12formatReadableSize(size): 21.70 GiB
13modification_time:        2025-09-29 01:51:47.820000
14
15Row 3:
16──────
17path:                     /Users/markhneedham/projects/videos/20260123-PGCHStack
18name:                     A001_08021314_C119.braw
19formatReadableSize(size): 21.54 GiB
20modification_time:        2025-08-02 13:14:33.260000

そして、容量を空けるために削除すべきファイルをより素早く見つけられるよう、このクエリを Claude が使用できるスキルとしてまとめました。

url テーブル関数向けの url_base

貢献者: Alexey Milovidov

url テーブル関数を頻繁に使っている方なら、同じベース URL を何度も入力した経験があるはずです。新しい url_base 設定を使用すると、一度設定するだけで、以降はすべて相対パスを使用できるようになります。

Amazon カスタマーレビューデータセットを使用する場合、ベース URL を次のように設定できます。

1SET url_base = 'https://datasets-documentation.s3.eu-west-3.amazonaws.com/amazon_reviews/';

これで、2014 年のレビューを次のようにクエリできます。

1SELECT
2    count(),
3    round(avg(star_rating), 2) AS stars,
4    round(avg(helpful_votes), 2) AS votes
5FROM url('amazon_reviews_2014.snappy.parquet')

1┌──count()─┬─stars─┬─votes─┐
2│ 44127569 │  4.23 │  0.96 │
3└──────────┴───────┴───────┘

また、2015 年のデータをクエリしたい場合も同様です。

1SELECT
2    count(),
3    round(avg(star_rating), 2) AS stars,
4    round(avg(helpful_votes), 2) AS votes
5FROM url('amazon_reviews_2015.snappy.parquet')

1┌──count()─┬─stars─┬─votes─┐
2│ 41905631 │  4.25 │  0.74 │
3└──────────┴───────┴───────┘

負の LIMIT BY

貢献者: Nihal Z. Miaji

26.5 リリースでは負の LIMIT BY も追加され、各グループの先頭からではなく末尾から行を取得できるようになりました。

動作を確認するために、お気に入りの英国不動産価格データセットを使用します。まず、Yorkshire という文字列を含むすべてのカウンティについて、地区ごとの価格の中央値を求める次のクエリから始めます。

1SELECT county, district, median(price)
2FROM uk_price_paid
3WHERE county ILIKE '%Yorkshire%'
4GROUP BY ALL
5ORDER BY median(price) DESC;

1┌─county───────────────────┬─district─────────────────┬─median(price)─┐
2│ NORTH YORKSHIRE          │ NORTH YORKSHIRE          │        263000 │
3│ NORTH YORKSHIRE          │ HARROGATE                │        185000 │
4│ NORTH YORKSHIRE          │ HAMBLETON                │        170000 │
5│ NORTH YORKSHIRE          │ RYEDALE                  │        160000 │
6│ NORTH YORKSHIRE          │ RICHMONDSHIRE            │        150000 │
7│ NORTH YORKSHIRE          │ CRAVEN                   │        149250 │
8│ NORTH YORKSHIRE          │ SELBY                    │        144995 │
9│ EAST RIDING OF YORKSHIRE │ EAST RIDING OF YORKSHIRE │        132000 │
10│ WEST YORKSHIRE           │ LEEDS                    │        129997 │
11│ NORTH YORKSHIRE          │ SCARBOROUGH              │        120000 │
12│ SOUTH YORKSHIRE          │ SHEFFIELD                │        115000 │
13│ WEST YORKSHIRE           │ KIRKLEES                 │        114950 │
14│ WEST YORKSHIRE           │ WAKEFIELD                │      112997.5 │
15│ SOUTH YORKSHIRE          │ ROTHERHAM                │        102500 │
16│ WEST YORKSHIRE           │ CALDERDALE               │        101000 │
17│ WEST YORKSHIRE           │ BRADFORD                 │        100000 │
18│ SOUTH YORKSHIRE          │ DONCASTER                │         98500 │
19│ SOUTH YORKSHIRE          │ BARNSLEY                 │         95000 │
20│ WEST YORKSHIRE           │ EAST YORKSHIRE           │         94950 │
21└──────────────────────────┴──────────────────────────┴───────────────┘

これまでも、カウンティのグループごとに最初の 2 行、つまり各カウンティ内で価格の中央値が最も高い上位 2 地区を選択できました。

1SELECT county, district, median(price)
2FROM uk_price_paid
3WHERE county ILIKE '%Yorkshire%'
4GROUP BY ALL
5ORDER BY median(price) DESC
6LIMIT 2 BY county

1┌─county───────────────────┬─district─────────────────┬─median(price)─┐
2│ NORTH YORKSHIRE          │ NORTH YORKSHIRE          │        262000 │
3│ NORTH YORKSHIRE          │ HARROGATE                │        185000 │
4│ EAST RIDING OF YORKSHIRE │ EAST RIDING OF YORKSHIRE │      130972.5 │
5│ WEST YORKSHIRE           │ LEEDS                    │        130000 │
6│ WEST YORKSHIRE           │ KIRKLEES                 │        115000 │
7│ SOUTH YORKSHIRE          │ SHEFFIELD                │        115000 │
8│ SOUTH YORKSHIRE          │ ROTHERHAM                │        105000 │
9└──────────────────────────┴──────────────────────────┴───────────────┘

しかし、負の LIMIT BY を使うことで、カウンティのグループごとに最後の 2 行、すなわち各カウンティ内で価格の中央値が最も低い 2 地区を選択することも可能になりました。

1SELECT county, district, median(price)
2FROM uk_price_paid
3WHERE county ILIKE '%Yorkshire%'
4GROUP BY ALL
5ORDER BY median(price) DESC
6LIMIT -2 BY county;

1┌─county───────────────────┬─district─────────────────┬─median(price)─┐
2│ NORTH YORKSHIRE          │ SELBY                    │        145000 │
3│ EAST RIDING OF YORKSHIRE │ EAST RIDING OF YORKSHIRE │        132500 │
4│ NORTH YORKSHIRE          │ SCARBOROUGH              │        122000 │
5│ SOUTH YORKSHIRE          │ DONCASTER                │         99000 │
6│ WEST YORKSHIRE           │ BRADFORD                 │         97500 │
7│ SOUTH YORKSHIRE          │ BARNSLEY                 │         94950 │
8│ WEST YORKSHIRE           │ EAST YORKSHIRE           │         94950 │
9└──────────────────────────┴──────────────────────────┴───────────────┘

マルチパス SQL/JSON

貢献者: Kevinyhzou, Alexey Milovidov

JSON_VALUE および JSON_QUERY 関数を使用する際、パスのタプルまたは配列を渡して文字列のタプルまたは配列を受け取れるようになり、JSON のパースが 1 回だけで済むようになりました。

新しい prettyPrintJSON 関数で出力した、Open House カンファレンスを表す JSON 文字列を使って試してみましょう。

1WITH '{
2  "name": "Open House 2026",
3  "tagline": "The real-time database for AI conference",
4  "dates": {
5    "workshops": "2026-05-26",
6    "conference": ["2026-05-27", "2026-05-28"]
7  },
8  "venue": {
9    "name": "Convene 100 Stockton",
10    "address": "40 O''Farrell St, San Francisco, CA 94108"
11  }
12}' AS conf
13SELECT prettyPrintJSON(conf)
14FORMAT Raw;

1{
2    "name": "Open House 2026",
3    "tagline": "The real-time database for AI conference",
4    "dates": {
5        "workshops": "2026-05-26",
6        "conference": [
7            "2026-05-27",
8            "2026-05-28"
9        ]
10    },
11    "venue": {
12        "name": "Convene 100 Stockton",
13        "address": "40 O'Farrell St, San Francisco, CA 94108"
14    }
15}
16
171 row in set. Elapsed: 0.003 sec.

文字列を返す場合、たとえば名前と会場を含むタプルを返したいときは、JSON_VALUE 関数を使用します。

1WITH '{
2  "name": "Open House 2026",
3  "tagline": "The real-time database for AI conference",
4  "dates": {
5    "workshops": "2026-05-26",
6    "conference": ["2026-05-27", "2026-05-28"]
7  },
8  "venue": {
9    "name": "Convene 100 Stockton",
10    "address": "40 O''Farrell St, San Francisco, CA 94108"
11  }
12}' AS conf
13SELECT JSON_VALUE(conf, ('$.name', '$.venue.name'));

1┌─JSON_VALUE(conf, ('$.name', '$.venue.name'))─┐
2│ ('Open House 2026','Convene 100 Stockton')   │
3└──────────────────────────────────────────────┘

JSON パスは、タプルではなく配列として渡すこともできます。

1WITH '{
2  "name": "Open House 2026",
3  "tagline": "The real-time database for AI conference",
4  "dates": {
5    "workshops": "2026-05-26",
6    "conference": ["2026-05-27", "2026-05-28"]
7  },
8  "venue": {
9    "name": "Convene 100 Stockton",
10    "address": "40 O''Farrell St, San Francisco, CA 94108"
11  }
12}' AS conf
13SELECT JSON_VALUE(conf, ['$.name', '$.venue.name']);

1┌─JSON_VALUE(conf, ['$.name', '$.venue.name'])─┐
2│ ['Open House 2026','Convene 100 Stockton']   │
3└──────────────────────────────────────────────┘

ただし、dates.conference は配列であるため、JSON_VALUE を使って取得しようとすると空文字列が返されます。

1WITH '{
2  "name": "Open House 2026",
3  "tagline": "The real-time database for AI conference",
4  "dates": {
5    "workshops": "2026-05-26",
6    "conference": ["2026-05-27", "2026-05-28"]
7  },
8  "venue": {
9    "name": "Convene 100 Stockton",
10    "address": "40 O''Farrell St, San Francisco, CA 94108"
11  }
12}' AS conf
13SELECT JSON_VALUE(conf, ('$.name', '$.dates.conference'));

1┌─JSON_VALUE(c⋯nference'))─┐
2│ ('Open House 2026','')   │
3└──────────────────────────┘

0 始まりの配列インデックスを使用すれば、その配列から個々の値を読み取ることができます。

1WITH '{
2  "name": "Open House 2026",
3  "tagline": "The real-time database for AI conference",
4  "dates": {
5    "workshops": "2026-05-26",
6    "conference": ["2026-05-27", "2026-05-28"]
7  },
8  "venue": {
9    "name": "Convene 100 Stockton",
10    "address": "40 O''Farrell St, San Francisco, CA 94108"
11  }
12}' AS conf
13SELECT JSON_VALUE(conf, ('$.dates.conference[0]', '$.dates.conference[1]'));

1┌─JSON_VALUE(co⋯ference[1]'))─┐
2│ ('2026-05-27','2026-05-28') │
3└─────────────────────────────┘

あるいは、日程を配列として、会場全体をオブジェクトとして返したい場合は、代わりに JSON_QUERY を使用する必要があります。

1WITH '{
2  "name": "Open House 2026",
3  "tagline": "The real-time database for AI conference",
4  "dates": {
5    "workshops": "2026-05-26",
6    "conference": ["2026-05-27", "2026-05-28"]
7  },
8  "venue": {
9    "name": "Convene 100 Stockton",
10    "address": "40 O''Farrell St, San Francisco, CA 94108"
11  }
12}' AS conf
13SELECT JSON_QUERY(conf, ('$.dates.conference', '$.venue'))
14FORMAT Raw;

読みやすくフォーマットした出力を以下に示します。

1(
2  '[["2026-05-27","2026-05-28"]]',
3  '[{"name":"Convene 100 Stockton","address":"40 O\'Farrell St, San Francisco, CA 94108"}]'
4)

JSON_QUERY は常に結果を [] で囲むため、配列の値は二重にラップされる点に注意してください。

Web ターミナル

貢献者: Alexey Milovidov

26.5 リリースでは、ブラウザ内で動作する実験的な clickhouse-client も導入されました。設定ファイルに以下を追加することで有効にできます。

config.d/webterminal.yaml

1allow_experimental_webterminal: true

その後、http://localhost:8123/webterminal にアクセスすると、次のような画面が表示されます。

Screenshot 2026-06-01 at 11.06.21.png

サブクエリのクエリキャッシュ

貢献者: Nikita Barannik, Vincent Voyer

サブクエリ単位でクエリキャッシュを制御できるようになりました。

これまでも、最も外側のクエリに対しては use_query_cache 設定を使用して次のようにクエリキャッシュを有効にできました。

1SELECT * FROM (SELECT * FROM table) 
2SETTINGS use_query_cache = 1;

サブクエリに対してクエリキャッシュを有効にしたい場合、26.5 からはその設定をサブクエリの末尾に付加できます。

1SELECT * 
2FROM (
3  SELECT * 
4  FROM table 
5  SETTINGS use_query_cache = 1
6);

また、use_query_cache_for_subqueries 設定を使用して、すべてのサブクエリへのクエリキャッシュの伝播を有効にすることもできます。

1SELECT * FROM (SELECT * FROM table)
2SETTINGS use_query_cache_for_subqueries = 1;

あるいは、すべてのサブクエリへのクエリキャッシュの伝播を有効にしつつ、そのうちの 1 つだけ無効にすることも可能です。

1SELECT * 
2FROM (SELECT * FROM table1) t1
3NATURAL JOIN (SELECT * FROM table2 SETTINGS use_query_cache = 0) t2
4SETTINGS use_query_cache_for_subqueries = 1;

今すぐ始める

自社データでの ClickHouse の動作をお試しになりませんか? ClickHouse Cloud ならわずか数分で開始でき、$300 分の無料クレジットも獲得できます。

サインアップ

ClickHouse リリース 26.5

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

JOIN を経由する ORDER BY … LIMIT のプッシュダウン

貢献者: Alexey Milovidov

より多くの処理を JOIN の前へ移動

「結合してから制限」から「制限してから結合」へ

ベンチマーク: 20 倍高速化、メモリ消費量は 175 分の 1

ORDER BY なしの GROUP BY … LIMIT

貢献者: Amos Bird

Top-N 最適化を GROUP BY に拡張

「すべてをグループ化してから制限」から「N グループのみを保持」へ

ベンチマーク: 11.9 倍高速化、メモリ消費量は 185 分の 1

filesystem テーブル関数

貢献者: Ilya Perstenev, Ilya Yatsishin, Alexey Milovidov

url テーブル関数向けの url_base

貢献者: Alexey Milovidov

負の LIMIT BY

貢献者: Nihal Z. Miaji

マルチパス SQL/JSON

貢献者: Kevinyhzou, Alexey Milovidov

Web ターミナル

貢献者: Alexey Milovidov

サブクエリのクエリキャッシュ

貢献者: Nikita Barannik, Vincent Voyer

今すぐ始める

Subscribe to our newsletter

最近の記事

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

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

ClickHouse が dbt プラットフォームで利用可能になりました

Replica-aware routing のパブリックベータ

Follow us

ClickHouse リリース 26.5

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

JOIN を経由する ORDER BY … LIMIT のプッシュダウン #

貢献者: Alexey Milovidov #

より多くの処理を JOIN の前へ移動 #

「結合してから制限」から「制限してから結合」へ #

ベンチマーク: 20 倍高速化、メモリ消費量は 175 分の 1 #

ORDER BY なしの GROUP BY … LIMIT #

貢献者: Amos Bird #

Top-N 最適化を GROUP BY に拡張 #

「すべてをグループ化してから制限」から「N グループのみを保持」へ #

ベンチマーク: 11.9 倍高速化、メモリ消費量は 185 分の 1 #

filesystem テーブル関数 #

貢献者: Ilya Perstenev, Ilya Yatsishin, Alexey Milovidov #

url テーブル関数向けの url_base #

貢献者: Alexey Milovidov #

負の LIMIT BY #

貢献者: Nihal Z. Miaji #

マルチパス SQL/JSON #

貢献者: Kevinyhzou, Alexey Milovidov #

Web ターミナル #

貢献者: Alexey Milovidov #

サブクエリのクエリキャッシュ #

貢献者: Nikita Barannik, Vincent Voyer #

今すぐ始める

Subscribe to our newsletter

最近の記事

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

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

ClickHouse が dbt プラットフォームで利用可能になりました

Replica-aware routing のパブリックベータ

Follow us

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

JOIN を経由する ORDER BY … LIMIT のプッシュダウン

貢献者: Alexey Milovidov

より多くの処理を JOIN の前へ移動

「結合してから制限」から「制限してから結合」へ

ベンチマーク: 20 倍高速化、メモリ消費量は 175 分の 1

ORDER BY なしの GROUP BY … LIMIT

貢献者: Amos Bird

Top-N 最適化を GROUP BY に拡張

「すべてをグループ化してから制限」から「N グループのみを保持」へ

ベンチマーク: 11.9 倍高速化、メモリ消費量は 185 分の 1

filesystem テーブル関数

貢献者: Ilya Perstenev, Ilya Yatsishin, Alexey Milovidov

url テーブル関数向けの url_base

貢献者: Alexey Milovidov

負の LIMIT BY

貢献者: Nihal Z. Miaji

マルチパス SQL/JSON

貢献者: Kevinyhzou, Alexey Milovidov

Web ターミナル

貢献者: Alexey Milovidov

サブクエリのクエリキャッシュ

貢献者: Nikita Barannik, Vincent Voyer