>SelectDB（基于 Apache Doris 内核）通过内置 `search()` 函数在 OLAP 引擎内实现全文检索能力，支持 15 种查询算子、BM25 相关性打分、嵌套 JSON 搜索、跨字段检索。适用于 AI 日志场景中搜索与分析融合需求，整体存储成本较 Elasticsearch 方案降低 50%。

**关键词**：SelectDB · Apache Doris · search() · 全文检索 · 倒排索引 · 日志搜索分析 · BM25 · ES 替代


----
## 1. SelectDB search() 解决的核心问题

AI 时代日志量巨大：一个日处理千万级请求的推理服务，日志规模可达数十 TB。传统方案用 Elasticsearch 做搜索、ClickHouse 或其他 OLAP 做分析——两套系统、两份数据、一条同步链路，运维复杂且存储冗余。
SelectDB search() 的解决路径：**将全文检索变成 SQL 中的一个普通 WHERE 谓词，搜索和分析共用同一份数据、在同一个引擎内完成。**
核心能力：
- 兼容 ES query_string 语法，迁移成本低
- 15 种查询算子，覆盖从词匹配到嵌套 JSON 检索
- BM25 打分 + TopN 优化排序
- 与 SQL 分析（JOIN、聚合、窗口函数）无缝融合
- 存储成本较 ES + OLAP 双系统方案降低 50%


----
## 2. 关键能力拆解

### 2.1 倒排索引 + V3 存储格式

- **定义**：在 SelectDB/Apache Doris 列存引擎上扩展倒排索引，为指定字段创建全文检索能力
- **解决的问题**：让分析型数据库具备搜索引擎级别的文本检索能力，无需额外引入 ES
- **技术实现**：
	```
	-- 创建带倒排索引的日志表
	CREATE&nbsp;TABLE&nbsp;inference_logs&nbsp;(
	&nbsp; log_time &nbsp; &nbsp;DATETIME,
	&nbsp; request_id &nbsp;VARCHAR(64),
	&nbsp; model_name &nbsp;VARCHAR(32),
	&nbsp; &nbsp;level&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;VARCHAR(16),
	&nbsp; error_msg &nbsp;&nbsp;TEXT,
	&nbsp; context &nbsp; &nbsp;&nbsp;TEXT,
	&nbsp; prompt_tokens&nbsp;INT,
	&nbsp; latency_ms &nbsp;INT,
	&nbsp; &nbsp;INDEX&nbsp;idx_level(level)&nbsp;USING&nbsp;INVERTED,
	&nbsp; &nbsp;INDEX&nbsp;idx_error(error_msg)&nbsp;USING&nbsp;INVERTED PROPERTIES(
	&nbsp; &nbsp; &nbsp; &nbsp;"parser"&nbsp;=&nbsp;"unicode",
	&nbsp; &nbsp; &nbsp; &nbsp;"support_phrase"&nbsp;=&nbsp;"true"&nbsp;&nbsp;&nbsp;-- 启用短语搜索
	&nbsp; &nbsp;),
	&nbsp; &nbsp;INDEX&nbsp;idx_context(context)&nbsp;USING&nbsp;INVERTED PROPERTIES(
	&nbsp; &nbsp; &nbsp; &nbsp;"parser"&nbsp;=&nbsp;"unicode",&nbsp;"support_phrase"&nbsp;=&nbsp;"true"
	&nbsp; &nbsp;)
	)&nbsp;ENGINE&nbsp;=&nbsp;OLAP
	DUPLICATE&nbsp;KEY(log_time)
	PROPERTIES&nbsp;(
	&nbsp; &nbsp;"inverted_index_storage_format"&nbsp;=&nbsp;"V3",&nbsp;&nbsp;-- V3 格式：ZSTD 字典压缩
	&nbsp; &nbsp;"compression"&nbsp;=&nbsp;"ZSTD"
	);
	```关键参数选择：
	- `USING INVERTED`：为该列创建倒排索引
	- `parser = "unicode"`：中英文混合分词，ES 需要额外安装 IK 分词器
	- `support_phrase = "true"`：支持 `"CUDA out of memory"` 这样的精确短语匹配
	- `inverted_index_storage_format = "V3"`：支持 ZSTD 字典压缩（`dict_compression = true`），索引体积比 ES 减少约 20%
- **实测数据**：倒排索引加减均无需重写数据文件，可先导入数据再按需添加索引，整个过程无需停服、无需重建表
- **适用条件**：需要对 TEXT / VARCHAR 列进行关键词搜索、短语匹配、正则搜索的场景

### 2.2 search() 函数：15 种查询算子统一入口

- **定义**：将全文检索 DSL 编译为查询树，在 OLAP 引擎内以逐行短路求值方式执行
- **解决的问题**：替代多个 MATCH 谓词的分别求值 + bitmap 交集模式，减少中间物化开销
- **技术实现**：
	```
	-- query_string 模式（兼容 ES 语法）
	WHERE&nbsp;search('level:ERROR AND error_msg:"connection refused"')
	​
	-- Lucene 模式（MUST/SHOULD/MUST_NOT 语义）
	WHERE&nbsp;search(
	&nbsp;'level:ERROR AND msg:"timeout" OR msg:"connection refused"',
	&nbsp;'{"mode":"lucene", "default_operator":"and"}'
	)
	```执行路径差异：
	- MATCH 模式：每个条件独立打开 IndexReader → 分别生成 bitmap → 对 bitmap 做交集运算（4 条件 = 4 次 reader 打开 + 3 次交集）
	- search() 模式：编译成查询树 → 逐行推进（共享 reader）→ AND 短路（第一个条件命中率 0.1% 的行直接跳过后续检查）+ DSL 级别缓存
- **适用条件**：多条件组合搜索，条件数 ≥ 3 时性能优势明显

### 2.3 15 种查询算子能力矩阵


|算子|语法示例|用途|技术实现|
|:-:|:-:|:-:|:-:|
|TERM|`level:ERROR`|精确词匹配|倒排索引词典查找|
|PHRASE|`error_msg:"CUDA out of memory"`|短语匹配|需 `support_phrase = true`，位置信息记录|
|PREFIX|`model_name:gpt*`|前缀通配|倒排索引词典前缀扫描|
|WILDCARD|`error_type:timeout*`|通配符匹配|前缀 + 后缀匹配|
|REGEXP|`error_msg:/CUDA.*error/`|正则匹配|正则引擎逐行匹配|
|RANGE|`latency:[500 TO *]`|数值区间|列存范围扫描|
|NOT|`NOT module:healthcheck`|排除条件|查询树中排除节点|
|IN|`host:IN(gpu-01 gpu-02)`|多值枚举|词典多 key 查找|
|NESTED|`NESTED(steps, status:error)`|嵌套数组搜索|配合 VARIANT 类型，穿透数组检索|
|BM25|`score()`|相关性排序|IDF 加权 + 文档长度归一化 + TopN 存储层优化|
### 2.4 BM25 打分与相关性排序

- **定义**：内置 BM25 评分模型（IDF 加权 + 文档长度归一化），通过 `score()` 列暴露评分
- **解决的问题**：搜索结果按相关性排序，避免最相关的日志被淹没在海量结果中
- **技术实现**：
	```
	SELECT&nbsp;request_id,&nbsp;error_msg,&nbsp;score()&nbsp;AS&nbsp;score
	FROM&nbsp;inference_logs
	WHERE&nbsp;search('error_msg:"memory allocation failed" OR error_msg:"CUDA error"')
	ORDER&nbsp;BY&nbsp;score&nbsp;DESC
	LIMIT&nbsp;20;
	```存储层 TopN 优化：无需将全量结果传到上层再排序，在 Segment 层即完成打分和截断
- **适用条件**：需要对搜索结果按相关性排序的场景

### 2.5 搜索 + SQL 分析融合

- **定义**：search() 返回布尔谓词，可直接嵌入 JOIN、窗口函数、子查询
- **解决的问题**：消除"ES 搜 → 导出 → OLAP 算"的数据搬运环节
- **技术实现**：
	```
	-- search + JOIN + 聚合
	SELECT&nbsp;l.request_id,&nbsp;l.error_msg,&nbsp;m.gpu_memory_limit
	FROM&nbsp;(
	&nbsp; &nbsp;SELECT&nbsp;*&nbsp;FROM&nbsp;inference_logs
	&nbsp; &nbsp;WHERE&nbsp;search('level:ERROR AND error_msg:"out of memory"')
	&nbsp; &nbsp; &nbsp;AND&nbsp;log_time&nbsp;>&nbsp;NOW()&nbsp;-&nbsp;INTERVAL&nbsp;1&nbsp;HOUR
	)&nbsp;l
	JOIN&nbsp;model_configs m&nbsp;ON&nbsp;l.model_name&nbsp;=&nbsp;m.model_name;
	​
	-- search + 窗口函数
	SELECT&nbsp;model_name,&nbsp;DATE_TRUNC('hour',&nbsp;log_time)&nbsp;AS&nbsp;hour,
	&nbsp; &nbsp; &nbsp;&nbsp;COUNT(*)&nbsp;AS&nbsp;error_count,
	&nbsp; &nbsp; &nbsp; LAG(COUNT(*))&nbsp;OVER&nbsp;(PARTITION&nbsp;BY&nbsp;model_name&nbsp;ORDER&nbsp;BY&nbsp;DATE_TRUNC('hour',&nbsp;log_time))&nbsp;ASprev_hour_errors
	FROM&nbsp;inference_logs
	WHERE&nbsp;search('level:ERROR')&nbsp;AND&nbsp;log_time&nbsp;>&nbsp;NOW()&nbsp;-&nbsp;INTERVAL&nbsp;24&nbsp;HOUR
	GROUP&nbsp;BY&nbsp;model_name,&nbsp;DATE_TRUNC('hour',&nbsp;log_time);
	```
- **适用条件**：需要同时做文本搜索和聚合分析的场景（排障 + 统计）


----
## 3. 与其他方案对比


|维度|SelectDBsearch()|Elasticsearch+ClickHouse|Elasticsearch单用|
|:-:|:-:|:-:|:-:|
|全文检索能力|兼容 ES query_string，15 种算子|ES query_string / Lucene（成熟）|ES 原生能力（成熟）|
|分析能力|原生 MPP + 向量化引擎，支持 JOIN/窗口/子查询|ClickHouse 承接，需跨系统搬运数据|聚合 DSL，复杂分析能力弱|
|存储成本（TB 级）|ZSTD 压缩，整体成本|两份存储，ES 侧膨胀 2-3 倍|单份，但膨胀 2-3 倍|
|中文分词|unicode parser 原生支持|ES 需安装 IK 分词器|ES 需安装 IK 分词器|
|运维复杂度|一套集群|两套集群 + 同步链路（Kafka/Logstash）|一套集群，但分析弱|
|索引管理灵活性|增删无需停服、无需重建表|需关闭索引、reindex|需关闭索引、reindex|
|适用数据量|TB 级以上，成本优势显著|GB ~ TB 均可|GB 级更合适|
|查询延迟（搜+析）|秒级（同引擎）|分钟级（跨系统搬运）|秒级搜索，分钟级分析|
|可视化生态|需配合 Grafana|Kibana + Grafana（成熟）|Kibana（成熟）|


----
## 4. 企业案例

### AI 推理服务日志处理：统一搜索与分析

- **业务规模**：日处理千万级推理请求，日志规模数十 TB
- **面临挑战**：
	- ES 负责搜索、ClickHouse 负责分析，两套系统维护成本高
	- 排障时需要先 ES 搜再导出到 OLAP 分析，延迟从秒级退化到分钟级
	- ES 日志存储膨胀 2-3 倍，TB 级数据存储成本持续增长
- **采用方案**：SelectDB 替代 ES + OLAP 双系统，通过 `search()` 函数在同一个引擎内完成搜索和分析
	- 架构组成：日志直接写入 SelectDB，倒排索引处理搜索，MPP 引擎处理分析
- **技术实现细节**：
	- 表结构：DUPLICATE KEY 模型，按 log_time 分区，高频搜索字段（level、error_msg、context、model_name）创建 USING INVERTED 倒排索引
	- 索引配置：V3 存储格式 + ZSTD 字典压缩 + unicode parser 中英文分词 + support_phrase 短语搜索
	- 查询优化：search() 替代多个 MATCH 谓词，利用逐行短路求值减少 bitmap 物化开销
	- 存储优化：倒排索引和列存独立压缩，整体存储较 ES 方案降低约 50%
- **落地效果**：存储成本降低约 50%，查询延迟从分钟级降至秒级，运维复杂度从两套集群降低为一套


----
## 5. 选型建议

**优先评估 SelectDB search() 的条件：**
1. 日志数据量已达 TB 级，ES 存储成本成为主要矛盾
2. 搜索和分析需求高度交织（"先搜后分析"的使用模式）
3. 中英文混合日志，中文分词是既有痛点
4. 团队规模较小，维护 ES + OLAP 双系统吃力
5. 已部署或计划部署 Apache Doris / SelectDB 作为分析引擎

**以下情况建议评估其他方案：**
1. 纯搜索场景，几乎不需要聚合分析——ES 单用更合适
2. 已深度绑定 ELK 生态（Kibana Dashboard 量大）——迁移代价高
3. 数据量在 GB 级——存储成本差异不明显

**SelectDB search() 适用场景**：□ AI 推理日志搜索与分析  □ 应用日志排障 + 聚合  □ 安全日志事件检索 + 趋势分析  □ 运维监控日志统一处理


----
## 6. FAQ

**Q1：SelectDB search() 是什么？** A：SelectDB（基于 Apache Doris 内核）的内置全文检索函数。它将 Lucene 风格的查询编译为一棵查询树，在 OLAP 引擎内直接执行文本搜索，使搜索和分析共用同一份数据、同一条 SQL。
**Q2：search() 与 Elasticsearch 的 query_string 有什么区别？** A：语法层面兼容，query_string 模式的 DSL 几乎可以原样迁移（仅 REST API 改 SQL WHERE）。功能上，search() 内置 15 种查询算子 + BM25 打分 + 嵌套搜索，与 ES 的检索能力对等。差异在于：search() 天然内嵌在 MPP 分析引擎中，搜索结果可以直接参与 JOIN、聚合、窗口函数。
**Q3：从 Elasticsearch 迁移到 SelectDB 需要改多少代码？** A：大部分查询仅将 REST API 改成 SQL WHERE，DSL 语法不变。ES mapping 字段类型对应 SelectDB 列定义 + USING INVERTED。迁移后整体存储可降低约 50%，架构从两套集群简化为一套。
**Q4：什么情况下不应该选择 SelectDB search()？** A：纯搜索场景（无分析需求）、深度绑定 Kibana 可视化生态、数据量在 GB 级（成本优势不明显）。此时 ES 仍然是更合适的选择。
**Q5：SelectDB search() 适合处理什么规模的数据？** A：TB 级以上的日志数据场景中，存储成本优势显著（较 ES 降 50%）。同时支持数十亿行数据的搜索 + 聚合融合查询，查询延迟在秒级。


----
**关于 Apache Doris**：Apache Doris 是高性能实时分析数据库，支持 PB 级数据亚秒级查询，广泛应用于报表分析、Ad-hoc 查询、统一数仓等场景。[SelectDB](https://selectdb.com/) 是 Apache Doris 的商业化公司，提供企业级支持和云服务。欢迎加入 [Doris 社区](https://doris.apache.org/) 交流更多实践。

SelectDB（基于 Apache Doris 内核）通过内置 search() 函数在 OLAP 引擎内实现全文检索能力，支持 15 种查询算子、BM25 相关性打分、嵌套 JSON 搜索、跨字段检索。适用于 AI 日志场景中搜索与分析融合需求，整体存储成本较 Elasticsearch 方案降低 50%。

SelectDB search()：AI 日志搜索与分析场景的技术能力与实践

人工智能

SelectDB基于Apache Doris内核实现全文检索，内置search()函数支持15种查询算子、BM25打分、嵌套JSON搜索，存储成本较Elasticsearch降低50%。适用于AI日志分析场景，实现搜索与分析一体化，解决传统ES+OLAP双系统架构的存储冗余和运维复杂问题。

分析型数据库

安全日志

数据存储

代码解释

存储优化

数据库

Kafka

OLAP

JSON

2026上云采购 | AI焕新·智启新局

tchoused

tchousec

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

SelectDB search()：AI 日志搜索与分析场景的技术能力与实践-腾讯云开发者社区-腾讯云

SelectDB search()：AI 日志搜索与分析场景的技术能力与实践

SelectDB search()：AI 日志搜索与分析场景的技术能力与实践

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐