本次 v0.14 更新聚焦于对全文索引的功能和性能以及成本优化；Flow Engine 引入 Batching 模式与 Streaming 模式形成双引擎架构，从而实现更灵活的数据处理；正式实现并发布了对 OTel 的 Traces 的支持。
从 v0.13 到 v0.14，Greptime 团队取得了显著的进展：共合并了 247 个 PR，其中包括 100 项功能增强，56 项错误修复，30 项代码重构，9 项性能优化以及大量的测试工作。在此期间，来自社区的 7 位个人贡献者提交了 16 次代码贡献。非常感谢团队和各位个人贡献者的努力，也欢迎更多对技术感兴趣的同学加入我们。
下面对本次版本更新做一个简单回顾和介绍：
全文索引增强
GreptimeDB 提供全文索引功能以加速文本搜索操作。用户可以在创建或修改表时配置全文索引，并提供各种选项以针对不同用例进行优化。
此次 v0.14 对全文索引的更新主要包括两个部分：
引入新的函数 matches_term
和操作符 @@
SQL 查询中，用户可以使用 matches_term
函数执行精确的词语/短语匹配，这在日志分析中尤其实用。matches_term
函数支持对 String
类型列进行精确匹配。你也可以使用 @@
操作符作为 matches_term
的简写形式。
下面是一个典型示例：
-- 使用 matches_term 函数
SELECT * FROM logs WHERE matches_term(message, 'error') OR matches_term(message, 'fail');
-- 使用 @@ 操作符（matches_term 的简写形式）
SELECT * FROM logs WHERE message @@ 'error' OR message @@ 'fail';
matches_term
函数专门用于精确匹配，使用方式如下：
text
：需要进行匹配的文本列，该列应包含String
类型的文本数据。term
：要匹配的词语或短语，遵循以下规则👇区分大小写； 匹配项必须由非字母数字字符（包括空格、标点符号等）或文本开头/结尾界定； 支持完整词语匹配和短语匹配。
详细使用方法欢迎参考 GreptimeDB 官方的最新文档：
https://docs.greptime.com/zh/user-guide/logs/query-logs/
引入全新的全文索引后端
引入了全新的 Bloom 全文索引后端。从 v0.14 开始，用户在为构建全文索引时将有两种选择，能帮助用户对自身的场景做出最合适的选择，以下展示了两种全文索引后端的特点：
1. Bloom 后端
| 适用场景 | |
| 特点 | - 存储开销较低 - 在不同查询模式下性能稳定 |
| 限制 | |
| 存储成本示例 | - Bloom 索引：约 1GB |
2. Tantivy 后端
| 适用场景 | |
| 特点 | - 对高选择性查询性能优异 |
| 限制 | - 对低选择性查询性能较慢 |
| 存储成本示例 | - Tantivy 索引：约 10GB |
性能对比
下表展现了不同查询方法之间的性能对比（以 Bloom 为基准）：
| 查询类型 | 高选择性（如 TraceID） | 低选择性（如 "HTTP"） |
|---|---|---|
| Bloom | ||
| Tantivy | ||
| LIKE |
主要观察结果：
对于高选择性查询（如唯一值），Tantivy 能够提供最佳性能； 对于低选择性查询，Bloom 能够提供更稳定的性能； Bloom 在存储方面比 Tantivy 有明显优势（测试案例中为 1GB vs 10GB）。
详细使用方法，欢迎参考 GreptimeDB 官方最新文档：
https://docs.greptime.com/zh/user-guide/logs/fulltext-index-config
其他更新
支持 Jaeger 查询协议 （实验功能阶段）
用户可以使用 Grafana 的 Jaeger 插件 或者 Jaeger UI 来查询 GreptimeDB 中的 Traces 数据。需要注意的是，Jaeger 查询接口目前仍处于实验阶段，在未来的版本中可能会有所调整。
详细的使用方式请参考 GreptimeDB 官方文档：
https://docs.greptime.com/zh/user-guide/query-data/jaeger/#
Jaeger 插件：
https://grafana.com/docs/grafana/latest/datasources/jaeger/
Jaeger UI：
https://github.com/jaegertracing/jaeger-ui
Flow 双引擎
Flow Engine 引入 Batching 模式与 Streaming 模式形成双引擎架构，从而实现更灵活的数据处理：
Batching 模式：定期批量处理数据，有最小刷新间隔； Streaming 模式：实时处理数据流，更加及时；
通常情况下，Batching 模式资源使用更加平稳，适合大批量数据处理，比如定期对数据进行聚合、统计和生成报表的场景；而 Streaming 模式实时性更高，但可能需要更多资源来保持低延迟，更适合对数据处理延迟有严格要求的场景。
当前，引擎会根据创建请求自行判断一个 Flow Task 需要以何种模式运行，未来可能将选项开放到用户层以提供更灵活的选择。
更多关于 Flow 的使用，请参考 GreptimeDB 官方最新文档：
https://docs.greptime.com/zh/user-guide/flow-computation/overview
正式支持 OTel Traces
GreptimeDB 支持直接写入 OpenTelemetry 协议的 Traces 数据，并内置 OpenTelemetry 的 Traces 的表模型来让用户方便地查询和分析 Traces 数据。
详细使用方式请参考 GreptimeDB 官方文档：
https://docs.greptime.com/zh/user-guide/ingest-data/for-observability/opentelemetry/#traces
升级提示
v0.14 与 v0.13 数据和配置完全兼容，如果用户在使用 v0.13，建议直接升级，对于使用其他版本的用户，请参考升级指南进行升级:
https://docs.greptime.com/zh/user-guide/administration/upgrade
未来展望
根据一月发布的《GreptimeDB 2025 Roadmap》，GreptimeDB 将持续推进一系列重要功能的更新与优化。下一个版本将聚焦于写入链路的吞吐优化（Bulk Ingestion）和完善分布式可靠性、稳定性方面的工作。
关于 Greptime
Greptime 格睿科技专注于打造新一代可观测数据库，服务开发者与企业用户，覆盖从从边缘设备到云端企业级部署的多样化需求。
GreptimeDB 开源版：开源、云原生，统一处理指标、日志和追踪数据，适合中小规模 IoT，个人项目与可观测性场景； GreptimeDB 企业版：面向关键业务，提供更高性能、高安全性、高可用性和智能化运维服务； GreptimeCloud 云服务：全托管云服务，零运维体验“企业级”可观测数据库，弹性扩展，按需付费。
欢迎加入开源社区参与贡献与交流！推荐从带有 good first issue
标签的任务入手，一起共建可观测未来。
⭐ Star us on GitHub：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/
往期精彩文章：
点击「阅读原文」，立即体验 GreptimeDB！
