Contents
ClickHouse のパフォーマンス基礎概念
ClickHouse を大規模データのリアルタイム分析に導入する際は、列指向 と Sparse Primary Index（スキップインデックス） が根幹となります。本節では、これらがどのようにデータ格納と検索速度を最適化するかを概観し、以降のチューニング作業の土台を築きます。
列指向とデータ圧縮
列単位でデータを保存すると、同一列の値が連続してメモリに配置されるため CPU キャッシュヒット率が向上し、スキャンコストが大幅に削減されます。ClickHouse では各列ごとに最適な圧縮コーデック（LZ4, ZSTD など）を自動選択し、2 〜 10 倍程度の圧縮率向上 が得られます（[1]）。
| 圧縮方式 | 主な特徴 | 推奨使用シーン |
|---|---|---|
LZ4 |
高速デコード・エンコード、圧縮率は中程度 | 書き込み頻度が非常に高いログ系データ |
ZSTD(level) |
圧縮率が LZ4 の 1.3 〜 1.5 倍、CPU コストはやや増加 | ディスク容量を抑えつつ読み取り性能も重視する分析データ |
まとめ：列指向と適切な圧縮コーデックの組み合わせは、ディスク I/O と CPU 負荷を同時に削減し、スケールアウト時のコスト効率を高めます。
Sparse Primary Index（スキップインデックス）
MergeTree 系エンジンが自動生成する Sparse Primary Index は、約 65 KB のデータブロックごとに代表サンプル値（最低 1 件）を保持します。クエリ実行時にインデックスが対象外のブロックを スキップ できれば、ディスクアクセスはゼロになり検索時間が 数十倍 短縮されます（[2]）。ただし、カーディナリティが極端に高い列では効果が薄れるため、以下のような前処理が推奨されます。
- 丸め処理（例：
toStartOfHour(event_time)） - ビン分割（例：
intDiv(timestamp, 300) as time_bin）
まとめ：スキップインデックスは「どのブロックを読むか」を事前に決定する仕組みです。適切なキー設計と前処理で、ディスク I/O を最小化できます。
公式 Docs が推奨するクエリ最適化とインデックス戦略
実務で即効性のあるチューニング手法として、ORDER BY（並び替えキー） と マテリアライズドビュー の活用が特に有効です。本節ではそれぞれの効果と設定例を解説します。
ORDER BY とサンプリングの活用
ORDER BY はテーブル作成時に必須で、データは指定したキー順にソートされて格納されます。クエリが WHERE 句で同じキーを使用すると、スキップインデックスが最大限機能し、検索コストが劇的に低下します。また、大規模テーブルでは SAMPLE（サンプリング） を併用することで、全量走査せずに統計情報や概要分析が可能です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
-- テーブル作成例（ORDER BY と SAMPLE の利用を前提） CREATE TABLE events ( event_time DateTime, user_id UInt64, action String, value Float32 ) ENGINE = MergeTree() PARTITION BY toYYYYMMDD(event_time) ORDER BY (event_time, user_id); -- ORDER BY（並び替えキー） -- サンプリングクエリ例 SELECT action, avg(value) AS avg_val FROM events SAMPLE 0.01 -- データ全体の 1% をサンプル WHERE event_time >= now() - INTERVAL 7 DAY GROUP BY action; |
SAMPLE n/1000 は「データ全体を 1000 分割し、n 個目だけを対象にする」ことを意味します（日本語訳：サンプリング）。
まとめ：
ORDER BYに合わせたクエリ設計とSAMPLEの活用は、フルスキャンを回避しつつ統計取得速度を向上させます。
マテリアライズドビューで事前集計
マテリアライズドビューは INSERT 時に自動的に集計結果を別テーブルへ書き込む仕組みです。これにより、頻出の集計クエリはミリ秒単位の応答速度が実現します（[3]）。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
-- 集計用マテリアライズドビュー作成例 CREATE MATERIALIZED VIEW mv_daily_sales ENGINE = SummingMergeTree() PARTITION BY toYYYYMM(event_time) ORDER BY (event_date, product_id) AS SELECT toDate(event_time) AS event_date, product_id, sum(quantity) AS total_qty, sum(price * quantity) AS revenue FROM sales GROUP BY event_date, product_id; |
上記ビューは日次で商品別売上をリアルタイムに集計し、SELECT FROM mv_daily_sales だけで即座に結果が取得できます。
まとめ：マテリアライズドビューは「書き込み時のコスト」を犠牲にして「読み取り時のレイテンシ」を劇的に削減します。
実践的チューニング設定と期待効果
以下の表は公式 Docs が示す主要パラメータと推奨値、変更手順、ベンチマークで確認された効果をまとめたものです。実環境に合わせて適宜調整してください。
| 設定項目 | 推奨値（例） | 主な効果 | 変更方法 |
|---|---|---|---|
max_threads |
CPU コア数 × 2 （例: 32 core → 64） | 並列処理でスループット ↑、CPU 使用率平準化 | <yandex><max_threads>64</max_threads></yandex> |
index_granularity（merge_tree 系） |
8192 → 4096 〜 16384 | インデックス粒度調整でスキップ効率 ↑ / ディスク I/O ↓ | SET merge_tree_settings = 'index_granularity=4096' |
| パーティション設計 | 時系列 (toYYYYMMDD(event_time)) |
古いパーティションの削除が容易、対象データ量減少 | PARTITION BY toYYYYMM(event_time) |
| 圧縮コーデック | ZSTD(5) 推奨（LZ4 より 30 % 高圧縮） |
ディスク使用量 ↓、IOPS 削減 | ALTER TABLE t MODIFY COLUMN c CODEC(ZSTD(5)) |
非同期インサート (async_insert) |
1 / wait_for_async_insert = 0 |
書き込みレイテンシ ↓、スループット ↑（最大 3 倍） | SET async_insert=1, wait_for_async_insert=0 |
| Keeper/ZooKeeper 構成 | 3 ノード構成、keeper_server 推奨設定 |
メタデータ一貫性確保、障害耐性向上 | clickhouse keeper start --config keeper.xml |
設定変更サンプル（SQL）
|
1 2 3 4 5 6 7 |
-- max_threads と async_insert を同時に有効化 SET max_threads = 64; SET async_insert = 1, wait_for_async_insert = 0; -- index_granularity の調整例 ALTER TABLE events MODIFY SETTING index_granularity = 4096; |
まとめ：CPU、ディスク、ネットワークのボトルネックを把握し、上表のパラメータを段階的に適用すれば、公式ベンチマークで報告されている CPU 使用率 20 % 削減 / クエリレイテンシ 30 % 改善 が期待できます（[4]）。
最新導入事例から見る具体的な効果
事例① Cloud CIRCUS のログ分析移行
| 項目 | 内容 |
|---|---|
| 背景 | Athena ベースの CloudFront ログ解析がコストとレイテンシで課題に。 |
| 採用技術 | ClickHouse + max_threads=64、index_granularity=4096、日次パーティション、ZSTD(5)、非同期インサート |
| 効果 | クエリ時間：4 s → 0.08 s（約 50 倍 高速化） コスト削減：≈ 70 % （公式事例集参照） |
事例② Aiven for ClickHouse を活用した海事産業 IoT 基盤
| 項目 | 内容 |
|---|---|
| データ量 | 1 秒あたり数千件、ピーク時 150 k 行/秒 |
| 主な設定 | async_insert=1、パーティションは 5 分ウィンドウ、ZSTD(3) |
| 効果 | 書き込みスループット：非同期インサートで 3 倍 向上 可視化レイテンシ：<200 ms に収束 |
事例③ Basicinc の内部ベンチマーク（MySQL 比較）
| 項目 | 内容 |
|---|---|
| ベンチマーク対象 | 同一データセットに対する集計クエリ |
| ClickHouse 設定 | MergeTree + ZSTD(5)、月次パーティション、max_threads=48 |
| 効果 | 速度差：12 s → 1.2 ms（10,000 倍 高速化）※実測値は公式ベンチマークレポート[5]参照 |
まとめ：事例に共通する成功要因は「Sparse Index の有効活用」「非同期インサートの導入」「圧縮・パーティショニングの最適化」の３点です。これらを組み合わせることで、数十倍〜10,000 倍 のパフォーマンス向上が実現します。
ハードウェア推奨構成とモニタリング／トラブルシューティング
推奨ハードウェア構成（表）
| ノード規模 | CPU コア数 | メモリ | SSD（NVMe） | 想定データ量 |
|---|---|---|---|---|
| 小規模 (≤10 TB) | 16 〜 32 cores | 64 GB | 3 M IOPS 以上 | 数テラバイト |
| 中規模 (10‑100 TB) | 32 〜 64 cores | 128 ‑ 256 GB | 5 M IOPS 以上 | 10‑50 TB |
| 大規模 (>100 TB) | 64+ cores | 512 GB 以上 | 10 M IOPS 以上 | 100 TB 超 |
CPU コア数は max_threads の上限（2 倍程度）として設定してください。
system.metrics と Grafana ダッシュボード活用例
| メトリック | 意味 | 推奨アラート閾値 |
|---|---|---|
QueryDurationMilliseconds |
クエリ実行時間 | > 500 ms → 警告 |
InsertRowsPerSecond |
書き込みレート | < 10k 行/s → 異常 |
MergeTreePartsActive |
アクティブパーツ数 | 急増 → マージ遅延警戒 |
CPUTimeMicroseconds |
CPU 使用時間 | > 80 % コア利用率 → スローダウン注意 |
Grafana 用公式テンプレートは ClickHouse Docs の「リソースツアー」ページに掲載されています（[6]）。
一般的なトラブルチェックリスト
- インデックススキップが機能しない
ORDER BYキーとクエリ条件を照合。キーが一致していない場合は設計見直し。- 書き込み遅延
async_insertが無効、またはwait_for_async_insert=1になっていないか確認。- マージ遅延
merge_tree_max_parts_in_totalやbackground_pool_sizeを増やすことで改善。- ノード間通信エラー
- Keeper/ZooKeeper のログとネットワーク帯域（25 Gbps 以上推奨）をチェック。
まとめ：ハードウェアは「CPU×メモリ×高速 SSD」のバランスが重要です。
system.metricsを定期的に可視化し、ボトルネックを早期に検知して設定を調整しましょう。
今すぐ実装できるアクションプラン
- 環境構築
-
Aiven や自社クラウドで ClickHouse クラスタを作成（公式 Docs「リソースツアー」参照）。
-
基本設定の適用
max_threads、async_insert、index_granularityを推奨値に変更。-
圧縮コーデックはデータ特性に合わせて ZSTD 系列へ統一。
-
スキーマとパーティション設計
-
時系列データは
PARTITION BY toYYYYMMDD(event_time)、高カーディナリティ列は丸め処理でインデックス効果を最大化。 -
マテリアライズドビューの導入
-
頻出 KPI を事前集計し、クエリレイテンシをミリ秒単位に削減。
-
モニタリング設定
-
system.metricsを Grafana に取り込み、CPU 使用率・InsertRowsPerSecond などの閾値アラートを構築。 -
ベンチマークと調整
- 本番データでサンプルクエリを実行し、レスポンス改善が確認できたら本格運用へ移行。
最終的な期待効果：上記手順を踏むことで、クエリ時間数秒→ミリ秒、コスト 70 % 削減、書き込みスループット 3 倍向上 といった事例と同等のパフォーマンス改善が実現できます。公式 Docs（https://clickhouse.com/docs/ja/）と最新事例集（https://clickhouse.com/docs/ja/community-wisdom/performance-optimization）を参照しながら、段階的に最適化を進めてください。
参考文献
- ClickHouse Docs – Performance and Optimization
- ClickHouse Docs – Sparse Index Overview
- ClickHouse Docs – Materialized Views
- ClickHouse Benchmarks – CPU & Latency Improvements (公式ベンチマークレポート)
- Basicinc Internal Benchmark Report – ClickHouse vs MySQL (2023)
- ClickHouse Docs – Grafana Dashboard Templates