为什么选择 GreptimeDB
团队开始评估新的可观测后端，往往是因为多套信号存储、存储扩容或长期分析的运维成本已经难以忽略。GreptimeDB 用同一个列式引擎处理 metrics、logs 和 traces，同时保留清晰的数据模型和部署边界。
GreptimeDB 是什么
GreptimeDB 是开源的可观测性数据库。它用同一个列 式引擎存储和查询 metrics、logs、traces，并提供统一的 SQL 查询层。GreptimeDB 既可以使用本地存储以单机模式运行，也可以组成以对象存储为持久化存储的分布式集群。
GreptimeDB 不是通用事务数据库。它的存储、索引、留存和查询路径面向以追加写入为主的时间索引数据，例如可观测数据和 IoT 数据。
为什么用一个引擎处理三种信号
metrics、logs 和 traces 分散在不同数据库时，每套系统都有自己的容量模型、生命周期策略、查询方式和故障边界。故障排查要么搬运数据，要么在几套系统之间来回查询。
GreptimeDB 用同一个列式引擎处理三类信号，并采用共同的 Tag、Timestamp、Field 列语义：
- metrics、logs、traces 共用一套存储和生命周期管理机制；
- 所有信号都可以使用 SQL 查询，metrics 还可以使用 PromQL；
- Flow用于持续聚合，并把派生结果物化到 sink table；
- instrumentation 记录了共同标识时，可以通过 SQL 关联不同信号。
这里的“统一”指引擎、存储和查询层，不要求 metrics、logs、traces 使用同一张表、同一套 schema，也不要求采用宽事件模型。
一个列式引擎，不同的表
减少系统数量，不等于把不同信号硬塞进同一种 schema。指标点、日志、span 和宽事件，其访问方式和留存要求并不相同。
GreptimeDB 允许每类 workload 使用适合自己的表：
- metrics 通常用主键列保存 labels，并使用 PromQL 查询；
- logs 常用 append-only 表，并根据查询方式选择全文索引或倒排索引；
- traces 保留 trace 和 span 标识，可以使用 SQL 或 Jaeger 兼容接口查询；
- 事后分析需要更多上下文时，可以采用宽事件，并承担相应的存储成本。
这些表可以分别配置 schema、索引、TTL、compaction 选项和存储后端。具体机制参见数据模型和存储位置。
实时监控与历史分析，共用一套系统
故障处置需要快速查询近期数据，趋势分析、容量评估和事后排查则可能扫描几周甚至几个月的数据。如果分别使用监控后端和分析数据库，就要多维护一条写入链路、一份数据副本和一套系统。
在使用对象存储的分布式部署中，GreptimeDB 用同一个引擎、同一套存储与查询基础处理这两类 workload。近期数据可以通过内存和本地 cache 加速，持久化数据则保存在对象存储中，供更长时间范围的查询使用。长期分析不需要另建分析数据库和数据复制链路。
对象存储与独立扩展
持久化文件绑定在计算节点上时，增加容量往往伴随数据迁移、本地磁盘再均衡，或者存储与计算一起扩容。留存数据越多，集群调整越重。
分布式 GreptimeDB 使用共享对象存储时，持久化数据文件可以放在 Amazon S3、Google Cloud Storage、Azure Blob Storage 等服务中。Datanode 负责写入、compaction 和查询，本地磁盘可以缓存远端数据。计算容量与对象存储容量可以分别调整，不必在 Datanode 之间复制全部持久化文件。具体参见架构和存储位置。
协议和查询边界
迁移成本常常不在数据库部署本身，而在采集端、仪表盘和客户端代码。GreptimeDB 支持通过多种现有协议写入数据：
- Prometheus Remote Write 写入 metrics；
- OpenTelemetry OTLP/HTTP 写入 metrics、logs 和 traces；
- Loki Push API 写入 logs；
- Elasticsearch Bulk API 写入文档；
- InfluxDB Line Protocol、MySQL、PostgreSQL，以及 GreptimeDB 的 gRPC 和 HTTP API。
这些集成只覆盖对应的写入或客户端接口，不代表完整兼容原系统。Loki 写入不包含 LogQL；开源版 Elasticsearch 集成支持 Bulk API，不等于完整支持 Query DSL。所有信号都可以使用 SQL 查询，metrics 还可以使用 PromQL，traces 还可以使用 Jaeger 兼容查询接口。规划迁移前，应先核对各协议页面列出的边界。
开源版与 Enterprise 的边界
评估扩展能力、可用性和运维成本时，需要先分清版本边界。开源版包括单机和集群部署、对象存储、SQL、PromQL、Flow、索引，以及上面列出的写入接口。
GreptimeDB Enterprise 另行提供读副本、通过 Datanode group 隔离 workload、自动 Region 均衡与重分区、RBAC、LDAP 集成、审计日志和企业灾备方案等能力。概念文档提到开源集群时，不默认包含这些功能。
可以按需调整的配置
共用一套系统改变的是运维对象，不会让不同 workload 变得完全相同。可以通过下面几类配置分别调整：
- 表设计：选择 schema 、主键、索引、append-only 模式和分区方式；通过 TTL控制留存周期，并按 workload 调整 compaction。
- 容量规划：根据写入量以及近期查询与历史查询的比例，规划计算资源、内存和本地 cache；再结合性能调优指南中的运行指标调整 cache 和查询配置。
- 持久性与恢复：根据 RPO 和 RTO 选择 WAL 模式、metadata 存储、对象存储策略以及备份恢复流程。
- Region 运维：为分布式部署规划分片、手动 Region 迁移和 failover。Enterprise 还可以使用 Datanode group隔离 workload，并通过 Region Balancer自动均衡 Region。
具体配置取决于 workload 和部署方式，不存在适用于所有信号的统一预设。
生产用户公开的数据
下面的数据来自特定 workload 和配置下的公开案例：
- OceanBase Cloud 运行着 80+ GreptimeDB 集群，保存 300 TB 日志与 SQL 审计数据，留存周期为 7 天，持续写入吞吐约 1 GB/s。从 Loki 迁移后，整体日志存储成本下降 60%+。
- 得物使用 Flow 从明细事件持续维护 10 秒、1 分钟和 10 分钟粒度的聚合结果。公开案例显示，预聚合将 P99 查询延迟从秒级降到毫秒级。
实际结果取决于 schema、索引、留存周期、硬件、对象存储价格、cache 配置和查询 workload。规划容量时，应结合带测试条件的性能报告。
用 agent 排查故障的实测结果
Agent RCA Bench 完成了 504 次端到端排查——6 个模型、14 个故障、每组重复两次——覆盖三种接口：Prometheus、Loki、Tempo 各自的原生查询 API；GreptimeDB 表之上的只读 SQL 与 PromQL；以及在此基础上再加一层语义层。
与三个独立后端相比，GreptimeDB 接口的结果是：
- 错误诊断少 40%——168 次排查中错 38 次，三个后端错 63 次；正确根因 130 次对 105 次。
- 读取的输入 token 少 48%— —1.998 亿对 3.818 亿。6 个模型读取的 token 都更少，其中 5 个准确率也更高。
- 整体成本低约 45%——全部排查的估算费用 98–101 美元，三个后端为 184–187 美元。
这组对比同时改变了存储、查询语言和工具接口，衡量的是接口组合，不是单独的存储引擎。完整报告公开了测量协议、逐次运行数据和每项结论的适用范围。
和现有方案比较
实际选型通常是在现有可观测系统之间比较：指标侧的 Prometheus、Mimir、Thanos，日志与链路侧的 Loki、Tempo、Elasticsearch，以及 VictoriaMetrics、ClickHouse 或 ClickStack。
GreptimeDB 对比页面按产品列出了架构、协议与查询差异、迁移路径和基准测试条件。应从当前正在使用的系统进入对应页面，而不是只看一张脱离版本和 workload 的功能表。