挑战者
Elasticsearch
搜索优先架构,可观测性存储开销是结构性问题
- 默认索引所有字段——高基数 trace/span ID 导致存储膨胀最高 45 倍
- 在[基准测试](/blogs/2025-04-17-elasticsearch-greptimedb-comparison)中日志写入 39K TPS,GreptimeDB 达到 185K TPS(4.7 倍)
- JVM 调优、分片管理与 ILM 增加运维负担
倒排索引擅长搜索。
但也让可观测性存储膨胀了。
Elasticsearch 是基于 Apache Lucene 的分布式搜索与分析引擎,广泛用于日志分析、APM 和企业搜索。它的倒排索引在全文搜索上表现出色,但在可观测性负载下——尤其是链路和大规模日志——存储开销成了结构性问题:JSON 文档模型 + 倒排索引 + 多索引副本导致数据显著膨胀。点击这里阅读完整的日志基准报告。
挑战者
搜索优先架构,可观测性存储开销是结构性问题
GreptimeDB
列存 + 对象存储,面向可观测性长期保留
为什么 Elasticsearch 集群在规模增长后更复杂,而 GreptimeDB 路径更直接。
5-9 个组件
采集 + 转换
索引 + 存储
集群路由
保留策略 + 归档
1 DATABASE
查询 + 摄取网关
原生对象存储
| 维度 | GreptimeDB | Elasticsearch |
|---|---|---|
| 存储格式 | Apache Parquet(列式,高压缩) | Lucene 段 + 倒排索引 |
| 索引策略 | 按字段选择:倒排、跳跃索引、布隆过滤器全文、向量索引 | 默认索引所有字段——高基数数据存储开销大 |
| 存储效率 | 日志约 ES 的 1/10;链路场景最高降 45 倍 | JSON + 倒排索引 + 副本导致存储膨胀 |
| 查询语言 | SQL + PromQL(双接口) | 查询 DSL(JSON)、Elasticsearch SQL(内置) |
| 数据类型 | 指标 + 日志 + 链路在一个数据库 | 主要用于文档(指标需要独立系统) |
| 写入吞吐 | 185K TPS(结构化日志) | 39K TPS(结构化日志,慢 4.7 倍) |
| 存储后端 | 原生对象存储(S3、OSS、GCS) | 本地磁盘,冷数据快照到 S3 |
| 扩展模型 | 存算分离,无状态节点 | 主-数据节点集群,分片管理 |
| 链路兼容 | Jaeger Query API 兼容,约一周迁移 | 原生 Jaeger/ES 后端 |
| OpenTelemetry | 原生 OTLP(全信号) | 通过 Elastic APM / Observability 栈 |
| 许可证 | Apache 2.0 | ELv2 / SSPL / AGPLv3(2024 年起三重许可) |
| 操作复杂度 | 单一可观测性系统 | ELK/EEK 栈:多组件管理 |
日志性能数据来自基准测试。链路存储对比基于生产迁移案例。实际效果因负载而异。
Stay in the loop
获取 Greptime 最新更新,并与其他用户讨论。