VICTORIA STACK
Victoria Stack
指标、日志、链路分散在不同存储和工具中
- 指标用 PromQL/MetricsQL，日志用 LogQL，链路单独查询
- 每类信号都有独立 UI 与运维面
- 跨信号关联通常需要在引擎外额外拼接
- 更多组件需要扩容与一致性维护
GREPTIMEDB
GreptimeDB
一个引擎统一摄取、存储与查询
- 统一存储层上支持 SQL + PromQL
- 在同一系统中联合查询指标、日志和链路
- 存算分离 + 原生对象存储
- 无状态计算层独立扩展
Skip to content 
三套系统，三种查询语言。
统一可观测性应是一条工作流。
Victoria Stack 通常由 VictoriaMetrics（指标）、VictoriaLogs（日志）、VictoriaTraces（链路）组成。每个组件在各自信号上都具备不错的性能与成本效率，但整体上仍需要维护多套系统和多种查询语言（PromQL/MetricsQL、LogQL、链路查询）。如果团队希望指标、日志、链路拥有统一摄取与统一查询面，GreptimeDB 提供 SQL + PromQL 的统一可观测性数据库方案。
架构对比
扩展 Victoria Stack 意味着同时扩展多套组件并保持多链路协同。
Victoria Stack
3 套系统
VictoriaMetrics
指标存储 + PromQL
VictoriaLogs
日志摄取 + LogQL
VictoriaTraces
链路摄取 + OTLP/Jaeger
分离的可视化与流程
按信号拆分工作流
GreptimeDB
1 个引擎
统一摄取网关
一个端点接入全信号
无状态计算节点
快速横向扩容
原生对象存储
存算分离架构
- 同一查询体验支持 SQL + PromQL
- 一个引擎统一指标 + 日志 + 链路
- 计算与存储可独立扩展
特性对比
| 特性/方面 | GreptimeDB | Victoria Stack（VictoriaMetrics + VictoriaLogs + VictoriaTraces） |
|---|---|---|
| 数据模型 | 统一可观测性数据库 | 按信号拆分的多套存储 |
| 多模型支持 | 一个数据库引擎统一指标、日志和链路 | 指标、日志、链路由多个组件组合完成 |
| 查询体验 | SQL + PromQL，统一查询面 | 指标用 PromQL/MetricsQL，日志用 LogQL，链路单独查询 |
| 数据摄取协议 | SQL、gRPC、OpenTelemetry 及多类可观测协议统一接入 | 按信号拆分摄取协议与端点 |
| 存储架构 | 存算分离，原生对象存储 | 各组件独立存储（指标/日志/链路） |
| 保留与分层 | 灵活 TTL + 自动分层 | 各组件分别配置保留和清理策略 |
| 运维复杂度 | 单一运维面，组件更少 | 组件更多，需要跨信号保持配置与运行一致 |
| 跨信号关联 | 引擎内原生关联 | 通常需要额外链路或外部工具拼接 |
迁移路径：最快一周可落地
在不重写整套可观测体系的前提下，逐步统一三类信号。
从 Loki 迁移到 GreptimeDB 实现了海量日志数据的高性能大规模查询，提供多云部署灵活性，并显著简化了应用和部署架构。
Stay in the loop
加入我们的社区
获取 Greptime 最新更新，并与其他用户讨论。