【金仓数据库征文】给国产数据库装上中文搜索引擎，zhparser vs jieba 分词实战，和三个隐藏关卡

一、别把全文检索外包给 Elasticsearch很多系统一遇到中文模糊搜索的需求第一反应就是上一套 Elasticsearch。多部署一个集群多一条数据同步链路多一个运维负担。但对相当一部分场景来说这是杀鸡用牛刀。数据本来就在数据库里为什么不让数据库自己做搜索金仓KingbaseES的多模能力里藏着一个容易被忽略的模块内置中文全文检索。两款中文分词器zhparser 和 jieba加上 GIN 倒排索引、相关性排序、关键词高亮一套完整的搜索引擎基建全在数据库内部。这篇我在鲲鹏服务器上把它跑通对比两个分词器的真实差异顺便趟过三个不写出来你一定会中招的坑。二、两个分词器切出两个世界中文全文检索的第一道工序是分词把「金仓数据库管理系统」切成一个个词。英文靠空格天然分词中文没有空格全靠分词器。金仓内置了两款zhparser 是基于词性规则的分词器jieba 移植自著名的结巴分词走词典路线。拿三句话做对比大部分句子两边都切得对。比如经典歧义句「南京市长江大桥」两者都正确切成南京市、长江大桥没有切成南京、市长、江大桥。但有一句把两者的差异暴露得干干净净。原句: 金仓数据库管理系统 zhparser: 数据库:1 管理系统:2 ← 「金仓」不见了 jieba: 数据库:2 管理系统:3 金仓:1 ← 正确切出「金仓」zhparser 把「金仓」弄丢了。这个细节先记住第四节它要出大事。三、第一个坑||不是你以为的拼接准备语料建索引的时候我一头撞进了金仓 MySQL 兼容模式的经典陷阱。我要把标题加正文拼起来送进分词器顺手写了title || || body结果返回一个f。SELECT title || || body FROM articles WHERE id1; -- 结果: f SELECT concat(title, , body) FROM articles WHERE id1; -- 结果: 金仓数据库迁移实战 把 Oracle...在 MySQL 兼容模式下||是逻辑或不是字符串拼接。字符串||字符串被当成布尔运算结果是f假。这个坑要是没发现to_tsvector(jiebacfg, title|| ||body)实际是在给一个f分词生成的索引全是空的检索永远返回零结果而且全程不报一个错。正解是concat()。在金仓 MySQL 兼容库里做字符串拼接一律concat()永远别用||。改过来之后倒排索引正常建立12012 行文档就绪。四、召回生死线选错分词器内容整段消失现在回收第二节埋的伏笔。同一批语料同一个查询词「金仓」分别用 jieba 索引和 zhparser 索引检索。jieba 索引召回 5 篇含「金仓」的文章zhparser 索引召回 0 篇。零篇。原因正是第二节那个差异。zhparser 切不出「金仓」这个词索引里根本没有这个词条查询的时候「金仓」被当成停用词忽略召回自然是零。**一个词典缺失就能让整类内容在搜索里彻底消失。**选分词器从来不是配置细节是生死决策。对以专名、新词、行业术语为主的语料政务、金融、科技类内容尤其如此词典型的 jieba 通常是更安全的选择。五、GIN 倒排索引把全表扫描降到毫秒搜索引擎的另一半是索引。全文检索用的是 GIN 倒排索引和搜索引擎同源的数据结构。看实际效果在 12012 行文档里查一个低选择率组合向量 RAG。走 GIN 倒排索引: Bitmap Index Scan on idx_jieba → Execution Time: 1.9 ms 强制全表扫描: Seq Scan on articles → Execution Time: 4.7 msGIN 索引通过 Bitmap Index Scan 直接定位命中行比全表扫描快 2.5 倍。这还只是 1.2 万行的小库。数据量越大、命中越稀疏也就是越像真实搜索场景倒排索引的优势就放得越大。几百万文档里搜一个关键词GIN 是毫秒级全表扫描可能是秒级甚至更久。顺带一个我觉得挺有意思的观察。如果查询词命中率很高比如查「数据库」能命中 42% 的文档优化器会主动放弃索引改走全表扫描命中太多的时候索引反而不划算。金仓的优化器是懂全文检索代价的不是无脑用索引。六、排序与高亮搜索的最后一公里能搜到还不够好的搜索要把最相关的排前面把命中的词标出来。金仓两样都有。相关性排序靠ts_rank按关键词的词频、位置给文档打分。查数据库或迁移标题里同时命中两个词的《金仓数据库迁移实战》拿到 0.0684 的最高分排在第一相关度低的排后面。搜索结果里最相关的在第一条就是这么实现的。关键词高亮靠ts_headline把命中的词用标记包起来直接生成搜索结果里那段带高亮的摘要。第1篇: 业务系统平滑【迁移】到金仓零停机完成数据校验与回退。 第2篇: 提供 MySQL 兼容模式存量应用只需更换驱动即可【迁移】。第三个坑也埋在这里。我本想用round(ts_rank(...), 4)保留 4 位小数结果全部返回0.0000。又是 MySQL 兼容模式的函数差异round(小数, n)在这个模式下对纯小数返回 0改用::numeric(6,4)强制类型精度才正常。数一下这已经是本文撞上的第三个 MySQL 兼容模式的坑了字符串的||、round还有 tsvector 的||拼接操作符也一样被逻辑或覆盖。七、与 MySQL ngram 的正面对照金仓的词典分词和 MySQL 唯一的中文方案 ngram到底差在哪做一个对照实验就清楚了。查「据库」它是「数据库」的一个片段本身不是一个有意义的词。KES jieba: 召回 0 篇 ← 词典知道「据库」不是词精确地不匹配 MySQL ngram: 召回 4 篇 ← 「据库」是「数据库」里的合法二元组全部误召回这一刀下去两种机制的差别就露出来了。ngram 把文本切成固定长度的字符片段默认 2 字不理解词义。好处是不需要词典、召回全代价是噪声大「据库」这种无意义片段也匹配索引体积还大。词典分词基于词典理解词边界精度高、索引小代价是依赖词典质量。没有绝对的优劣只有场景适配。但有一点是实打实的金仓两种都给你词性型的 zhparser 加词典型的 jieba你可以按语料特性选而 MySQL 只有 ngram 一种。多模融合这个词落到全文检索场景里真实含义就是这种给足选择的能力。八、结论我用金仓内置的能力给数据库装上了一个像模像样的中文搜索引擎。两款分词器可选GIN 倒排索引毫秒级检索相关性排序关键词高亮没有引入任何外部组件。这趟实战最想留下两句话。第一句分词器的选择是搜索的生死线。jieba 召回 5 篇zhparser 召回 0 篇一个词典差异就能让整类内容从搜索里消失选型必须拿真实语料实测不能看文档拍板。第二句MySQL 兼容不等于完全一样。||、round这些运算符和函数的语义差异会静默地毁掉你的功能而且不报错。涉及它们的地方永远亲手验一遍。至于还在纠结要不要为了中文搜索再上一套 ES 的团队我的建议是先看看金仓自己能不能扛下来。很多时候答案是能。数据不用搬家搜索就在原地发生。这也是国产数据库多模融合给出的一个务实答案。