GreptimeDB v0.10 针对日志场景兼容了业内多种协议，包括 Loki Remote Write、Vector 插件以及 OTLP 全量数据类型（Metrics、Traces、Logs）的写入。同时新增了 JSON 类型、地理位置类型和向量数据类型。

从 v0.9 到 v0.10，Greptime 团队取得了显著的进展：共合并了 422 次代码提交，修改了 1120 个文件，其中包括 142 项功能增强， 103 项错误修复， 39 项代码重构，以及大量的测试工作。在此期间，共有 8 位来自社区的个人贡献者提交了 48 次代码贡献。

非常感谢团队和各位个人贡献者的努力，也欢迎更多对技术感兴趣的同学加入我们！

日志相关

• Loki Remote Write

• 支持 Loki Remote Write 写入协议。通过 Grafana Alloy 或者 Grafana Agent 的 loki.write 组件即可写入 Loki 格式的日志

• Pipeline Engine 优化和完善

• 大幅优化了 Pipeline Engine 的性能，在相对复杂配置下，Pipeline Engine 的处理速度相较 v0.9 版本提升了 70% 以上

• 新增 JSON Path Processor，支持使用 JSON Path 对数据进行提取

• Vector 插件支持

• 增加了 Vector 插件 sink greptime_logs，可以通过 vector 支持多种写入协议

• OTeL Log

• 随着 JSON 数据类型的原生支持，GreptimeDB 现在支持通过 OTLP 写入 Logs，并且重构了 Traces 的存储 schema。至此，GreptimeDB 完整地支持了 OTLP 的 Metrics，Traces 和 Logs 写入。

欢迎大家试用，详细用法可参考官方文档：https://docs.greptime.com/zh/user-guide/ingest-data/for-observerbility/opentelemetry/。

自由索引

过去在 GreptimeDB 中，INVERTED INDEX 倒排索引始终与 PRIMARY KEY 主键的声明绑定，所有 PRIMARY KEY 主键都会被建立倒排索引。一般来说，这种默认设定在绝大多数情况下都是合理的。通过为主键建立倒排索引，可以加快主键查询速度，这在多数场景下都是性能上的保障。

然而，随着 GreptimeDB 应用场景的不断扩展，一些值得关注的用户需求无法通过默认行为满足：

1. 弱化某些主键列的功能

• 有时候，用户只需将某列声明为主键以实现去重，而无需加速查询。例如，Prometheus Remote Write 协议所写入的 Tags 列会被映射为 GreptimeDB 的主键，但并非所有 Tags 列都需要加速查询。

2. 为非主键列建立倒排索引

• 日志场景下，某些字段可能不符合 Tags 的语义，但希望通过建立倒排索引来加速查询。

在新版本中我们对这一行为进行了优化，现在倒排索引不再与 PRIMARY KEY 强制关联，支持按需在任意列上建立倒排索引，这种灵活性带来成本和效率上的显著优势，也可以一定程度缓解高基数问题。

JSON 数据类型

GreptimeDB 支持 JSON 类型，允许用户存储和查询 JSON 格式的数据。JSON 类型非常灵活，可以存储各种形式的结构化或非结构化数据，适合日志记录、分析和半结构化数据存储等场景。

如何在 GreptimeDB 中使用 JSON 数据类型

1. 定义 JSON 类型列

在 SQL 中，可以通过以下语法来定义包含 JSON 类型的表。

CREATE TABLE <table_name> (   ...   <json_col> JSON );

2. JSON 写入

GreptimeDB 中，JSON 数据以字符串形式写入。

可以使用以下 SQL 格式插入 JSON 数据：

INSERT INTO <table> (<json_col>) VALUES ('{"key1": "value1", "key2": 10}'), ('{"name": "GreptimeDB", "open_source": true}'), ...

3. JSON 函数

GreptimeDB 支持多种 JSON 函数，用于操作 JSON 数据类型，包括 json_get_<type>、json_is_<type> 和json_path_exists 。

可以使用以下 SQL 格式执行 JSON 函数：

SELECT <json_function>(<json_col>, <args>) FROM <table>;

ALTER 功能增强

• 新增对修改 Database 以及 Table 的数据保留时间（TTL）的支持：

ALTER DATABASE my_db SET 'ttl'='360d';ALTER DATABASE my_db UNSET 'ttl';
ALTER TABLE my_table SET 'ttl'='1d';ALTER TABLE my_table UNSET 'ttl';

• 支持对 Compaction 一些参数进行修改，如：

# TWCS compaction 策略的时间窗口ALTER TABLE monitor SET 'compaction.twcs.time_window'='2h';# TWCS compaction 策略的最大允许输出文件大小ALTER TABLE monitor SET 'compaction.twcs.max_output_file_size'='500MB';# TWCS compaction 策略的活跃窗口中最多允许的有序组数量ALTER TABLE monitor SET 'compaction.twcs.max_inactive_window_files'='2';# TWCS compaction 策略的非活跃窗口中最多允许的有序组数量ALTER TABLE monitor SET 'compaction.twcs.max_active_window_files'='2';# TWCS compaction 策略的非活跃窗口中最多允许的文件数量ALTER TABLE monitor SET 'compaction.twcs.max_inactive_window_runs'='6';# TWCS compaction 策略的活跃窗口中最多允许的文件数量ALTER TABLE monitor SET 'compaction.twcs.max_active_window_runs'='6';

• 支持用来启用和关闭列的全文索引配置

# 开启全文索引ALTER TABLE monitor MODIFY COLUMN load_15 SET FULLTEXT WITH (analyzer = 'Chinese', case_sensitive = 'false');# 关闭全文索引ALTER TABLE monitor MODIFY COLUMN load_15 UNSET FULLTEXT;

查询性能提升

• 优化不指定时间范围时的扫描逻辑：如果用户存储了较长时间范围的数据，该优化可以避免查询时从对象存储加载所有元数据。

• 一些重点时序查询场景的性能优化：在查询时间戳最新的 N 条数据（order by timestamp desc limit N）这个场景下，可以达到将近 10 倍的性能提升.

其他更新

1. 地理空间类型

• 提供轨迹、地理编码相关的地理函数，支持 Geohash，H3 和 S2 索引，详细用法请参考官方文档：https://docs.greptime.com/zh/reference/sql/functions/geo/。

2. 向量类型

• 引入向量数据类型，在物联网车端等边缘场景中，GreptimeDB 以其高效轻量的架构，支持直接在边缘设备上高效运行，完成向量数据的存储与计算，为车载系统中的实时感知、智能决策和低时延响应提供强有力支持，助推 AI 技术在智能驾驶等领域的深度应用。

3. Flow 流处理

• 性能优化：显著提升性能，流式计算 COUNT(*) 的 FLOW 任务 CPU 开销降至原来的 1%。

• 易用性提高：新增对 CREATE OR REPLACE FLOW 的支持

升级提示

配置文件参数变更概览

本次升级对 Datanode 配置文件进行了以下调整：

（图 1：Datanode 配置文件调整）

升级步骤

v0.9 升级到 v0.10 版本

1. 检查配置文件

• 移除 region_engine.mito.max_background_jobs 参数：新版本中，该参数已被删除，原本用于限制总的后台任务数，现在拆分为更具体的任务类型限制参数（如 Flush 、Compaction、清理任务）。

• 如果配置文件中存在该参数，请删除，并根据新的参数重新设置值。

2. 新增参数调整

• 调整以下参数以替代原有功能：

• 使用 region_engine.mito.max_background_flushes 设置后台刷新任务的最大数量（默认值为 CPU 核心数的 1/2）。

• 使用 region_engine.mito.max_background_compactions 设置后台合并任务的最大数量（默认值为 CPU 核心数的 1/4）。

• 使用 region_engine.mito.max_background_purges 设置后台清理任务的最大数量（默认值为 CPU 核心数）。

• 根据原有配置中 max_background_jobs 的值，合理分配以上参数以满足性能需求。

更低版本升级到 v0.10 版本

从更低版本升级到 v0.10 需要停机升级，推荐使用官方升级工具。

升级流程如下：

1. 创建一个全新的 v0.10 集群

2. 关闭旧集群流量入口（停写）

3. 通过 GreptimeDB CLI 升级工具导出表结构和数据

4. 通过 GreptimeDB CLI 升级工具导入数据到新集群

5. 入口流量切换至新集群

详细升级指南请参考：

• 中文：https://docs.greptime.cn/user-guide/administration/disaster-recovery/back-up-&-restore-data
  

• 英文：https://docs.greptime.cn/en/user-guide/administration/disaster-recovery/back-up-&-restore-data
  

未来展望

GreptimeDB 的短期目标是成为一个融合 Metrics 和 Logs 的泛时序数据库。在下一个版本中，我们仍将继续打磨 Log Engine，进一步提升日志查询的性能和用户体验。这些改进将包括（但不限于）增加 GreptimeDB 日志查询 DSL 的功能以及实现部分 Elasticsearch/Loki API 的兼容性，为用户提供更加高效和灵活的日志查询能力。

关于 Greptime

Greptime 格睿科技专注于为可观测、物联网及车联网等领域提供实时、高效的数据存储和分析服务，帮助客户挖掘数据的深层价值。目前基于云原生的时序数据库 GreptimeDB 已经衍生出多款适合不同用户的解决方案，更多信息或 demo 展示请联系下方小助手（微信号：greptime）。

欢迎对开源感兴趣的朋友们参与贡献和讨论，从带有 good first issue 标签的 issue 开始你的开源之旅吧～期待在开源社群里遇见你！添加小助手微信即可加入“技术交流群”与志同道合的朋友们面对面交流哦~

Star us on GitHub Now: https://github.com/GreptimeTeam/greptimedb

官网：https://greptime.cn/

文档：https://docs.greptime.cn/

Twitter: https://twitter.com/Greptime

Slack: https://greptime.com/slack

LinkedIn: https://www.linkedin.com/company/greptime/