ClickHouseがさらに怠け者になり、さらに高速に - 遅延ロード最適化を導入

(clickhouse.com)

6 ポイント投稿者 GN⁺ 2025-04-24 | 2件のコメント | WhatsAppで共有

ClickHouse が新しい最適化手法である lazy materialization を導入し、Top N クエリの性能を 最大1,500倍 まで向上
必要なときにだけカラムデータを読む戦略 によってディスクI/Oを最小化
既存の カラムストレージ、インデックス、PREWHERE 手法とともに階層的なI/O最適化スタックを構成
クエリ実行計画に応じてカラムデータを遅延ロード し、とくに LIMIT句のあるクエリ で大きな効果を発揮
デフォルト設定で有効化 されているため、コード変更なしで性能向上を得られる

ClickHouseの遅延最適化戦略: Lazy Materialization

中核となる概念

ClickHouse は 不要なデータを読まないことで性能を最大化 する
lazy materialization は、クエリ実行中に実際に 必要な時点でのみカラムデータをロード する方式
既存のI/O最適化手法と 独立して動作しつつ、相互補完的な性能向上 を提供する

既存のI/O最適化技術

カラム指向ストレージ: 必要なカラムだけを読む
Sparse Index / Skipping Index / Projections: フィルタ条件に一致するgranuleだけを読む
PREWHERE: 非インデックスカラム を早期フィルタリング
Query Condition Cache: 繰り返しクエリの結果をキャッシュし、同じgranuleの再処理を回避

Lazy Materializationの仕組み

既存技術が フィルタリングによるI/O削減 に集中していたのに対し、lazy materialization は 演算時点まで読み取りを遅らせる
クエリの次のステップで必要なカラムだけを直ちに読み、残りはLIMIT後に必要なときだけ読む
とくに Top Nクエリ では一部のカラムだけが参照されるため、大容量のテキストカラムなどをほとんど読まない

> カラム独立保存方式だからこそ可能な最適化であり、行指向DBでは不可能なアプローチ

実例: Amazonレビューデータセット

150M rows、非圧縮70GB、圧縮30GB

Top Nクエリの例:

SELECT helpful_votes  
FROM amazon.amazon_reviews  
ORDER BY helpful_votes DESC  
LIMIT 3;

実行時間: 0.07秒
カラム単独参照により高速処理

大容量テキストカラム参照の例:
```
SELECT review_body  
FROM amazon.amazon_reviews  
FORMAT Null;  
```
- 実行時間: 176秒
- 単一カラムでも56GBあり、ディスクI/Oのボトルネックが発生

最適化レイヤー適用ごとの性能比較

1. 最適化なし (Baseline)

実行時間: 219秒
処理量: 72GB、150M rows
すべてのカラムを読み込んでソート

2. Primary Key Index適用

実行時間: 96秒
処理量: 28GB、53M rows
PKベースのgranuleフィルタリングで50%以上の時間短縮

3. PREWHERE追加

実行時間: 61秒
処理量: 16GB
非インデックスのフィルタ条件も適用して追加でI/Oを削減

4. Lazy Materialization有効化

実行時間: 0.18秒
処理量: 807MB
最終的に必要な3行だけを大きなカラムからロード

> 合計で1,200倍以上の性能向上、150倍以上のメモリ使用量削減

フィルタなしのTop Nクエリにも有効

フィルタなしの全体ソートクエリでは:

SELECT helpful_votes, product_title, review_headline, review_body  
FROM amazon.amazon_reviews  
ORDER BY helpful_votes DESC  
LIMIT 3;

lazy materialization 前: 219秒
lazy materialization 後: 0.139秒
1,576倍高速化、40倍I/O削減、300倍メモリ使用量削減

実行計画の確認

EXPLAIN actions = 1  
SELECT helpful_votes, product_title, review_headline, review_body  
FROM amazon.amazon_reviews  
ORDER BY helpful_votes DESC  
LIMIT 3  
SETTINGS query_plan_optimize_lazy_materialization = true;

結果:

Lazily read columns: review_headline, review_body, product_title   
  Limit                    
    Sorting                             
      ReadFromMergeTree

ソートとLIMITの後でのみ大容量カラムをロード

結論

ClickHouse の I/O最適化スタックが完成: Index → PREWHERE → Lazy Materialization
コード変更なしで、クエリ実行方式だけで性能を数百〜数千倍向上
とくに Top Nパターン、大容量カラム、LIMITクエリ に理想的
デフォルト設定で有効化 されており、ユーザーが個別に設定しなくても自動適用される

> 同じSQL、同じマシン、異なる結果
> 高速 = 読み取りが少ない = ClickHouse

2件のコメント

zihado 2025-04-24

> ClickHouse と StarRocks を比較した人がいるのか気になる。数か月前は StarRocks の結合性能のほうが良さそうに見えた
https://d2.naver.com/helloworld/1168674

GN⁺ 2025-04-24

Hacker Newsのコメント

この最適化は、大規模データセットからランダムサンプルを抽出する際、特に目的の列に大きな値が含まれる可能性がある場合に、劇的な高速化をもたらしそう
- 基本的なSQLレシピでは、サンプルに含める行を LIMIT 句で決定する
- 新しい最適化は、LIMIT 句がデータセットを少数の行に絞り込むまで、大きな列の読み込みを遅らせることを約束している
- この最適化がClickHouseで実際にこうしたクエリを高速化するか確認できる人がいるのか気になる
ClickHouseが本当に好き
- 最近見つけたばかりだが、分析向けの非効率なソリューションと比べると新鮮な空気のように感じる
- とても高速で、CLIも使っていて楽しい
スクロールできないWebサイトは理解できない
- 少しスクロールすると上に跳ね戻って、使いものにならない
遅延マテリアライゼーション、19年後
- 関連リンクあり
新しいマテリアライゼーションのオプションとは関係ないが、この部分が目を引いた
- クエリが1億5000万個の値をソートして上位3件を返すのに70ミリ秒しかかからない
- 現代のハードウェアとソフトウェアにおける「遅いクエリ」のメンタルモデルを更新する必要がある
- 1億5000万個の整数を70ミリ秒でソートするのは驚くべきことではない
- ピークメモリ使用量は3.59 MiB
- とても素晴らしい記事で、説明が明快で良い図も含まれている
ClickHouseにWSLやLinux仮想マシン不要のWindowsネイティブ版リリースがあれば、DuckDBより人気が出ていただろう
- MySQLがPostgreSQLより人気だった理由の1つは、MySQLにWindowsインストーラがあったことだ
空港ドラマにもかかわらず、ビーチ休暇を計画中
- 技術情報と図は最高水準だったが、物語が含まれていたことでさらに良くなっていた
ClickHouseは現代エンジニアリングの傑作
- パフォーマンスに絶対的な注意を払っている
ClickHouseとStarRocksを比較した人がいるのか気になる
- 数か月前は、StarRocksの結合性能のほうが良さそうに見えた
こうしたデータベースが、すべての行指向データベースが間違っていたことを示しているのは驚き
- btreeインデックス構造では、この速度には到底近づけない
- 現代のマシンがどれほど速いかを見るのは驚くべきことだ
- データセットは適切に圧縮されていなかったのではないかと思う
- データ読み込みは展開より遅い
- 暗号化は無料だというアイデアがあったCloudflareの記事を思い出す
- コンピュートエンジン (chdb) を使っているのが驚き