ClickHouse 查询很快。
但可观测性需要的不仅仅是查询引擎。
ClickHouse 是高性能列式 OLAP 数据库，时间只是另一个维度——不是存储的组织原则。ClickStack 增加了 OTLP 摄入，ClickHouse 有早期实验性 PromQL 支持，但这些都是在 OLAP 核心之上的附加功能。用 ClickHouse 做可观测性通常需要缓冲中间件 + 摄入 worker + 转换管道。点击这里阅读日志基准报告。
挑战者
OLAP 引擎——可观测性通过 ClickStack 运行，是独立的层
GreptimeDB
PromQL、OTLP、Jaeger 在同一个二进制
ClickHouse 以 OLAP 为核心。可观测性通过 ClickStack 运行，是独立的层。
4-8 个组件
摄取 + 转换
存储 + 计算
查询优化
仪表盘 + 告警适配
1 DATABASE
查询 + 摄取网关
原生对象存储
| 维度 | GreptimeDB | ClickHouse |
|---|---|---|
| 查询语言 | SQL + PromQL（双语原生） | SQL 为主，早期实验性 PromQL 支持 |
| 数据类型 | 指标 + 日志 + 链路在一个数据库 | OLAP 分析数据；可观测性通过 ClickStack |
| PromQL 支持 | 原生 PromQL 查询引擎 | 实验性（仅支持 rate/delta/increase 等基础函数） |
| OpenTelemetry | 原生 OTLP（全信号） | 通过 ClickStack 摄入 OTLP（与核心 OLAP 引擎分离） |
| 链路支持 | 原生 Jaeger Query API | 通过 ClickStack |
| 存储设计 | 以时间戳为核心的布局，针对时序访问优化 | 时间只是另一列；通用 OLAP 布局 |
| Schema 演进 | 动态——新属性自动建列 | 需要 ALTER TABLE 或 schema 迁移 |
| 存储格式 | Apache Parquet（列式，高压缩） | MergeTree 引擎系列（列式） |
| 日志存储效率 | 1.3GB（13% 压缩率） | 2.6GB（26% 压缩率）——大 2 倍 |
| 存储后端 | 原生对象存储（S3、OSS、GCS） | 本地磁盘为主，冷存储到 S3 |
| 摄入管道 | SDK → 原生 OTLP 端点 → 数据库（无中间件） | 通常需要缓冲（Redis/Kafka）+ 摄入 worker |
| 扩展模型 | 存算分离，无状态节点 | 无共享分片，有状态副本 |
| 持续聚合 | 内置 SQL + Flow 流计算引擎 | Materialized Views + Aggregating MergeTree |
| 许可证 | Apache 2.0 | Apache 2.0 |
| 集成成本 | 开箱即用的可观测性方案 | ClickStack + 配置 |
存储对比来自日志基准测试，实际效果因负载和配置而异。
Stay in the loop
获取 Greptime 最新更新，并与其他用户讨论。
