On this page
本次 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 的简写形式。
下面是一个典型示例：
sql
-- 使用 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 官方的最新文档。
引入全新的全文索引后端
引入了全新的 Bloom 全文索引后端。从 v0.14 开始，用户在为构建全文索引时将有两种选择，能帮助用户对自身的场景做出最合适的选择，以下展示了两种全文索引后端的特点：
1. Bloom 后端
| 适用场景 | 通用日志搜索 |
| 特点 | - 使用 Bloom 过滤器进行高效过滤 - 存储开销较低 - 在不同查询模式下性能稳定 |
| 限制 | 对于高选择性查询稍慢 |
| 存储成本示例 | - 原始数据：约 10GB - Bloom 索引：约 1GB |
2. Tantivy 后端
| 适用场景 | 高选择性查询（如 TraceID 等唯一值） |
| 特点 | - 使用倒排索引实现快速精确匹配； - 对高选择性查询性能优异 |
| 限制 | - 存储开销较高（接近原始数据大小） - 对低选择性查询性能较慢 |
| 存储成本示例 | - 原始数据：约 10GB - Tantivy 索引：约 10GB |
性能对比
下表展现了不同查询方法之间的性能对比（以 Bloom 为基准）：
| 查询类型 | 高选择性（如 TraceID） | 低选择性（如 "HTTP"） |
|---|---|---|
| Bloom | 1 倍（基准） | 1 倍（基准） |
| Tantivy | 快 5 倍 | 慢 5 倍 |
| LIKE | 慢 50 倍 | 1 倍 |
主要观察结果：
- 对于高选择性查询（如唯一值），Tantivy 能够提供最佳性能；
- 对于低选择性查询，Bloom 能够提供更稳定的性能；
- Bloom 在存储方面比 Tantivy 有明显优势（测试案例中为 1GB vs 10GB）。
详细使用方法，欢迎参考 GreptimeDB 官方最新文档。
其他更新
支持 Jaeger 查询协议 （实验功能阶段）
用户可以使用 Grafana 的 Jaeger 插件 或者 Jaeger UI 来查询 GreptimeDB 中的 Traces 数据。需要注意的是，Jaeger 查询接口目前仍处于实验阶段，在未来的版本中可能会有所调整。
详细的使用方式，请参考 GreptimeDB 官方文档。
Flow 双引擎
Flow Engine 引入 Batching 模式与 Streaming 模式形成双引擎架构，从而实现更灵活的数据处理：
- Batching 模式：定期批量处理数据，有最小刷新间隔；
- Streaming 模式：实时处理数据流，更加及时；
通常情况下，Batching 模式资源使用更加平稳，适合大批量数据处理，比如定期对数据进行聚合、统计和生成报表的场景；而 Streaming 模式实时性更高，但可能需要更多资源来保持低延迟，更适合对数据处理延迟有严格要求的场景。
当前，引擎会根据创建请求自行判断一个 Flow Task 需要以何种模式运行，未来可能将选项开放到用户层以提供更灵活的选择。
更多关于 Flow 的使用，请参考 GreptimeDB 官方最新文档。
正式支持 OTel Traces
GreptimeDB 支持直接写入 OpenTelemetry 协议的 Traces 数据，并内置 OpenTelemetry 的 Traces 的表模型来让用户方便地查询和分析 Traces 数据。
详细使用方式，请参考 GreptimeDB 官方文档。
升级提示
v0.14 与 v0.13 数据和配置完全兼容，如果用户在使用 v0.13，建议直接升级，对于使用其他版本的用户，请参考升级指南进行升级。
未来展望
根据一月发布的《GreptimeDB 2025 Roadmap》，GreptimeDB 将持续推进一系列重要功能的更新与优化。下一个版本将聚焦于写入链路的吞吐优化（Bulk Ingestion）和完善分布式可靠性、稳定性方面的工作。
关于 Greptime
Greptime 格睿科技专注于打造新一代可观测数据库，服务开发者与企业用户，覆盖从从边缘设备到云端企业级部署的多样化需求。
- GreptimeDB 开源版：开源、云原生，统一处理指标、日志和追踪数据，适合中小规模 IoT，个人项目与可观测性场景；
- GreptimeDB 企业版：面向关键业务，提供更高性能、高安全性、高可用性和智能化运维服务；
- GreptimeCloud 云服务：全托管云服务，零运维体验“企业级”可观测数据库，弹性扩展，按需付费。
欢迎加入开源社区参与贡献与交流！推荐从带有 good first issue 标签的任务入手，一起共建可观测未来。
⭐ Star us on GitHub | 📚 官网 | 📖 文档
