ClickHouse 查询很快。
但可观测性需要的不仅仅是查询引擎。
ClickHouse 是高性能列式 OLAP 数据库——通用分析引擎，并非专为可观测性打造。ClickStack 增加了 OTLP 摄入，ClickHouse 有早期实验性 PromQL 支持，但这些都是在 OLAP 核心之上的附加功能。在 ClickHouse 上做可观测性，通常会在数据库前面加一层缓冲、摄入 worker 和转换步骤，指标、日志、链路由不同部件拼装。GreptimeDB 是为可观测性设计的数据库，原生跑在对象存储上，近实时告警和长期分析都在同一套栈里完成。点击这里阅读日志基准报告。
挑战者
OLAP 引擎——可观测性通过 ClickStack 运行，是独立的层
时间只是另一列——存储布局不针对可观测性负载优化
可观测性摄入通常会加一层缓冲（Kafka/Redis）+ worker
早期实验性 PromQL（功能有限）；ClickStack OTLP 与 OLAP 核心分离
在日志基准测试中日志存储大 50%（2.6GB vs 1.3GB）
GreptimeDB
PromQL、OTLP、Jaeger 在同一个二进制
以时间戳为核心的存储布局——从底层为可观测性设计
原生 OTLP 端点——SDK 直写，无需缓冲层
动态 schema——新 span 属性自动建列，无需迁移
在日志基准测试中日志存储低 50%，压缩率更优
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 端点 → 数据库（无需缓冲层） | 通常在前面加一层缓冲（Kafka/Redis）+ worker |
| 高基数写入 | 写入吞吐和落盘大小随时序基数增长基本保持平稳（基准测试） | 高基数指标需要谨慎设计主键和分区 |
| 扩展模型 | 存算分离；region 随数据增长自动再平衡与重分区 | 无共享分片；分片数与分片键需前置决定，重分片需手动 |
| 复制与高可用 | 对象存储上共享一份副本，高可用靠元数据与 region leadership | 每个副本各存一份全量（zero-copy 复制为实验性）；完全存算分离的 SharedMergeTree 仅 ClickHouse Cloud 提供 |
| 持续聚合 | 内置 SQL + Flow 流计算引擎 | Materialized Views + Aggregating MergeTree |
| 许可证 | Apache 2.0 | Apache 2.0 |
| 集成成本 | 开箱即用的可观测性方案 | ClickStack + 配置 |
存储对比来自日志基准测试，实际效果因负载和配置而异。
Stay in the loop
获取 Greptime 最新更新，并与其他用户讨论。
