跳到主要内容
版本:Nightly

常见问题

核心能力

什么是 GreptimeDB?

GreptimeDB 是一个开源、云原生的统一可观测性数据库,旨在在单一系统中存储和分析 metrics、logs 和 traces。基于 Rust 构建以实现高性能,它提供:

  • 高达 50 倍的运营和存储成本降低
  • 在 PB 级数据集上实现亚秒级查询响应
  • 原生 OpenTelemetry 支持
  • SQL、PromQL 和流处理能力
  • 计算存储分离,实现灵活扩展

GreptimeDB 的性能与其他解决方案相比如何?

GreptimeDB 在可观测性工作负载中提供卓越性能:

写入性能

  • 比 Elasticsearch 快 2-4.7倍(高达 470% 吞吐量)
  • 比 Loki 快 1.5倍(121k vs 78k rows/s)
  • 比 InfluxDB 快 2倍(250k-360k rows/s)
  • 媲美 ClickHouse(达到 111% 吞吐量)

查询性能

  • 日志查询比 Loki 快 40-80倍
  • 重复查询快 500倍(缓存优化)
  • 复杂时序查询比 InfluxDB 快 2-11倍
  • 与 ClickHouse 在不同查询模式下性能相当

存储与成本效率

  • 存储占用比 Elasticsearch 少 87%(仅需 12.7%)
  • 比 ClickHouse 节省 50% 存储
  • 比 Loki 节省 50% 存储(3.03GB vs 6.59GB 压缩后)
  • 运营成本比传统架构降低 50倍

资源优化

  • CPU 使用率减少 40%
  • 在测试数据库中内存消耗最低
  • 对象存储(S3/GCS)上性能一致
  • 卓越的高基数数据处理

独特优势

  • 单一数据库处理 metrics、logs 和 traces
  • 原生云原生架构
  • 水平扩展能力(处理 11.5亿+ 行数据)
  • 原生全文搜索和索引

基准测试报告:vs InfluxDB | vs Loki | 日志基准测试

GreptimeDB 如何处理 metrics、logs 和 traces?

GreptimeDB 设计为统一可观测性数据库,原生支持三种遥测数据类型:

  • Metrics:完全兼容 Prometheus,支持 PromQL
  • Logs:全文索引、Loki 协议支持和高效压缩
  • Traces:实验性 OpenTelemetry trace 存储,支持可扩展查询

这种统一方法消除了数据孤岛,无需复杂的数据管道即可实现跨信号关联。

详细文档:

GreptimeDB 的主要应用场景是什么?

GreptimeDB 擅长于:

  • 统一可观测性:用单一数据库替代复杂的监控堆栈
  • 边缘和云数据管理:跨环境无缝数据同步
  • IoT 和汽车:高效处理大量传感器数据
  • AI/LLM 监控:跟踪模型性能和行为
  • 实时分析:在 PB 级数据集上实现亚秒级查询

架构与性能

GreptimeDB 能否替代我的 Prometheus 设置?

是的,GreptimeDB 提供:

  • 原生 PromQL 支持,兼容性接近 100%
  • Prometheus remote write 协议支持
  • 高效处理高基数 metrics
  • 无需降采样的长期存储
  • 比传统 Prometheus+Thanos 堆栈更高的资源效率

GreptimeDB 提供哪些索引能力?

GreptimeDB 提供丰富的索引选项:

  • 倒排索引:标签列的快速查找
  • 全文索引:高效日志搜索
  • 跳跃索引:加速范围查询
  • 向量索引:支持 AI/ML 工作负载

这些索引即使在 PB 级数据集上也能实现亚秒级查询。

配置详情请参见索引管理

GreptimeDB 如何实现成本效益?

GreptimeDB 通过以下方式降低成本:

  • 列式存储:卓越的压缩比
  • 计算存储分离:独立扩展资源
  • 高效基数管理:处理高基数数据而不发生爆炸
  • 统一平台:消除对多个专用数据库的需求

结果:比传统堆栈降低高达 50 倍的运营和存储成本。

什么使 GreptimeDB 成为云原生?

GreptimeDB 专为 Kubernetes 构建:

  • 分解架构:分离计算和存储层
  • 弹性扩展:根据工作负载添加/删除节点
  • 多云支持:无缝运行在 AWS、GCP、Azure
  • Kubernetes operators:简化部署和管理
  • 对象存储后端:使用 S3、GCS 或 Azure Blob 进行数据持久化

Kubernetes 部署详情请参见 Kubernetes 部署指南

GreptimeDB 支持无 schema 数据摄入吗?

是的,GreptimeDB 在使用以下协议时支持自动 schema 创建:

  • gRPC 协议
  • InfluxDB Line Protocol
  • OpenTSDB 协议
  • Prometheus Remote Write
  • OpenTelemetry 协议
  • Loki 协议(日志数据)
  • Elasticsearch 兼容 API(日志数据)

表和列在首次写入时自动创建,无需手动 schema 管理。

集成与兼容性

GreptimeDB 如何与现有工具和系统集成?

协议支持

  • 数据写入:OpenTelemetry、Prometheus Remote Write、InfluxDB Line、Loki、Elasticsearch、gRPC(参见协议概述
  • 数据查询:MySQL、PostgreSQL 协议兼容
  • 查询语言:SQL、PromQL

可视化与监控

数据管道集成

  • OpenTelemetry:原生 OTLP 摄入,无转换层,保留所有语义约定
  • 数据收集:Vector、Fluent Bit、Telegraf、Kafka
  • 实时流处理:直接从 Kafka、Vector 等系统接收数据

SDK 和客户端库

如何从其他数据库迁移到 GreptimeDB?

GreptimeDB 为流行数据库提供迁移指南:

  • 从 ClickHouse:表结构和数据迁移
  • 从 InfluxDB:Line protocol 和数据迁移
  • 从 Prometheus:Remote write 和历史数据迁移
  • 从 MySQL/PostgreSQL:基于 SQL 的迁移

详细迁移说明请参见迁移概述

GreptimeDB 提供哪些灾备选项?

GreptimeDB 提供多种灾备策略以满足不同的可用性需求:

  • 单机灾备方案:使用远程 WAL 和对象存储,可实现 RPO=0 和分钟级 RTO,适合小规模场景
  • Region 故障转移:个别区域的自动故障转移,停机时间最短
  • 双机热备(企业版):节点间同步请求复制,提供高可用性
  • 跨区域单集群:跨越三个区域,实现零 RPO 和区域级容错
  • 备份与恢复:定期数据备份,可根据备份频率配置 RPO

根据您的可用性需求、部署规模和成本考虑选择合适的解决方案。详细指导请参见灾难恢复概述

数据管理与处理

GreptimeDB 如何处理数据生命周期?

保留策略

  • 数据库级和表级 TTL 设置
  • 无需手动清理的自动数据过期
  • 通过 TTL 文档配置

数据导出

GreptimeDB 如何处理高基数和实时处理?

高基数管理

  • 高级索引策略防止基数爆炸
  • 具有智能压缩的列式存储
  • 带数据修剪的分布式查询执行
  • 高效处理数百万唯一时间序列

了解更多索引信息:索引管理

实时处理

  • Flow Engine:实时流数据处理系统,对流式数据进行连续增量计算,自动更新结果表
  • Pipeline:实时数据解析转换机制,通过可配置处理器对各种入库数据进行字段提取和数据类型转换
  • 输出表:持久化处理结果用于分析

GreptimeDB 的可扩展性特征是什么?

扩展限制

  • 表或列数量无严格限制
  • 数百个表的性能影响最小
  • 性能随主键设计而非表数量扩展
  • 列式存储确保高效的部分读取

分区与分布

  • region 内基于时间的自动组织
  • 通过 PARTITION 子句进行手动分布式分片(参见表分片指南
  • 计划未来版本的自动 region 拆分
  • 无需配置的动态分区(企业版功能)

核心扩展性功能

  • 多层缓存:写入缓存(磁盘支持)和读取缓存(LRU 策略)优化性能
  • 对象存储后端:通过 S3/GCS/Azure Blob 实现几乎无限存储
  • 异步 WAL:高效的预写日志,支持可选的按表控制
  • 分布式查询执行:多节点协调处理大型数据集
  • 手动压缩:通过管理命令提供

企业级扩展功能

  • 高级分区和自动重新平衡
  • 增强的多租户和隔离功能
  • 企业级监控和管理工具

架构详情请参见存储架构博客

GreptimeDB 的设计权衡是什么?

GreptimeDB 针对可观测性工作负载进行了优化,具有以下设计限制:

  • 无 ACID 事务:优先考虑高吞吐量写入而非事务一致性
  • 有限删除操作:为追加重的可观测性数据设计
  • 时序数据专注:针对 IoT、metrics、logs 和 traces 而非通用 OLTP 进行优化
  • 简化连接:针对时序查询而非复杂关系操作进行优化

部署与运维

GreptimeDB 部署和运维指南

部署选项

集群部署(生产环境)

  • 最少 3 个节点实现高可用性
  • 服务架构:metasrv、frontend、datanode(可同节点或分离部署)
  • 存储后端:S3、GCS、Azure Blob(生产)或本地存储(测试)
  • 元数据存储:MySQL/PostgreSQL 后端支持 metasrv
  • 参见容量规划指南

边缘与单机部署

  • Android ARM64、Raspberry Pi 等受限环境
  • 单节点模式适用于开发测试和 IoT 场景
  • 高效资源使用,支持边缘计算

数据分布策略

  • 当前:通过 PARTITION 子句手动分区(参见表分片指南),region 内自动时间组织,支持手动 region 迁移进行负载均衡(参见Region 迁移指南
  • 自动 region 故障转移容灾(参见Region 故障转移
  • 路线图:自动 region 拆分、动态负载均衡

监控与运维

GreptimeDB 提供全面的监控能力,包括指标收集、健康检查和可观测性集成。详细的监控设置和故障排除指南请参见监控概述

部署和管理详情:部署与管理概述

开源版 vs 企业版 vs 云版本

GreptimeDB 各版本的区别是什么?

开源版本

  • 高性能写入和查询能力
  • 集群部署和基础读写分离
  • 多协议支持(OpenTelemetry、Prometheus、InfluxDB 等)
  • 基础访问控制和加密
  • 基础性能诊断
  • 社区支持

企业版本(包含所有开源版功能,另增加):

  • 基于成本的查询优化器,提升性能
  • 高级读写分离和双活灾备(参见双机热备灾备方案
  • 自动扩展、索引和负载均衡
  • 分层缓存和企业级管理控制台
  • 企业授权(RBAC/LDAP 集成)
  • 增强的安全和审计功能
  • 一对一技术支持和 7x24 服务响应
  • 专业定制服务

GreptimeCloud(全托管,包含所有企业版功能,另增加):

  • Serverless 自动扩展,按用量付费
  • 全托管部署,无缝升级
  • 独立资源池和网络隔离
  • 可配置读写容量和无限存储
  • 具有 Prometheus 工作台的高级仪表板
  • SLA 保证和自动灾难恢复

详细对比请参见价格与功能

有哪些安全功能可用?

开源版本

  • 基本用户名/密码身份验证
  • 连接的 TLS/SSL 支持

企业版/云版本

  • 基于角色的访问控制(RBAC)
  • 团队管理和 API 密钥
  • 静态数据加密
  • 合规审计日志

技术细节

GreptimeDB 如何扩展 Apache DataFusion?

GreptimeDB 基于 DataFusion 构建:

  • 查询语言:原生 PromQL 与 SQL 并存
  • 分布式执行:多节点查询协调
  • 自定义函数:时序特定的 UDF/UDAF
  • 优化:针对可观测性工作负载的规则
  • 计数器处理:在 rate()delta() 函数中自动重置检测

自定义函数开发:函数文档

GreptimeDB 和 InfluxDB 的区别是什么?

主要区别:

  • 开源策略:GreptimeDB 的整个分布式系统完全开源
  • 架构:针对可观测性工作负载优化的基于 region 的设计
  • 查询语言:SQL + PromQL vs InfluxQL + SQL
  • 统一模型:在一个系统中原生支持 metrics、logs 和 traces
  • 存储:具有专用优化的可插拔引擎
  • 云原生:为 Kubernetes 构建,具有分解的计算/存储(参见 Kubernetes 部署指南

详细比较请参见 GreptimeDB vs InfluxDB。更多产品比较(如 vs. ClickHouse、Loki 等)可在官网的资源菜单中找到。

GreptimeDB 的存储引擎如何工作?

LSM-Tree 架构

  • 基于日志结构合并树(LSMT)设计
  • WAL 可以使用本地磁盘或分布式服务(如 Kafka)通过 Log Store API
  • SST 文件刷写到对象存储(S3/GCS)或本地磁盘
  • 面向云原生环境设计,以对象存储为主要后端
  • 使用 TWCS(时间窗口压缩策略)优化时序工作负载

性能考量

  • 时间戳:日期时间格式(yyyy-MM-dd HH:mm:ss)无性能影响
  • 压缩:仅测量数据目录;WAL 循环重用
  • Append Only 表:建议使用,对写入和查询性能更友好,尤其适合日志场景
  • Flow Engine:目前基于 SQL;PromQL 支持正在评估中

特定用例的最佳实践是什么?

网络监控(如数千个网卡):

  • 使用 Flow 表进行连续聚合
  • 通过 Flow Engine 手动降采样进行数据缩减
  • 输出到常规表进行长期存储

日志分析

  • 使用 Append Only 表获得更好的写入和查询性能
  • 在频繁查询的字段上创建索引(索引管理
  • 存储效率:ClickHouse 的 50%,Elasticsearch 的 12.7%

表设计与性能

入门指南

如何开始使用 GreptimeDB?

📚 学习资源

文档与指南

性能基准

🚀 快速上手路径

  1. 云端体验GreptimeCloud 免费版 - 无需安装即可试用
  2. 本地部署:按照安装指南自托管部署
  3. 集成现有系统:GreptimeDB 支持与 Prometheus、Vector、Kafka、Telegraf、EMQX、Metabase 等众多系统的广泛集成。完整列表请参见集成概述,或从以下开始:

🤝 社区与贡献

参与社区

贡献代码