给全文搜索引擎Manticore (Sphinx) search 增加中文分词
Sphinx search 是一款非常棒的开源全文搜索引擎,它使用C++开发,索引和搜索的速度非常快,我使用sphinx的时间也有好多年了。最初使用的是coreseek,一个国人在sphinxsearch基础上添加了mmseg分词的搜索引擎,可惜后来不再更新,sphinxsearch的版本太低,bug也会出现;后来也使用最新的sphinxsearch,它可以支持几乎所有语言,通过其内置的ngram tokenizer对中文进行索引和搜索。
但是,像中文、日文、韩文这种文字使用ngram还是有很大弊端的:
当Ngram=1时,中文(日文、韩文)被分解成一个个的单字,就像把英文分解成一个个字母那样。这会导致每个单字的索引很长,搜索效率下降,同时搜索结果习惯性比较差。
当Ngram=2或更大时,会产生很多无意义的“组合”,比如“的你”、“为什”等,导致索引的字典、索引文件等非常大,同时也影响搜索速度。
基于以上弊端,为中日韩文本加入分词的tokenizer是很有必要的。
于是决定来做这件事。先去Sphinxsearch网站去看看,发现它已经发布了新的3.x版本,而且加入了很多很棒的特性,然而它从Sphinxsearch 3.x 开始,暂时不再开源. 不过,部分前Sphinxsearch的开发人员跳出来成立新团队,在Sphinx 2.x版本基础上开发自己的Manticoresearch。这两者很像,从它们的名字就可以看出来,这俩都是狮身怪兽。
Sphinx 是(古埃及)狮身人面像,Manticore 是(传说中的)人头狮身龙(蝎)尾怪兽
Manticoresearch 从Sphinxsearch 继承而来, 并做了性能优化. 因此,我选择了Manticoresearch 来添加中日韩分词。
首先从Manticoresearch的github仓库pull最新的代码来谈价,后面我也会尽力与Manticoresearch的主分支保持同步。
算法实现
算法基于字典,具体是cedar的实现的双数组trie。cedar是C++实现的高效双数组trie,也是分词字典的最佳之选。cedar的协议是GNU GPLv2, LGPLv2.1, and BSD;或者email联系作者所要其它协议。
通过最小匹配(而非单字)来匹配字典和字符串,把字符串分割成最短(而非单字)的词。如果遇到处理不了的歧义时,以单字做词。这样的目的是,保证搜索时能找到这些内容而不丢失。
稍微解释一下,对于搜索引擎的分词为什么这么做:
- 搜索引擎要能找到尽可能全内容:最彻底的方法是ngram=1,每个字单独索引,这样你搜索一个单字“榴”时,含有“榴莲”的文本会被找到,但缺点就如前面所说。
- 搜索引擎要能找到尽可能相关的内容: 分词就是比较好的方法,对词进行索引,这样你搜索一个单字“榴”时,含有“榴莲”的文本就不会被找到。但分词的粒度要小,比如“编程语言”这是一个词组,如果把这个分成一个词,你搜索“编程”时,就找不到只含“编程语言”的文本,同样的,“上海市”要分成“上海”和“市”,等等。所以,“最小匹配”适用于搜索引擎。
编译安装
从github仓库manticoresearch-seg获取源码,编译方法跟Manticoresearch一样,具体看官方文档。
使用方法
1. 准备词表 把所有词写到一个txt文件,一行一个词,如下所示:
# words.txt 中文 中国語 중국어
2. 创建字典 成功编译代码后,就会得到创建字典的可执行程序make_segdictionary
. 然后执行命令:
./make_segdictionary words.txt words.dict
这样就得到了字典文件: words.dict
3. 配置索引 只需在配置文件的 index {...}
添加一行即可:
index { ... seg_dictionary = path-to-your-segmentation-words-dictionary ... }
提醒: 分词对批量索引和实时索引都起作用。
吐槽
添加分词最初的想法是,我的代码作为新增文件加入项目,只在原有文件个别处添加就好。这样做分得比较清楚,后面对manticore官方仓库提交代码也比较清晰。于是就尝试这样做。
然而,Sphinx的代码组织的真是有点乱,Manticore沿用Sphinx的代码所以架构是一样的。最大的一个cpp文件sphinx.cpp 竟然有3万多行代码,很多类的声明直接放在这个.cpp 文件里面,而没有放到头文件sphinx.h里面。 因为我实现的分词tokenizer必须要继承它的类保持接口一致。尝试着把cpp文件的一些声明移到.h文件,结果是越移越多,要对原始文件做很大改动,甚至可能要重新架构源代码。不是不可以重新架构,一来会很费时间,二来向官方提交代码很难被接受,三是跟官方代码保持同步就很费劲,最终还是在原来sphinx.cpp文件中添加分词tokenizer: CSphTokenizer_UTF8Seg 。
当然,Sphinx的代码的类的继承关系比较清晰,继承原来的tokenizer实现新的也不算费事,修改了4个源码文件就添加好了分词tokenizer。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
剖析Hadoop和Spark的Shuffle过程差异(一)
一、前言 对于基于MapReduce编程范式的分布式计算来说,本质上而言,就是在计算数据的交、并、差、聚合、排序等过程。而分布式计算分而治之的思想,让每个节点只计算部分数据,也就是只处理一个分片,那么要想求得某个key对应的全量数据,那就必须把相同key的数据汇集到同一个Reduce任务节点来处理,那么Mapreduce范式定义了一个叫做Shuffle的过程来实现这个效果。 二、编写本文的目的 本文旨在剖析Hadoop和Spark的Shuffle过程,并对比两者Shuffle的差异。 三、Hadoop的Shuffle过程 Shuffle描述的是数据从Map端到Reduce端的过程,大致分为排序(sort)、溢写(spill)、合并(merge)、拉取拷贝(Copy)、合并排序(merge sort)这几个过程,大体流程如下: 上图的Map的输出的文件被分片为红绿蓝三个分片,这个分片的就是根据Key为条件来分片的,分片算法可以自己实现,例如Hash、Range等,最终Reduce任务只拉取对应颜色的数据来进行处理,就实现把相同的Key拉取到相同的Reduce节点处理的功...
- 下一篇
深入理解Java中方法的参数传递机制
形参和实参 我们知道,在Java中定义方法时,是可以定义参数的,比如: public static void main(String[] args){ } 这里的args就是一个字符串数组类型的参数。 在程序设计语言中,参数有形式参数和实际参数之分,先来看下它们的定义: 形式参数:是在定义函数名和函数体的时候使用的参数,目的是用来接收调用该函数时传入的参数,简称“形参”。 实际参数:在主调函数中调用一个函数时,函数名后面括号中的参数称为“实际参数”,简称“实参”。 举个栗子: public class ParamTest { public static void main(String[] args) { ParamTest pt = new ParamTest(); // 实际参数为“张三” pt.sout("张三"); } public void sout(String name) { // 形式参数为 name System.out.print(name); } } 上面例子中,ParamTest类中定义了一个sout方法,该方法有个String类型的参数name,该参数即为形参...
相关文章
文章评论
共有0条评论来说两句吧...