Solr配置文件分析与验证

前面一篇开始学习solr的时候,做了个入门的示例http://blog.csdn.net/zjc/article/details/24414271 。虽然可以检索出内容,但总和想象的结果有差异——比如,检索“天龙”两个字,按常规理解,就应该只出来《天龙八部》才对,可是竟然也会把《倚天屠龙记》检出来。后来研究了一下,发现系统是这样处理的:无论是抽索引时还是分析检索词时,都把所有文字按单字拆开。这样,刚好《倚天屠龙记》里包含“天”和“龙”。于是对照solr的配置文件schema.xml做了一些分析和验证。下面来看一下:

在schema.xml里,对检索结果有最直接影响的有这么几项:

<solrQueryParserdefaultOperator="OR"/>

这一行在文件较靠后的位置,但我最先拿出来说。这表示,对拆分后的检索词是按照“且”还是“或”的关系选定结果。默认是OR,可以改成AND。象前面例子,如果再有一本《天天向上》,也一样会被检索出来。因为包含了“天”字。那就差的更远了。所以如果采用这个默认的单字拆分法,那最好是用AND,否则结果就太乱了。

好了,假定我们改成了AND,那么结果是《天天向上》没有了,但《倚天屠龙记》还在的。因为既有“天”又有“龙”,说明单字拆分法有不足之处。

决定这个单字拆分法的是谁呢?仔细检查文件,我们发现这一行:

<field name="name"type=" text_general" indexed="true"stored="true"/>

表示name这个字段是text_general类型的。这就靠谱了,多半text_general类型的处理方式就是单字拆分。

有没有更好的分词方法呢,当然有,而且肯定不止一种。我按照网上的例子采用了mmseg4j。使用方法很简单,把解压后的几个jar文件放到classpath目录下。然后在schema.xml里增加下面几行:

<fieldType name="textComplex"class="solr.TextField" positionIncrementGap="100" >

<analyzer>

<tokenizerclass="com.chenlb.mmseg4j.solr.MMSegTokenizerFactory"mode="complex" dicPath="./dic"/>

<filter class="solr.LowerCaseFilterFactory"/>

</analyzer>

</fieldType>

<fieldTypename="textMaxWord" class="solr.TextField"positionIncrementGap="100" >

<analyzer>

<tokenizer class="com.chenlb.mmseg4j.solr.MMSegTokenizerFactory"mode="max-word" dicPath="./dic"/>

<filterclass="solr.LowerCaseFilterFactory"/>

</analyzer>

</fieldType>

<fieldType name="textSimple"class="solr.TextField" positionIncrementGap="100" >

<analyzer>

<tokenizerclass="com.chenlb.mmseg4j.solr.MMSegTokenizerFactory"mode="simple" dicPath="./dic"/>

<filterclass="solr.LowerCaseFilterFactory"/>

</analyzer>

</fieldType>

这里定义了三种fieldType,分别是textComplex、textMaxWord、textSimple。名称无所谓,重要的是子元素定义了分词器和过滤器使用的类:com.chenlb.mmseg4j.solr.MMSegTokenizerFactory、solr.LowerCaseFilterFactory。其实三种用的类是相同的,只是后面有个mode不同。

这里只是定义了分词类型,我们要把这个分词类型应用到我们的数据里才行。所以,要把<field name="name" type="textSimple"indexed="true" stored="true"/> ——我这里改成了textSimple 。在fieldType和fieldname的共同作用下,我们终于可以完成中文习惯上的分词了。当然要重新运行代码,重新抽索引才行,而且字段name里得有东西(参考上一篇的代码)。

搜索“name:天龙”,结果为空。这又是怎么回事呢?难道又错了?其实如果想看分词效果,solr的管理端有个分析工具很好用。

进到分析页面,上面输入字段名称name,下面输入文本,看一下它倒底是怎么分的

原来textSimple方式把“天龙八部”作为一个整词了,难怪我们搜“天龙”没结果,再搜“天龙八部”,有结果了。晕,这也太不符合习惯了。少字没结果,多字反倒有结果。接着,我们再换一种试试:

<field name="name" type="textMaxWord"indexed="true" stored="true"/> name字段用textMaxWord类型,这表示采用最大化分词的方式。再来分析一下:

这回差不多了,“天龙八部”被分成“天龙”“八”“部”三个词。搜索这三个词都有结果了,而且是唯一结果。

换个搜索写法:

不写name:天龙,直接写天龙。晕死,倚天屠龙记又出来了。接着看schema.xml:

<defaultSearchField>text</defaultSearchField>

这表示默认搜索字段,如果前面什么都不写,就到text里去查找。而text怎么定义的呢?再找:

<field name="text" type="text_general"indexed="true" stored="false"multiValued="true"/>

果然,又回到text_general来了,还是单字拆分法。

等等,回忆一下,我们并没有text这个字段啊(参考上一篇代码),我们只录入了三个字段id、name、price,这个text是谁?继续找,在这里——

<copyField source="cat"dest="text"/>

<copyField source="name"dest="text"/>

<copyField source="manu"dest="text"/>

<copyField source="features"dest="text"/>

<copyField source="includes"dest="text"/>

这几行表示,把cat、name、manu、features、includes都作为text看待(一般是为提供通用检索或简单检索功能用的),text是text_general类型的,还是默认的。所以不写条件时当然又回到单字查找法了。

总结一下:

这5个元素交互作用,最终共同影响着搜索结果。

fieldType:定义了可选的类型,当然定义了未必就用

field:定义了某个字段具体是什么fieldType的

copyField:提供了一个同时查找多个字段的简便方法

defaultSearchField:定义了不写字段条件时的查找范围

solrQueryParser defaultOperator:定义了各分词之间采用什么逻辑组合

Solr配置文件分析与验证

时间: 2024-10-18 17:25:33

Solr配置文件分析与验证的相关文章

Solr文本分析剖析【文本分析、分词器详解、自定义文本分析字段及分词器】

一.概述 Solr文本分析消除了索引词项与用户搜索词项之间的语言差异,让用户在搜索buying a new house时能找到类似的内容,例如:purchasing a new home这样的文档.如果搭配恰当,文本分析就能允许用户使用自然语言进行搜索,而无需考虑搜索词项的所有可能形式.毕竟谁也不想看到为了相似搜索而构造这样的查询表达式:buying house OR purchase home OR buying a home OR purchasing a house .... 用户可以使用

nginx.conf配置文件分析

#总结一下nginx.conf文件内容. #运行用户 user www-data; #启动进程,通常设置成和cpu的数量相等 worker_processes  1; #全局错误日志 error_log  /var/log/nginx/error.log; #进程文件 pid        /var/run/nginx.pid; #一个nginx进程打开的最多文件描述符数目,理论值应该是最多打开文件数(系统的值ulimit -n)与nginx进程数相除,但是nginx分配请求并不均匀,所以建议与

Sphinx配置文件分析

#在Sphinx配置文件中,主要包括五个部分:source部分.index部分.searchd部分.indexer部分和common部分(前四部分比较重要): #source是数据源,index负责定义索引,searchd负责定义searchd守护进程的相关选项,indexer负责定义生成索引的过程中索引的功能性限制: #在数据源source中,type指定数据库的类型,目前Sphinx只支持两种类型的数据库,一种是MySQL: #sql_host指定主机,sql_user和sql_pass对应

Solr 配置文件之schema.xml

schema.xml这个配置文件的根本目的是为了通过配置告诉Solr如何建立索引. solr的数据结构如下: document:一个文档.一条记录 field:域.属性 solr通过搜索某个或某些field,返回若干个符合条件的document,或者按搜索的score排序返回. 如果跟数据库对比,document相当于数据库的表,field相当于表中的字段.而schema.xml就是为了定义一个表的结构(定义各个field的名字.类型.约束.等等). schema.xml的基本结构如下: <sc

Linux环境变量设置中配置文件分析(/etc/profile,~/.bashrc等)(转)

说明:在研究中发现,对于不同版本的Linux系统有着不同的文件,但是总的入口是不变的/etc/profile,下面只是展示加载顺序的研究过程,所以会有些系统没有这个文件等问题. 一.配置文件与作用域: 1.系统级别: /etc/environment:在登录时操作系统使用的文件,系统在读取profile前,设置环境文件的环境变量. /etc/profile:此文件为系统的每个用户设置环境信息,当用户第一次登录时,该文件被执行.并从/etc/profile.d目录的配置文件中搜集shell的设置.

Redis配置文件分析

#Redis演示示例配置文件 # 注意单位问题:当须要设置内存大小的时候,能够使用类似1k.5GB.4M这种常见格式: # # 1k=> 1000 bytes #1kb => 1024 bytes # 1m=> 1000000 bytes #1mb => 1024*1024 bytes # 1g=> 1000000000 bytes #1gb => 1024*1024*1024 bytes # # 单位是大写和小写不敏感的,所以1GB 1Gb 1gB的写法都是全然一样的

Linux用户管理-配置文件分析

Linux是个多用户多任务的分时操作系统,所有一个要使用系统资源的用户都必须先向系统管理员申请一个账号,然后以这个账号的身份进入系统.用户的账号一方面能帮助系统管理员对使用系统的用户进行跟踪,并控制他们对系统资源的访问:另一方面也能帮助用户组织文件,并为用户提供安全性保护.每个用户账号都拥有一个惟一的用户名和用户口令.用户在登录时键入正确的用户名和口令后,才能进入系统和自己的主目录. 配置文件: 用户信息文件:/etc/passwd 密码文件:/etc/shadow 用户组文件:/etc/gro

vue-cli的webpack模板项目配置文件分析

由于最近在vue-cli生成的webpack模板项目的基础上写一个小东西,开发过程中需要改动到build和config里面一些相关的配置,所以刚好趁此机会将所有配置文件看一遍,理一理思路,也便于以后修改配置的时候不会"太折腾". 一.文件结构 本文主要分析开发(dev)和构建(build)两个过程涉及到的文件,故下面文件结构仅列出相应的内容. ├─build │ ├─build.js │ ├─check-versions.js │ ├─dev-client.js │ ├─dev-ser

hibernate配置文件分析

<!--标准的XML文件的起始行,version='1.0'表明XML的版本,encoding='gb2312'表明XML文件的编码方式--> <?xml version='1.0' encoding='gb2312'?> <!--表明解析本XML文件的DTD文档位置,DTD是Document Type Definition 的缩写,即文档类型的定义,XML解析器使用DTD文档来检查XML文件的合法性.--><!--hibernate.sourceforge.ne