跳到主要内容
版本：0.15

常见问题

核心能力​

什么是 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 等众多系统的广泛集成。完整列表请参见集成概述，或从以下开始：

🤝 社区与贡献：

参与社区：

贡献代码：