4. 追踪数据存储选型：Elasticsearch、Jaeger 存储、ClickHouse 的时序与全文检索能力对比
在分布式追踪平台中，存储后端是决定查询性能、成本与运维复杂度的核心组件。自助查询接口的设计必须依赖底层存储的检索能力，尤其是对 TraceID 精确查找、标签/属性全文检索 以及 时间范围聚合 三类典型场景的支持。本节从时序写入、全文检索、资源消耗三个维度，对比 Elasticsearch、Jaeger 原生存储（Badger/Cassandra）与 ClickHouse 的适用边界。
选型前提： 以下对比基于生产环境 10TB+ 追踪数据规模，采样率 100% 场景。若日均 Span 量低于 1 亿，Elasticsearch 仍是最易上手的方案。
4.1 三类存储引擎的核心差异
| 维度 | Elasticsearch | Jaeger 原生存储 (Badger/Cassandra) | ClickHouse |
|---|---|---|---|
| 存储模型 | 倒排索引 + 列式 doc_values | LSM-Tree (Badger) / 宽列 (Cassandra) | 列式存储 + 主键排序 |
| 写入模式 | 近实时 (NRT)，1s 刷新 | 实时写入，无全局索引 | 批量插入，推荐 1-10 秒合并 |
| 全文检索 | 原生支持，分词/模糊/正则 | 仅支持精确匹配 (Tag 索引) | 需配合 tokenbf_v2 或 ngram 跳数索引 |
| 时序聚合 | 较差，date_histogram 需大量堆内存 | 不支持原生时序聚合 | 极优，物化视图 + TTL 自动降采样 |
| TraceID 查询 | O(1) 路由，毫秒级 | O(1) 主键查询，毫秒级 | O(log n) 主键索引，亚秒级 |
| 压缩率 | 1:3 ~ 1:5 (LZ4) | 1:2 ~ 1:3 (无全局压缩) | 1:6 ~ 1:10 (ZSTD + 列式编码) |
| 运维复杂度 | 高，需调优 JVM/分片/段合并 | 低 (Badger) / 中 (Cassandra) | 中，需管理分区与合并树 |
关键结论： Elasticsearch 在“任意字段全文检索”场景占优；ClickHouse 在“大规模时序聚合 + 低成本存储”场景胜出；Jaeger 原生存储仅适合小规模（< 5TB）或开发环境。
4.2 全文检索能力对比：从 TraceID 到 Tag 模糊搜索
自助查询接口的核心体验在于 “搜索任意 Span 属性” 的响应速度。以下对比三种引擎在典型查询模式下的表现：
- 精确 TraceID 查询： 三者均能通过主键/路由在 100ms 内返回，Elasticsearch 和 ClickHouse 支持批量 TraceID 查询。
- 标签键值对精确匹配： Jaeger 原生存储依赖 Tag 索引（仅支持等值查询），Elasticsearch 和 ClickHouse 均可通过 KV 索引快速定位。
- 标签值模糊搜索： 例如查询 http.url 包含 "/api/v2/order" 的所有 Span。Elasticsearch 原生支持；ClickHouse 需建立 tokenbf_v2 跳数索引，首次查询较慢；Jaeger 原生存储不支持。
- 正则/通配符搜索： 仅 Elasticsearch 支持实时正则，ClickHouse 的 regexp 函数需全表扫描（除非配合物化列）。
4.3 时序写入与存储成本：ClickHouse 的压倒性优势
追踪数据本质上是 高基数时序数据——每个 Span 携带唯一的 TraceID、Service、Operation 以及数十个标签。ClickHouse 的列式存储与物化视图机制在此场景下具备天然优势：
- 写入吞吐： ClickHouse 单节点可达到 200MB/s 写入，Elasticsearch 受限于分片刷新与段合并，通常为 50-100MB/s。
- 存储压缩： 相同数据集下，ClickHouse 的 ZSTD 压缩比 Elasticsearch 的 LZ4 节省 40%-60% 磁盘空间。
- 时序降采样： ClickHouse 通过物化视图 + TTL 自动将原始 Span 数据聚合为分钟级/小时级统计，无需额外 ETL 管道。
避坑提示： 不要将 Elasticsearch 作为“时序数据库”使用。当需要查询“过去 7 天每分钟的 P99 延迟”时，Elasticsearch 的 date_histogram 聚合会触发大量 fielddata 加载，极易导致 GC 抖动甚至 OOM。ClickHouse 的 AggregatingMergeTree 表引擎专为此场景设计。
4.4 混合存储架构：取长补短的最佳实践
在大型平台工程实践中，单一存储引擎难以同时满足“全文检索”与“时序聚合”的需求。推荐采用 双写双读 或 热温分层 架构：
4.5 选型决策矩阵
根据团队规模与查询场景，推荐以下选型路径：
| 场景 | 推荐存储 | 理由 |
|---|---|---|
| 日均 Span < 5 亿，需要任意字段搜索 | Elasticsearch | 开箱即用的全文检索，运维成本可接受 |
| 日均 Span > 10 亿，以 TraceID 查询为主 | ClickHouse | 存储成本低，写入吞吐高，时序聚合强 |
| 需要同时支持模糊搜索与长期趋势分析 | Elasticsearch + ClickHouse 混合 | ES 处理热数据检索，CH 处理冷数据聚合 |
| 小团队 / 开发环境 / 日均 Span < 1 亿 | Jaeger 原生 (Badger) | 零运维，快速部署，但不可扩展 |
| 已有 Kafka + Flink 数据管道 | ClickHouse | 流式写入与物化视图天然适配 |
平台工程建议： 在自助查询接口设计初期，将存储层抽象为
SpanStorage 接口，支持动态切换后端。这样即使初期选用 Elasticsearch，后续迁移到 ClickHouse 时只需实现新的适配器，查询 API 无需改动。