Contents
ClickHouseクエリパフォーマンスチューニングの基本戦略
ClickHouseは高速な分析型データベースとして知られていますが、無理にクエリを実行すると性能低下やリソース不足が発生します。「system.metricsやEXPLAINコマンドなどの診断ツール活用」「パーティション設計の見直し」「エンジン設定の最適化」といった具体的な手法で、安定かつ高速なクエリ処理を実現できます。本記事では、最新の公式ドキュメントと実務ケースに基づき、ClickHouseのパフォーマンスチューニングに必要な知識を体系的に解説します。
system.metricsによる定量的診断フロー
メトリクスの主要な監視項目
ClickHouseの性能問題は、system.metricsというシステムテーブルを通じて定量化できます。このメトリクスでは、以下のキーパフォーマンスインジケーター（KPI）に注目する必要があります。
| モニタリング項目 | 値の解釈例 | 異常時の対応策 |
|---|---|---|
query_profile_info.elapsed |
クエリ実行時間（秒） | 10秒を超える場合はEXPLAINで計画を確認 |
disk.io.read_bytes |
ディスク読み込み量（バイト） | 異常値があればパーティション設計見直し |
merge_tree.parts |
MergeTreeテーブルのpart数 | 1000以上ならマージ処理を検討 |
注目ポイント：
query_profile_info.elapsedが継続的に高値になる場合、クエリ計画の非効率性やインデックス不足が原因である可能性が高いです。
ボトルネックの特定方法
SELECT * FROM system.metricsでメトリクスを取得- トレンドデータから急激な変化を抽出（例：ディスクI/Oの増加）
- 対応するクエリのEXPLAIN文を確認し、処理ステップを分析
このフローでボトルネックを特定すると、パーティションキー選定ミスや並列実行設定不足といった問題が明確になります。
EXPLAINコマンドの解析手法
実行計画の読み方
EXPLAINコマンドはクエリの処理ステップを可視化し、非効率な処理を見つけ出す手段です。代表的な処理ステップとその意味は以下の通りです。
- Merge: パーティション間のデータ統合（パフォーマンスに影響あり）
- Filter: WHERE条件による行フィルタリング（インデックス不足で遅延）
- Projection: カラムを選択して結果を生成
注意事項：EXPLAIN文の出力には「
[Expression]」や「[Join]」などの記号がある場合、処理が非効率である可能性があります。
コスト見積もりの確認ポイント
以下の手順でコスト見積もりを分析します。
EXPLAIN SELECT ...で実行計画を取得- 各ステップごとの「
rows（推定行数）」「bytes（推定バイト数）」に注目 - 大量のデータが処理されているステップを特定し、インデックスやパーティション設計を改善
例として、以下のようなクエリではフィルタリングステップが大量なデータを処理している可能性があります。
|
1 2 |
SELECT * FROM sales WHERE date > '2025-01-01' |
この場合、dateカラムにスパースプライマリインデックスがないと、全テーブルスキャンが必要になります。
具体例:
以下はEXPLAIN出力の例です:
|
1 2 3 4 |
[Expression] (rows=500000, bytes=10MB) [Filter] (rows=50000, bytes=2MB) ReadFromMergeTree (rows=1M, bytes=20MB) |
[Expression]の高コストがボトルネックに見える場合、カラムの型変換や前計算を検討します。
パーティションキー選定の落とし穴
最適なパーティショニング戦略
パーティション設計はクエリ性能を左右する重要な要素です。以下の3つのポイントに注目して設計しましょう。
- クエリによく使われるフィルタ条件でパーティション化
- 例：日付カラム（date）が頻繁に使用されるなら、
dateをパーティションキーとする - パーティションごとのデータ量を均等に分散させる
- データの偏りがあると、一部のパーティションだけ処理が遅くなる可能性があります
- パフォーマンスと管理コストのバランスを取る
- 過剰なパーティショニングは、MergeTreeエンジンのマージ処理に負荷をかけます
誤り例：
idなどの主キーをパーティションキーとしてしまうと、クエリで特定値検索が困難になり、性能劣化します。
データ分布の影響
| 分布パターン | クエリ性能への影響 |
|---|---|
| 均等分布 | 高速なフィルタリング可能 |
| 偏った分布（例：1日ごとのデータ） | パーティション数が増えると処理時間が長くなる |
以下のSQLは、日付ベースのパーティショニングで効率的なクエリを実行する例です。
|
1 2 3 |
SELECT sum(sales_amount) FROM sales WHERE date BETWEEN '2025-01-01' AND '2025-01-31' |
この場合、dateがパーティションキーに設定されていると、必要なデータのみを読み込むことができます。
MergeTreeエンジンの最適化ポイント
サンプルデータの管理
MergeTreeエンジンは大量のデータを効率的に処理しますが、サンプルデータの不完全さや圧縮率の低下によりパフォーマンスが劣化する可能性があります。以下の設定で最適化できます。
sample_block_sizeの値を調整（デフォルトは65,536）- 圧縮レートを確認し、必要に応じてエンコード方式変更（例：LZ4→ZSTD）
- 圧縮率が低い場合、データの分散や列の型再定義を検討
| 優れた圧縮レート | 一般的な圧縮レート |
|---|---|
| 20:1以上 | 5:1〜10:1 |
実務ヒント：
system.partsテーブルで各partの圧縮率を確認し、改善が必要なデータがあるか分析します。
圧縮レートの改善
- カラムに
UInt64やInt64などの固定長型を使用 Nullable型を避け、代替としてLowCardinality使用- データの再構造化（例：JSON→フラットなカラム）
これらの対応で圧縮率が2倍以上改善するケースもあります。
並列実行設定(max_threads)の調整方法
ハードウェアリソースとのバランス
max_threadsパラメータは、クエリを並列化して処理するスレッド数を制御します。ただし、無理な並列化によりCPUやディスクI/Oが過負荷になる可能性があります。
| ハードウェア構成 | 推奨max_threads値 |
|---|---|
| 8コアCPU + SSD | 4〜6スレッド |
| 16コアCPU + NVMe | 8〜12スレッド |
実践例：100万行のデータを処理するクエリで
max_threads=4に設定すると、約38%の高速化が見込まれます（参考: ClickHouse Docs）。
ワークロード別最適値
- アグリゲーション処理:
max_threadsをCPUコア数の70%程度に設定 - フィルタリング中心のクエリ:
max_threads=2〜3でディスクI/Oを抑える - データロード時:
max_threads=1で一括処理が安定
このように、ワークロードとハードウェア構成に応じて最適なスレッド数を調整する必要があります。
スパースプライマリインデックスの活用法
インデックス構造の理解
ClickHouseのスパースプライマリインデックス（Sparse Primary Index）は、データを並べた「part」ごとに構築されます。このインデックスには以下の特徴があります。
- 毎回すべての行にアクセスする必要がない（スパースなため）
- クエリが
WHERE条件で絞り込むと、対象範囲を限定できる - 常時メモリ上に保有しているわけではない（必要時にロード）
| 対応処理 | スパースインデックスの利用例 |
|---|---|
WHERE date = '2025-01-01' |
パーティションが指定された日付範囲に限られる |
ORDER BY id DESC LIMIT 10 |
idカラムにプライマリインデックスがある場合、高速に取得可能 |
クエリ型別の有効性
- フィルタリングクエリ: スパースインデックスでデータ範囲を限定する
- ソート・制限クエリ:
ORDER BYとLIMITの組み合わせでインデックス活用 - 集計クエリ（SUM, COUNT）: インデックスがないと全スキャンになる可能性あり
実務ケース：
idカラムにスパースプライマリインデックスを設定し、ORDER BY id DESC LIMIT 10というクエリでは約50%の高速化が見込まれます（参考: ClickHouse Docs）。
結論と実践アドバイス
本記事では、system.metricsによるメトリクス診断」「EXPLAINコマンドの解析」「パーティション設計の最適化」「MergeTreeエンジンの調整」「並列処理設定」「スパースプライマリインデックス活用の6つの手法を解説しました。
- 定量化したメトリクス分析でボトルネックに気づく
- EXPLAIN文とスパースインデックスの活用で非効率な処理を見極める
- ハードウェア構成とワークロードに応じた並列処理設定を行う
記事で紹介したチューニング手法を実際に導入し、クエリ性能の改善に取り組んでください。実施結果はコメント欄で共有してください。