这是《ClickHouse 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 ClickHouse 和 Elasticsearch 都是常见的数据平台，但优化目标不同：前者面向大规模扫描聚合，后者面向搜索、倒排检索和可观测性场景。
29.1 核心差异
| 维度 | ClickHouse | Elasticsearch |
|---|---|---|
| 存储模型 | 列式 | 面向文档，倒排索引 |
| 强项 | 大范围聚合分析 | 全文检索、相关性搜索 |
| 写入 | 批量 append | 文档近实时写入 |
| 更新 | Merge 语义 | 文档 update / delete |
| 聚合 | 强，成本可控 | 可用，深度聚合成本高 |
| 查询模式 | SQL | DSL / QL |
| 典型场景 | 数仓、报表、行为分析 | 搜索、日志检索、APM |
29.2 日志场景
Elasticsearch：
优点：检索表达式丰富、生态成熟、权限和索引生命周期完善
代价：大范围聚合和长期留存成本高
ClickHouse：
优点：压缩率高、扫描聚合快、长期存储成本低
代价：全文检索和相关性排序能力不如专门搜索系统
常见组合：
Kafka
-> Elasticsearch：最近 7 天检索
-> ClickHouse：6 个月或更长期分析
29.3 用户行为分析
漏斗、留存、多维聚合：
SELECT city_id, event_type, count(), sum(amount)
FROM analytics.events
WHERE event_date = today()
GROUP BY city_id, event_type;
这类查询通常更适合 ClickHouse。若需要“搜索符合条件的一批用户”，再用 Elasticsearch 或业务检索服务。
29.4 指标监控
常见选择：
| 需求 | 方案 |
|---|---|
| 高基数指标长期存储 | ClickHouse / TSDB |
| 指标采集与告警 | Prometheus + TSDB |
| 日志与 trace 检索 | Elasticsearch / Loki / ClickHouse |
| 统一可观测性 | 根据规模和查询模式选择 |
ClickHouse 可以存 Prometheus 长期指标，但告警链路通常仍由 Prometheus 或其他监控服务承担。
29.5 更新语义
ClickHouse：
ReplacingMergeTree 后台替换
CollapsingMergeTree 正负抵消
查询需处理版本
Elasticsearch：
按文档 ID update / delete
近实时可见
segment merge 后清理
如果业务核心是文档 ID 级更新和检索，Elasticsearch 更自然；如果是分析快照，ClickHouse 的版本化合并模型更有优势。
29.6 容量与性能
比较时要使用相同条件：
- 相同数据集；
- 相同压缩和索引配置；
- 相同查询集；
- 相同并发；
- 相同硬件；
- 相同保留期；
- 相同一致性要求。
Elasticsearch 索引、副本和查询缓存会消耗较多内存；ClickHouse 的成本主要来自磁盘扫描、合并和高并发查询 CPU。
29.7 选型流程
1. 查询是检索为主还是聚合为主？
2. 是否需要全文和相关性行？
3. 数据保留多久？
4. 写入是批量流还是文档更新？
5. 团队运维能力？
6. 成本模型如何？
7. 是否可以两系统协同？
29.8 常见误区
| 误区 | 修正 |
|---|---|
| ClickHouse 可以替代所有搜索 | 全文检索不是它的核心强项 |
| Elasticsearch 聚合一定慢 | 取决于规模、映射和查询 |
| 只比较单条 SQL 耗时 | 要看并发、成本和保留期 |
| 双写一定能一致 | 需要边界和对账 |
| 迁移后 schema 照搬 | 要重新建模 |
本章小结
ClickHouse 与 Elasticsearch 是互补关系。ClickHouse 擅长大规模分析、预聚合和长期存储；Elasticsearch 擅长全文检索和文档化查询。根据查询模式、更新语义和成本选择，而不是简单追求一个系统解决所有问题。
思考题
- 哪些日志查询更适合 Elasticsearch？
- 哪些行为分析更适合 ClickHouse？
- 两系统并存的边界和口径如何设计？
- 更新语义有什么差异？
- 如何做公平的性能对比？