常见问题
核心能力
什么是 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
可视化与监控:
- Grafana:Grafana 集成(含官方插件)+ MySQL/PostgreSQL 数据源支持
- 原生 PromQL:直接支持 Prometheus 风格查询和仪表板
- 任何 SQL 工具:通过 MySQL/PostgreSQL 协议兼容
数据管道集成:
- OpenTelemetry:原生 OTLP 摄入,无转换层,保留所有语义约定
- 数据收集:Vector、Fluent Bit、Telegraf、Kafka
- 实时流处理:直接从 Kafka、Vector 等系统接收数据
SDK 和客户端库:
- Go:greptimedb-ingester-go
- Java:greptimedb-ingester-java
- Rust:greptimedb-ingester-rust
- Erlang:greptimedb-ingester-erl
- Python:通过标准 SQL 驱动程序(MySQL/PostgreSQL 兼容)
如何从其他数据库迁移到 GreptimeDB?
GreptimeDB 为流行数据库提供迁移指南:
- 从 ClickHouse:表结构和数据迁移
- 从 InfluxDB:Line protocol 和数据迁移
- 从 Prometheus:Remote write 和历史数据迁移
- 从 MySQL/PostgreSQL:基于 SQL 的迁移
详细迁移说明请参见迁移概述。
GreptimeDB 提供哪些灾备选项?
GreptimeDB 提供多种灾备策略以满足不同的可用性需求:
- 单机灾备方案:使用远程 WAL 和对象存储,可实现 RPO=0 和分钟级 RTO,适合小规模场景
- Region 故障转移:个别区域的自动故障转移,停机时间最短
- 双机热备(企业版):节点间同步请求复制,提供高可用性
- 跨区域单集群:跨越三个区域,实现零 RPO 和区域级容错
- 备份与恢复:定期数据备份,可根据备份频率配置 RPO
根据您的可用性需求、部署规模和成本考虑选择合适的解决方案。详细指导请参见灾难恢复概述。
数据管理与处理
GreptimeDB 如何处理数据生命周期?
保留策略:
- 数据库级和表级 TTL 设置
- 无需手动清理的自动数据过期
- 通过 TTL 文档配置
数据导出:
- 用于 S3、本地文件的
COPY TO
命令 - 通过任何兼容客户端的标准 SQL 查询
- 备份和灾难恢复的导出功能:备份与恢复数据
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?
📚 学习资源:
文档与指南:
性能基准:
🚀 快速上手路径:
- 云端体验:GreptimeCloud 免费版 - 无需安装即可试用
- 本地部署:按照安装指南自托管部署
- 集成现有系统:GreptimeDB 支持与 Prometheus、Vector、Kafka、Telegraf、EMQX、Metabase 等众多系统的广泛集成。完整列表请参见集成概述,或从以下开始:
- OpenTelemetry 集成
- Prometheus 迁移
- Grafana 仪表板配置
🤝 社区与贡献:
参与社区:
- Slack 频道 - 与用户和开发者交流
- GitHub Discussions - 技术讨论
贡献代码:
- 贡献指南 - 开发环境搭建
- 适合新手的 Issue - 第一次贡献
- 文档改进 - 帮助完善中英文文档