On this page
从 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 格式的日志
- 支持 Loki Remote Write 写入协议。通过 Grafana Alloy 或者 Grafana Agent 的
Pipeline Engine 优化和完善
大幅优化了 Pipeline Engine 的性能，在相对复杂配置下，Pipeline Engine 的处理速度相较 v0.9 版本提升了 70% 以上
新增 JSON Path Processor，支持使用 JSON Path 对数据进行提取
Vector 插件支持
- 增加了 Vector 插件 sink
greptime_logs，可以通过 vector 支持多种写入协议
- 增加了 Vector 插件 sink
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 应用场景的不断扩展，一些值得关注的用户需求无法通过默认行为满足：
- 弱化某些主键列的功能
- 有时候，用户只需将某列声明为主键以实现去重，而无需加速查询。例如，Prometheus Remote Write 协议所写入的 Tags 列会被映射为 GreptimeDB 的主键，但并非所有 Tags 列都需要加速查询。
- 为非主键列建立倒排索引
- 日志场景下，某些字段可能不符合 Tags 的语义，但希望通过建立倒排索引来加速查询。
在新版本中我们对这一行为进行了优化，现在倒排索引不再与 PRIMARY KEY 强制关联，支持按需在任意列上建立倒排索引，这种灵活性带来成本和效率上的显著优势，也可以一定程度缓解高基数问题。
JSON 数据类型
GreptimeDB 支持 JSON 类型，允许用户存储和查询 JSON 格式的数据。JSON 类型非常灵活，可以存储各种形式的结构化或非结构化数据，适合日志记录、分析和半结构化数据存储等场景。
如何在 GreptimeDB 中使用 JSON 数据类型
- 定义 JSON 类型列
在 SQL 中，可以通过以下语法来定义包含 JSON 类型的表。
sql
CREATE TABLE <table_name> (
...
<json_col> JSON
);- JSON 写入
GreptimeDB 中，JSON 数据以字符串形式写入。
可以使用以下 SQL 格式插入 JSON 数据：
sql
INSERT INTO <table> (<json_col>) VALUES
('{"key1": "value1", "key2": 10}'),
('{"name": "GreptimeDB", "open_source": true}'),
...- JSON 函数
GreptimeDB 支持多种 JSON 函数，用于操作 JSON 数据类型，包括 json_get_<type>、json_is_<type> 和json_path_exists 。
可以使用以下 SQL 格式执行 JSON 函数：
sql
SELECT <json_function>(<json_col>, <args>) FROM <table>;ALTER 功能增强
- 新增对修改 Database 以及 Table 的数据保留时间（TTL）的支持：
sql
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 一些参数进行修改，如：
sql
# 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';- 支持用来启用和关闭列的全文索引配置
sql
# 开启全文索引
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 倍的性能提升.
其他更新
- 地理空间类型
- 提供轨迹、地理编码相关的地理函数，支持 Geohash，H3 和 S2 索引，详细用法请参考官方文档：https://docs.greptime.com/zh/reference/sql/functions/geo/。
- 向量类型
- 引入向量数据类型，在物联网车端等边缘场景中，GreptimeDB 以其高效轻量的架构，支持直接在边缘设备上高效运行，完成向量数据的存储与计算，为车载系统中的实时感知、智能决策和低时延响应提供强有力支持，助推 AI 技术在智能驾驶等领域的深度应用。
- Flow 流处理
性能优化：显著提升性能，流式计算
COUNT(*)的 FLOW 任务 CPU 开销降至原来的 1%。易用性提高：新增对
CREATE OR REPLACE FLOW的支持
升级提示
配置文件参数变更概览
本次升级对 Datanode 配置文件进行了以下调整：
升级步骤
v0.9 升级到 v0.10 版本
- 检查配置文件
移除
region_engine.mito.max_background_jobs参数：新版本中，该参数已被删除，原本用于限制总的后台任务数，现在拆分为更具体的任务类型限制参数（如 Flush 、Compaction、清理任务）。如果配置文件中存在该参数，请删除，并根据新的参数重新设置值。
- 新增参数调整
- 调整以下参数以替代原有功能：
- 使用
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 需要停机升级，推荐使用官方升级工具。
升级流程如下：
创建一个全新的 v0.10 集群
关闭旧集群流量入口（停写）
通过 GreptimeDB CLI 升级工具导出表结构和数据
通过 GreptimeDB CLI 升级工具导入数据到新集群
入口流量切换至新集群
详细升级指南请参考：
中文：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
Twitter: https://twitter.com/Greptime
Slack: https://greptime.com/slack
