批量写入优化、慢查询分析与索引结果缓存引入｜Greptime 双周精选

内容概述

作为一个成长中的开源项目，GreptimeDB 的进展离不开来自全球的社区贡献者们，感谢各位！

最近的更新内容如下：

持续完善 Bulk 写入模式
将慢查询保存到系统表中
引入索引结果缓存

社区贡献者名单

在过去的两周里，GreptimeDB 共合并了 104 个 PR，其中有 2 位独立贡献者，累计 2 个 PR 被成功合并，还有很多待合并的 PR 。

祝贺以下各位在过去 2 周内成为我们最突出的贡献者：

@yinheli db#6128
@zqr10159 dbingesterjava#86

👏 欢迎 @yinheli 作为新的贡献者加入到社区，并成功合并了 PR，还有更多来自其他独立贡献者的 PR 正在等待合并。

衷心感谢我们所有的成员和贡献者！是你们的付出让我们的项目得以成功，也是你们让 GreptimeDB 成为一个更优质的产品。让我们一起努力，建立一个更棒的社区！

PR 亮点

db#6086 Bulk 写入多时间分区

在 Bulk 写入模式中增加了多时间分区的支持。为了发挥向量化操作的性能优势，该 PR 手动实现了 gt_eq && lt 操作，而非直接依赖 Arrow 内核提供的基础操作。据 Benchmark 显示，这个优化使性能提升了 20% 以上。

db#6008 新增 `SlowQueryRecorder`：将慢查询记录到系统表

此前，当系统检测到慢查询时会将其输出到日志中，维护人员需要手动提取日志并转存到其他数据库后才可进行后续分析。本 PR 引入 SlowQueryRecorder 模块，实现慢查询的自动化存储管理，能够直接使用 GreptimeDB 分析慢查询的能力。

以下是慢查询系统表的结构示例：

sql

+------+-----------+---------------------------------------------+-----------+----------------------------+--------------+-------------+---------------------+---------------------+
| cost | threshold | query                                       | is_promql | timestamp                  | promql_range | promql_step | promql_start        | promql_end          |
+------+-----------+---------------------------------------------+-----------+----------------------------+--------------+-------------+---------------------+---------------------+
|    2 |         0 | irate(process_cpu_seconds_total[1h])        |         1 | 2025-05-14 13:59:36.368575 |     86400000 |     3600000 | 2024-11-24 00:00:00 | 2024-11-25 00:00:00 |
|   22 |         0 | SELECT * FROM greptime_private.slow_queries |         0 | 2025-05-14 13:59:44.844201 |            0 |           0 | 1970-01-01 00:00:00 | 1970-01-01 00:00:00 |
+------+-----------+---------------------------------------------+-----------+----------------------------+--------------+-------------+---------------------+---------------------+

db#5981 在 Prometheus Remote Write 使用 Pipeline 引擎

Pipeline 引擎最初专为文本预处理设计。随着 GreptimeDB 拥抱可观测生态，我们发现其强大的数据转换能力同样适用于分布式链路追踪和监控指标数据的预处理（如 Label 的预处理和转换）。本 PR 在 Prometheus Remote Write 流程中集成了 Pipeline 执行引擎。随着 Pipeline 引擎的持续优化，修改指标请求将变得和修改文本请求一样简单直接。

db#6110 引入索引结果缓存

GreptimeDB 已经支持了多种索引类型。本 PR 添加了对索引查询结果的缓存，极大改善了重复查询情况下的性能。

db#6121 TWCS Compaction Picker 优化

TWCS (Time Window Compaction Strategy) Compaction 策略最早通过 db#1851 引入。随着数据库架构的持续演进，现有实现已无法充分适配当前需求。本 PR 提升了数据库架构的适配性，极大地减少了 Compaction 的时间复杂度。

Good First Issue

Issue#6095 支持 `x-greptime-pipeline-name` HTTP Header

OTEL 协议的 HTTP endpoint 支持 x-greptime-pipeline-name Header 来指定 Pipeline 名称，但是 /event/logs 目前并不支持这个 Header。检查并修改其他可以运行 Pipeline 的 HTTP endpoints，使它们都支持通过 HTTP Header 来指定 Pipeline 名称。

难度: 简单

关键词: HTTP，Pipeline

Issue#6105 支持通用的对象存储数据源，例如 azblob，oss 和 gcs

无论 copy from/to table/database 还是 external table 都使用 build_backend 来创建对象存储后端，但当前只支持 S3。我们需要增加对其他对象存储的支持。（由 @yihong0618 在 db#5585 (comment) 中提出）

难度: 简单

关键词: 对象存储

Issue#6188 新增一个 Metadata CLI

我们需要一个 CLI 工具来与 GreptimeDB 的元数据交互，类似 etcdctl 与 etcd 的交互。这会方便我们做一些简单的集群元数据检视和操作，便于对集群的运维和问题排查。

难度: 简单

关键词: Metasrv

批量写入优化、慢查询分析与索引结果缓存引入｜Greptime 双周精选

内容概述 ​

社区贡献者名单 ​

PR 亮点 ​

Good First Issue ​

加入我们的社区

内容概述

社区贡献者名单

PR 亮点

Good First Issue