ClickHouse パフォーマンス基礎と最適化ガイド – 列指向・Sparse Index の活用

2026年6月24日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 ClickHouse のパフォーマンス基礎概念
- 1.1 列指向とデータ圧縮
- 1.2 Sparse Primary Index（スキップインデックス）
2 公式 Docs が推奨するクエリ最適化とインデックス戦略
- 2.1 ORDER BY とサンプリングの活用
- 2.2 マテリアライズドビューで事前集計
3 実践的チューニング設定と期待効果
- - 3.0.1 設定変更サンプル（SQL）
4 最新導入事例から見る具体的な効果
5 ハードウェア推奨構成とモニタリング／トラブルシューティング
6 今すぐ実装できるアクションプラン
- 6.1 参考文献

スポンサードリンク

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（サンプリング） を併用することで、全量走査せずに統計情報や概要分析が可能です。

-- テーブル作成例（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 &gt;= now() - INTERVAL 7 DAY
GROUP BY action;

-- テーブル作成例（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]）。

-- 集計用マテリアライズドビュー作成例
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;

-- 集計用マテリアライズドビュー作成例

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）

-- 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;

-- 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]）。

項目	内容
背景	Athena ベースの CloudFront ログ解析がコストとレイテンシで課題に。
採用技術	ClickHouse + `max_threads=64`、`index_granularity=4096`、日次パーティション、ZSTD(5)、非同期インサート
効果	クエリ時間：4 s → 0.08 s（約 50 倍高速化）コスト削減：≈ 70 % （公式事例集参照）

項目	内容
データ量	1 秒あたり数千件、ピーク時 150 k 行/秒
主な設定	`async_insert=1`、パーティションは 5 分ウィンドウ、ZSTD(3)
効果	書き込みスループット：非同期インサートで 3 倍向上可視化レイテンシ：<200 ms に収束

項目	内容
ベンチマーク対象	同一データセットに対する集計クエリ
ClickHouse 設定	MergeTree + ZSTD(5)、月次パーティション、`max_threads=48`
効果	速度差：12 s → 1.2 ms（10,000 倍高速化）※実測値は公式ベンチマークレポート[5]参照

ハードウェア推奨構成とモニタリング／トラブルシューティング

推奨ハードウェア構成（表）

ノード規模	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

スポンサードリンク

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

-ClickHouse

comment コメントをキャンセル

: ClickHouse

ClickHouse と Grafana の連携手順：インストール・設定・ベンチマーク完全ガイド

ClickHouse と Grafana を連携させるためのバージョン要件からインストール、データソース設定、パフォーマンスチューニングまでを網羅した手順です。

: ClickHouse

ClickHouse Cloud 完全ガイド：概要・クイックスタート・本番運用まで

数分で始められるフルマネージド OLAP データベース、ClickHouse Cloud の概要から実践的な設定・運用方法をまとめました。

: ClickHouse

ClickHouseのベクトル化クエリ実行とChunk/Batch処理の全貌

ClickHouseのベクトル化クエリ実行はデータをChunkやBatch単位で処理し、CPUキャッシュとSIMDを活用して数倍の高速化を実現します。

: ClickHouse

ClickHouse コスト削減と最適化ガイド｜CPU・ディスク・圧縮設定

CPU とディスク I/O が主要コストドライバーである ClickHouse の運用において、圧縮レベル、パーティション設計、インデックス戦略、スレッド設定など実践的な最適化手法を紹介します。

: ClickHouse

ClickHouse Cloud: AWS vs GCP比較と導入ガイド

AWSとGCPにおけるClickHouse Cloudのコスト、運用負荷、最新機能、パフォーマンスを比較。技術責任者が導入時に考慮すべきポイントを解説します。

ClickHouseとGrafanaの連携ガイド: ダッシュボード設定とツール比較

KrakenD Microservices Performance Tuning Guide

ClickHouse パフォーマンス基礎と最適化ガイド – 列指向・Sparse Index の活用

ClickHouse のパフォーマンス基礎概念

列指向とデータ圧縮

Sparse Primary Index（スキップインデックス）

公式 Docs が推奨するクエリ最適化とインデックス戦略

ORDER BY とサンプリングの活用

マテリアライズドビューで事前集計

実践的チューニング設定と期待効果

設定変更サンプル（SQL）

最新導入事例から見る具体的な効果

事例① Cloud CIRCUS のログ分析移行

事例② Aiven for ClickHouse を活用した海事産業 IoT 基盤

事例③ Basicinc の内部ベンチマーク（MySQL 比較）

ハードウェア推奨構成とモニタリング／トラブルシューティング

推奨ハードウェア構成（表）

system.metrics と Grafana ダッシュボード活用例

一般的なトラブルチェックリスト

今すぐ実装できるアクションプラン

参考文献