Skip to content

GreptimeDB 与现有可观测后端的对比

  • GreptimeDB 使用同一个列式存储引擎处理指标、日志和链路,并以对象存储为主存储。

  • 各对比页介绍架构差异、迁移路径和基准测试结果。

Comparison banner diagram

真正要判断的,不是哪一个指标工具更好。
而是指标、日志和链路是否还需要三套后端。

三套系统

三个后端,三套扩展模型

  • 写入和留存要按信号分别配置
  • 每个后端的扩展方式和故障模型各不相同
  • 跨信号排查需要使用多种查询语言
  • 规模扩大后,实时监控和历史分析需要分别规划容量
  • 要部署、升级、加固和监控的组件更多
VS
一个引擎 →

一个引擎,一套数据模型

  • 指标、日志和链路采用统一的表模型:Tag 列、Timestamp 列和 Field 列
  • 保留原始事件,可在查询时按需派生指标,也可通过 Flow 持续聚合并物化指标
  • 当数据包含共同标识符时,可以通过一条 SQL 关联不同信号
  • 同一个引擎同时处理近期数据和长期留存,无需另建分析系统
  • 通过压缩和对象存储,存储成本最高可降至原来的 1/50

深度对比

每个页面都包含架构差异、迁移路径与真实基准数据。

指标

Prometheus / Mimir / Thanos

为了扩展一个指标系统,要维护 Distributor + Ingester + Compactor + Store-Gateway + Querier?

GREPTIMEDB ADVANTAGES

  • 原生存算分离,无需 Thanos Sidecar
  • PromQL + SQL,同时替代指标数仓能力
  • 兼容 Remote Write,30 分钟重定向即可开始
查看深度对比

日志

Grafana Loki

Loki 只索引标签。每次日志正文查询都是暴力扫描——规模大了就超时。

GREPTIMEDB ADVANTAGES

  • 全文索引,不再暴力扫描日志正文
  • 基准测试中关键字搜索快 40–80 倍
  • 生产环境存储成本下降 60%+(OceanBase Cloud 实测)
查看深度对比

链路 / 日志

Elasticsearch

倒排索引为文本检索而优化。用于链路存储时额外开销显著——在我们的链路 benchmark 中存储膨胀最高达 45 倍。

GREPTIMEDB ADVANTAGES

  • 列存 + 对象存储——为高效检索链路和日志提供灵活索引
  • 兼容 Jaeger UI,无需重写仪表盘
  • Apache 2.0 许可证(ES 为 ELv2 / SSPL / AGPLv3)
查看深度对比

指标 / 日志 / 链路

Victoria Stack

VictoriaMetrics + VictoriaLogs + VictoriaTraces——每个信号一个独立产品,三套系统各自运维。

GREPTIMEDB ADVANTAGES

  • 一个引擎,一条 SQL 跨信号 JOIN 查询
  • 沿用现有协议端点,背后只有一个存储后端
  • 对象存储优先 vs 本地磁盘优先架构
查看深度对比

分析 / OLAP

ClickHouse

分析能力很强。可观测性通过 ClickStack 运行,与 OLAP 核心是独立的层。

GREPTIMEDB ADVANTAGES

  • PromQL、OTLP、Jaeger 在同一个二进制
  • 为可观测性设计——一套栈同时做告警和长期分析
  • 原生对象存储,弹性扩缩;自动重分区由企业版提供
查看深度对比

渐进迁移,而不是一次性重构

先从最痛的信号开始。写入重定向分钟级,完整迁移取决于协议兼容性。

阅读迁移指南

重定向写入

文档

将写入端点(Remote Write、OTLP、Loki Push API)指向 GreptimeDB。指标、日志、链路都适用。零停机。

~30 分钟

迁移仪表盘和查询

文档

PromQL / Jaeger 兼容栈——切换数据源,小时级。其他栈——用内置仪表盘或迁移查询,天到周级。

小时到周级

回填并下线旧系统

导出历史数据批量导入 GreptimeDB。验证后逐步下线旧系统。

天到周级