跳到主要内容
版本：Nightly

常见问题

GreptimeDB 如何处理 metrics、logs 和 traces？​

GreptimeDB 用同一个列式引擎处理 metrics、logs 和 traces，并采用共同的 Tag、Timestamp、Field 列语义。三类信号可以使用不同的物理表、schema、索引、TTL 和写入方式。

所有信号都可以使用 SQL 查询，metrics 还可以使用 PromQL，traces 还提供单独的 Jaeger 兼容查询接口。Flow 可以持续计算源表数据，并把聚合结果物化到 sink table。详见数据模型、日志和 traces。

支持更新数据吗？​

部分支持。对于开启去重的表，写入主键和时间索引相同的数据时，Field 会按表的 merge_mode 合并。主键和时间索引用来标识数据行，不能原地修改。

通过 SQL 建表时，默认的 last_row 保留最后一行；last_non_null 分别保留每个 Field 最后写入的非空值。自动建表可能采用写入协议自己的默认配置。去重只在同一个 Region 内生效。GreptimeDB 允许使用表中的任意列分区，但对于去重表，建议从主键中选择分区列，让主键相同的数据始终落入同一个 Region，从而正确完成去重和合并。详见表分片。

Append-only 表关闭去重，同一主键和时间戳的写入会新增数据行，不会形成更新。详见更新数据和 merge_mode。

支持删除数据吗？​

支持，但表本身需要允许删除。可以用 SQL 删除匹配的数据、清空表，或通过 TTL 自动过期。Append-only 表不支持按行删除。详见删除数据。

可以按表设置 TTL 或保留策略吗？​

可以。TTL 可以设置在 database 或 table 层级，table 自己的设置优先。详见使用 TTL 策略保留数据。

压缩率是多少？​

没有适用于所有数据的固定压缩率。结果取决于表结构宽度、数值分布、主键基数、重复度、SST 格式、索引和具体负载。索引可以加快过滤，但也会增加存储和写入开销。应使用实际数据和留存设置测量，而不是套用一个通用倍数。

一份公开的 Edge benchmark 提供了有明确条件的量级参考：在 Qualcomm SA8155P 上写入 1000 万行 TSBS 数据后，GreptimeDB Edge 占用 87 MB，SQLite 占用 1,686 MB。这个结果只适用于当时测试的 Edge 版本、schema 和配置，不是 GreptimeDB 部署的通用压缩率。详见 GreptimeDB Edge 与 SQLite 对比报告。

表结构和索引的取舍参见表设计指南和索引。

如何解决高基数问题？​

高基数始终有成本：不同主键值越多，metadata、索引、内存和查询的开销都可能增加。GreptimeDB 提供以下控制手段：

  • flat SST 格式减少按序列维护的开销，是新表的默认格式，适合高基数主键。Flat Format 工程文章介绍了 memtable 和 merge path 的设计，并给出了 benchmark 条件。
  • 可以按查询选择性和存储成本配置倒排索引、全文索引或 skipping index，通常不需要为每一列建索引。
  • 不需要更新和删除的不可变记录可以使用 append-only 表，省去去重计算。
  • 集群可以通过表分区把 Region 分布到不同 Datanode，但分区方式和负载分布仍需要合理设计。
  • 只有确实用于分组、去重或过滤的标识，才适合放进主键。

不存在对所有 schema 和部署都成立的统一基数上限。评估时要同时测试预期序列数、写入速率、查询条件和留存周期。详见 sst_format、索引和表设计指南。

支持持续聚合或降采样吗？​

支持。Flow会在新数据行写入源表时持续计算，并把结果物化到 sink table。它可以用于固定窗口聚合和降采样，源数据则按自己的 TTL 保留。

可以把数据存到云上的对象存储吗？​

可以。持久化数据文件可以存入 Amazon S3、Google Cloud Storage、Azure Blob Storage、阿里云 OSS 和支持的 S3 兼容服务。对象存储与 WAL、metadata、本地 cache 的职责不同，需要分别考虑持久性和恢复。详见存储位置和存储选项。

性能对比其他方案怎么样？​

性能取决于具体负载、表结构、索引、留存周期、硬件、对象存储、cache、并发和查询形态。阅读 benchmark 时要同时检查测试条件，并用自己的预期负载验证。

已发布的报告包括：

有灾难恢复方案吗？​

GreptimeDB 提供构建恢复方案所需的组件，但仅使用对象存储并不等于具备完整灾备能力。持久化数据文件、WAL、Metasrv metadata、Region 放置与 failover、部署配置都会影响 RPO 和 RTO。

集群 failover 还依赖正确配置的拓扑和健康的替代 Datanode。对象存储策略之外，还要备份并验证 metadata 和 WAL 的恢复。详见灾备、WAL 概述和存储位置。

支持地理空间计算吗？​

支持。GreptimeDB 提供处理 WKT、Geohash、H3、S2、空间关系、距离和面积的 SQL 函数。这些函数不会创建或隐含数据库级空间索引。详见地理函数。

支持 JSON 数据吗？​

GreptimeDB 提供两种 JSON 列类型：

  • 实验性的 JSON 类型用于存储通用 JSON 值，可以使用 JSON 函数读取和处理。
  • JSON2 从 v1.2 开始提供，目前处于 Beta 阶段。它面向 logs 和其他半结构化数据，以结构化列式形式保存子路径，支持点号路径、json_get 和可选的 type hint。目前 JSON2 只能用于 append-only 表。

两种类型目前都不能为 JSON 子路径配置索引。如果某些稳定属性需要频繁过滤，并需要倒排索引、全文索引或 skipping index，应把它们存入有明确类型的普通列。详见索引。

更多问题？​

部署、迁移、运维和 schema 等问题参见完整的常见问题。