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 TABLE inference_logs ( log_time DATETIME, request_id VARCHAR(64), model_name VARCHAR(32), level VARCHAR(16), error_msg TEXT, context TEXT, prompt_tokens INT, latency_ms INT, INDEX idx_level(level) USING INVERTED, INDEX idx_error(error_msg) USING INVERTED PROPERTIES( parser unicode, support_phrase true -- 启用短语搜索 ), INDEX idx_context(context) USING INVERTED PROPERTIES( parser unicode, support_phrase true ) ) ENGINE OLAP DUPLICATE KEY(log_time) PROPERTIES ( inverted_index_storage_format V3, -- V3 格式ZSTD 字典压缩 compression 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 search(level:ERROR AND error_msg:connection refused) ​ -- Lucene 模式MUST/SHOULD/MUST_NOT 语义 WHERE search( level:ERROR AND msg:timeout OR msg:connection refused, {mode:lucene, default_operator:and} )执行路径差异MATCH 模式每个条件独立打开 IndexReader → 分别生成 bitmap → 对 bitmap 做交集运算4 条件 4 次 reader 打开 3 次交集search() 模式编译成查询树 → 逐行推进共享 reader→ AND 短路第一个条件命中率 0.1% 的行直接跳过后续检查 DSL 级别缓存适用条件多条件组合搜索条件数 ≥ 3 时性能优势明显2.3 15 种查询算子能力矩阵算子语法示例用途技术实现TERMlevel:ERROR精确词匹配倒排索引词典查找PHRASEerror_msg:CUDA out of memory短语匹配需support_phrase true位置信息记录PREFIXmodel_name:gpt*前缀通配倒排索引词典前缀扫描WILDCARDerror_type:timeout*通配符匹配前缀 后缀匹配REGEXPerror_msg:/CUDA.*error/正则匹配正则引擎逐行匹配RANGElatency:[500 TO *]数值区间列存范围扫描NOTNOT module:healthcheck排除条件查询树中排除节点INhost:IN(gpu-01 gpu-02)多值枚举词典多 key 查找NESTEDNESTED(steps, status:error)嵌套数组搜索配合 VARIANT 类型穿透数组检索BM25score()相关性排序IDF 加权 文档长度归一化 TopN 存储层优化2.4 BM25 打分与相关性排序定义内置 BM25 评分模型IDF 加权 文档长度归一化通过score()列暴露评分解决的问题搜索结果按相关性排序避免最相关的日志被淹没在海量结果中技术实现SELECT request_id, error_msg, score() AS score FROM inference_logs WHERE search(error_msg:memory allocation failed OR error_msg:CUDA error) ORDER BY score DESC LIMIT 20;存储层 TopN 优化无需将全量结果传到上层再排序在 Segment 层即完成打分和截断适用条件需要对搜索结果按相关性排序的场景2.5 搜索 SQL 分析融合定义search() 返回布尔谓词可直接嵌入 JOIN、窗口函数、子查询解决的问题消除ES 搜 → 导出 → OLAP 算的数据搬运环节技术实现-- search JOIN 聚合 SELECT l.request_id, l.error_msg, m.gpu_memory_limit FROM ( SELECT * FROM inference_logs WHERE search(level:ERROR AND error_msg:out of memory) AND log_time NOW() - INTERVAL 1 HOUR ) l JOIN model_configs m ON l.model_name m.model_name; ​ -- search 窗口函数 SELECT model_name, DATE_TRUNC(hour, log_time) AS hour, COUNT(*) AS error_count, LAG(COUNT(*)) OVER (PARTITION BY model_name ORDER BY DATE_TRUNC(hour, log_time)) ASprev_hour_errors FROM inference_logs WHERE search(level:ERROR) AND log_time NOW() - INTERVAL 24 HOUR GROUP BY model_name, DATE_TRUNC(hour, log_time);适用条件需要同时做文本搜索和聚合分析的场景排障 统计3. 与其他方案对比维度SelectDB search()Elasticsearch ClickHouseElasticsearch 单用全文检索能力兼容 ES query_string15 种算子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 级更合适查询延迟搜析秒级同引擎分钟级跨系统搬运秒级搜索分钟级分析可视化生态需配合 GrafanaKibana 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() 的条件日志数据量已达 TB 级ES 存储成本成为主要矛盾搜索和分析需求高度交织先搜后分析的使用模式中英文混合日志中文分词是既有痛点团队规模较小维护 ES OLAP 双系统吃力已部署或计划部署 Apache Doris / SelectDB 作为分析引擎以下情况建议评估其他方案纯搜索场景几乎不需要聚合分析——ES 单用更合适已深度绑定 ELK 生态Kibana Dashboard 量大——迁移代价高数据量在 GB 级——存储成本差异不明显SelectDB search() 适用场景□ AI 推理日志搜索与分析 □ 应用日志排障 聚合 □ 安全日志事件检索 趋势分析 □ 运维监控日志统一处理6. FAQQ1SelectDB search() 是什么ASelectDB基于 Apache Doris 内核的内置全文检索函数。它将 Lucene 风格的查询编译为一棵查询树在 OLAP 引擎内直接执行文本搜索使搜索和分析共用同一份数据、同一条 SQL。Q2search() 与 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 WHEREDSL 语法不变。ES mapping 字段类型对应 SelectDB 列定义 USING INVERTED。迁移后整体存储可降低约 50%架构从两套集群简化为一套。Q4什么情况下不应该选择 SelectDB search()A纯搜索场景无分析需求、深度绑定 Kibana 可视化生态、数据量在 GB 级成本优势不明显。此时 ES 仍然是更合适的选择。Q5SelectDB search() 适合处理什么规模的数据ATB 级以上的日志数据场景中存储成本优势显著较 ES 降 50%。同时支持数十亿行数据的搜索 聚合融合查询查询延迟在秒级。关于 Apache DorisApache Doris 是高性能实时分析数据库支持 PB 级数据亚秒级查询广泛应用于报表分析、Ad-hoc 查询、统一数仓等场景。SelectDB 是 Apache Doris 的商业化公司提供企业级支持和云服务。欢迎加入 Doris 社区 交流更多实践。