@Greptime: Your logs keep growing. Query traffic comes in peaks. Why scale storage and compute together? In 3 minutes: how Greptim…

Your logs keep growing. Query traffic comes in peaks. Why scale storage and compute together?

In 3 minutes: how GreptimeDB separates them with shared object storage in distributed deployments, and reuses data files during repartitioning.

https://t.co/3hCde9iAY8

TL;DR：日志持续增长、查询流量出现峰值时，无需让计算与存储同步扩容——GreptimeDB 通过计算与持久存储分离，让你按查询负载扩计算、按保留需求扩存储。

日志在增长，查询有峰值：为什么要解耦

你的日志在不断增长，而查询流量存在峰值。关键问题是：增加计算资源，是否意味着要把所有历史数据迁移到新机器？

GreptimeDB 的答案是：把计算与持久存储分离。这样你可以根据查询流量调整计算规模，根据保留需求调整存储规模，而不是让两者作为一个整体同步增长。

GreptimeDB 是什么

GreptimeDB 是一个开源可观测性数据库。指标（Metrics）、日志（Logs）和链路追踪（Traces）共享同一个列式引擎，但可以使用独立的表、索引和保留策略。

这种设计的好处是：三种信号共用一个数据库后端，而无需将它们强制归入同一种数据模型。

用 SQL 关联三种信号

当标识符对齐时，你可以用 SQL 查询并关联这些信号——指标、日志、链路追踪可以放在同一个查询里做关联分析。

写入路径与查询能力

数据写入支持：

• Prometheus remote write
• 通过 HTTP 的 OpenTelemetry
• Loki push 端点

这让你在沿用熟悉的采集器的同时，用 SQL 分析已存储的信号，并用 PromQL 查询指标。

需要注意边界：写入兼容性不等于完整的功能对齐——支持 Loki push 并不意味着支持 LogQL。

架构：共享对象存储下的分工

在使用共享对象存储的分布式部署中，各组件职责如下：

热点分区：引用变更而非数据搬迁

区域（Region）是逻辑数据分片，其清单（Manifest）记录了对持久化文件的引用。

在重新分区过程中，规则、文件引用和路由都会发生变化。关键点在于：已有的 SST 文件可以被复用，而不是在节点之间整体复制。这样就避免了仅仅为了调整分区边界而搬迁所有旧文件。

注意：文件本身保持原位，只有引用发生了变化。

这并非零 I/O

刷写（Flush）和压实（Compaction）仍可能产生写入。但这让你可以在不重建整张表的情况下调整分区布局。

手动重新分区的前提条件

手动重新分区需要：

1. 分布式集群
2. 共享对象存储
3. 在 Meta SRV 和每个数据节点上启用垃圾回收（GC）

此外，切换期间写入可能短暂受到影响，因此客户端需要具备重试机制。

企业版功能边界

自动重新分区和自动区域均衡属于企业版功能，受其配置和触发条件限制。

与 ClickHouse 的对比

ClickHouse 提供实时分析以及 ClickStack 可观测性平台，ClickHouse Cloud 同样实现了计算与存储分离。

GreptimeDB 的差异点在于遥测原生的数据库基础：

• 原生写入、SQL 与 PromQL
• 为不同信号模型提供统一后端
• 共享对象存储和手动重新分区包含在开源核心中，可在自有基础设施上运行

这种组合让你能够围绕熟悉的采集路径构建，关联已存储的信号，并分别规划计算能力和数据保留策略。

值得验证的优势

综上，值得验证的优势很清晰：

• 统一后端：支持不同信号模型
• 熟悉的采集路径：Prometheus remote write、OpenTelemetry、Loki push
• 独立于数据保留增长的计算能力

请结合你的写入速率、保留周期和典型查询来验证这一组合。

文档和代码参考见视频简介。接下来，作者将把一套故障排查工作流应用到这个架构中。

Source: @Greptime — 计算与存储分离如何避免为扩容迁移历史数据