标签
GreptimeDB的Grafana插件已升级至v3.0.3版本，新增Go后端以支持在告警规则中进行SQL宏插值，使得在面板和告警中能够使用一致的查询。
DBeaver Community 26.1.5 已发布，新增了一个专用的 GreptimeDB 驱动程序，使时序数据的连接和管理更加便捷。
一篇深度博文，通过基准测试复现和代码分析，解读 GreptimeDB 中让 Prometheus 读取转换速度提升 10 倍的 Rust 性能 PR。
GreptimeDB v1.2.0-beta.1 已发布，主要特性包括：JSON2 作为结构化列类型、支持原生直方图的 Prometheus Remote Write v2、字典编码的序列键以加快查询速度，以及其他加固和破坏性更改。
GreptimeDB引入了一个语义层，保留了通常会在摄取时丢弃的OTLP元数据（仪器类型、单位、时间性），使AIOps工具和LLM代理能够理解系统拓扑，而无需从列名猜测。
GreptimeDB v1.1 通过单个 ALTER TABLE 语句引入了对现有表的在线重新分区，消除了数据迁移、双写或应用程序变更的需求。它利用共享对象存储和逻辑分片来更新清单和路由，而无需在节点之间移动数据。
本帖子解释了可观测性 2.0，即从预聚合指标转向存储包含所有字段的宽事件，从而在读取时支持即席查询。它强调了 AI 智能体可观测性的紧迫性，以及 GreptimeDB 如何支持这一模型。
GreptimeDB 现已成为 Perses（CNCF 可观测性仪表盘项目）的原生数据源，支持通过 PromQL 查询指标，以及通过 SQL 查询日志、链路追踪和时间序列聚合。
小米智慧工厂用 GreptimeDB 替换了 Loki 进行日志存储，每月处理数十亿行数据，并采用了定制化索引：针对高基数的 trace_id 使用 Bloom 跳跃索引，针对低基数字段使用倒排索引，并对消息体进行全文搜索。
GreptimeDB v1.1 引入了对现有表的在线重新分区、增量 Flow 读取、面向 LLM 的语义层以及稳定性改进。
GreptimeDB v1.1.0 已发布，提供高达97%的PromQL查询加速，整体查询时间降低20-40%，在TSBS扫描密集型查询上性能提升高达4.5倍，并支持对现有表进行在线重分区。
Erxi 在贡献了包括 meta KV 写入保护、flush 原因传播以及 CSV COPY 修复等多项改进后，被欢迎成为 GreptimeDB 的新提交者。
GreptimeDB 1.0 引入了三个用于异常检测的内置SQL窗口函数（Z-Score、MAD、IQR），使得无需外部服务即可直接在SQL中进行异常评分。
GreptimeDB v1.0引入了Pending Rows Batcher，这是一个三阶段流水线，将CPU密集型工作从Datanode的关键路径上移开，使Prometheus远程写入吞吐量从120万提升到217万points/sec，并将Datanode的CPU使用率降低20%。
GreptimeDB v1.0 集成了 DataFusion 的动态过滤下推功能，通过将运行时边界推送到扫描层来加速 TopK 查询，在 50 亿行的 trace 表上将查询时间从 29 秒降低到 0.21 秒。
GreptimeDB 是一个统一的指标、日志和追踪数据库，提供原生 OpenTelemetry 数据接入、SQL/PromQL 查询、对象存储以降低成本，以及边缘到云的部署。
GreptimeDB 的扁平格式查询现在支持在任何列（标签、字段、时间戳）上预过滤，而不仅仅是主键，性能提升高达 4.5 倍。此外，mito2 存储引擎移除了其遗留扫描路径，清理了约 1800 行代码。