# ClickHouse vs Elasticsearch: ログ/分析にはどちら?

> ClickHouse vs Elasticsearch: カラムナー型の分析データベースと全文検索エンジンの比較。クエリモデル、コスト、全文検索、CI/運用への適合性を率直に比較します。

Source: https://latchkey.dev/ja/learn/tool-comparisons/clickhouse-vs-elasticsearch  
Updated: 2026-06-26

ClickHouseは分析とログクエリ向けの高速なカラムナーデータベースであり、Elasticsearchは強力なテキスト検索と集計を備えた全文検索エンジンです。

ClickHouseはデータをカラムナー形式で保存して積極的に圧縮するため、大規模な分析クエリやログ集計クエリを高速かつ低コストで実行できますが、全文検索はネイティブ性が低めです。Elasticsearchはコンテンツをインデックス化してリッチな全文検索とファセット探索を実現しますが、ストレージコストは高くなります。ClickHouseは分析スループットとストレージコストで優れ、Elasticsearchは全文検索と探索UXで優れています。

## Comparison

|  | ClickHouse | Elasticsearch |
| --- | --- | --- |
| モデル | カラムナーSQL | 転置インデックス |
| 強み | 分析、集計 | 全文検索 |
| ストレージコスト | 非常に低い | 高め |
| 全文検索 | 限定的 | 優秀 |
| 最適な用途 | 大規模なログ分析 | 検索中心のログ |

## ユースケースとコスト

ClickHouseはSQL集計とストレージコストが支配的となる大量のログ・イベント分析に適しており、多くの観測可能性プラットフォームが現在ClickHouseにログを保存しています。Elasticsearchはユーザーが自由にテキストを探索し、ランキングやファセットを必要とする検索中心の用途に適しています。

## 運用とCIへの適合性

ClickHouseは極めてよく圧縮でき、実行効率も高い一方、Elasticsearchはシャードとヒープの慎重なチューニングが必要です。どちらもエフェメラルなインスタンスに対してCIで結合テストされ、より高速なマネージドrunnerがイメージのpullとクエリテストを短縮します。

## Decide with your own numbers, not a feature table

Feature comparisons age badly and rarely decide anything, because both tools in a mature category can do the job. What differs is how each behaves on your repository, and that takes one afternoon to measure.

```Terminal
# time a cold install with each candidate, cache cleared
hyperfine --prepare "rm -rf node_modules" --warmup 1 \
  "<tool-a> install" "<tool-b> install"

# and the thing CI actually pays for: a cold run with no local cache
docker run --rm -v "$(pwd):/w" -w /w node:22 sh -c "<tool> install"
```

> Measure the cold path. Warm local benchmarks favour whichever tool you already have cached, which is exactly the condition a CI runner never has.

## What actually changes when you switch

- Lockfile format. A switch is a one-way door for anyone still on the old tool until everyone migrates, so plan it as a single coordinated change.
- Resolution strictness. Tools differ on whether an undeclared transitive import works, and the stricter one will surface latent bugs as new failures.
- CI cache configuration. The cache path and key differ per tool; carrying over the old ones silently disables caching.
- Everyone on the team and every runner must move together. Pin the version so they cannot drift.

## 結論

SQLで安価かつ高速なログ分析が欲しいなら: ClickHouse。リッチな全文検索と探索が欲しいなら: Elasticsearch。分析とコストはClickHouseに、検索の深さはElasticsearchに有利です。

## FAQ

### ClickHouse vs Elasticsearch: Which for Logs/Analytics?

ClickHouse stores data columnar and compresses it aggressively, making large-scale analytical and log aggregation queries fast and cheap, though full-text search is less native. Elasticsearch indexes content for rich full-text search and faceted exploration, at higher storage cost.

### Use case and cost?

ClickHouse suits high-volume log and event analytics where SQL aggregations and storage cost dominate; many observability platforms now store logs in ClickHouse. Elasticsearch suits search-heavy use where users explore text freely and need ranking and facets.

### Ops and CI fit?

ClickHouse compresses extremely well and is efficient to run; Elasticsearch needs careful shard and heap tuning. Both are integration-tested in CI against ephemeral instances, where faster managed runners shorten image pulls and query tests.

### Which should I choose?

Want cheap, fast log analytics with SQL: ClickHouse. Want rich full-text search and exploration: Elasticsearch. Analytics and cost favor ClickHouse; search depth favors Elasticsearch.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt