关于搜索开发过程中的总结

1、我想索引文件损坏并不是因为文件没有被关闭,而是在更新索引的时候程序中断的,造成了文件的不完整,才会导致索引文件的损坏的问题--针对IndexWriter没有正常关闭的问题，如果是索引数据写入完毕，最后没有关闭，只会导致索引文件被锁，而不会造成数据的损毁，数据的损毁是在写入的过程中程序突然异常而造成了写入数据的不完整而造成的

 

2、3.0确实取消了2元分词，因为对未知词使用2元切分，在召回率上存在一些问题。新的切分算法配合IKQueryParser是能达到很好的搜索效果的，试试看！ --ik3.0版本去掉了针对陌生词的二元分词

 

3、在频繁建索引后，一定记得固定时间要优化索引，比如每天的凌晨1点。--刚开始我写的程序是每写入一次就优化一次的，看来应该将优化放置在晚上进行

 

4、构建实时的索引两种策略，一种是按照每隔一段时间建一次，另一种是判断内存，当内存吃到一定程度了，就写入一次。

 

5、用户搜索*中国*，分词器会怎么处理? 看你用的查询分析器了，如果使用IKQueryParser的话，会帮你过滤掉。但如果使用Lucene自带的parser，就可能被解析为通配符了--有道理

 

6、lucene是按照分词切分的结果进行完整匹配查询的， "硬盘驱动器"被切分成“硬盘”“驱动”“驱动器”，但没有“硬" 和 "盘"，（那样是单字切分），因此搜索不到，这个是lucene的基础概念，切记。 

 

7、如果你需要顾虑stopword，需要直接应用IKSegmentor，并加入自己stopfilter，构造一个新的Analyzer。你可以看一看lucene自带的standardAnalyzer的源代码，就知道了--当前记下，以后用到了是个思路

 

8、解释一下，IK3.0为啥不对汉字进行stopword过滤。 

1。IK的核心分词类IKSegmentor的功能是最细化的识别所有的词汇，包括敏感词汇。 

2.对未知的姓名，地面，专有名词，采用单字切分，这样有利于搜索。 

3.对任何的汉字切分结果，IK3.0不做任何“无用词”的假设。如：在佛经中出现的梵文可能被单字切分出大量的拟声词。这些都不能被做为“无用词”过滤。

4.IK推荐用户在各种的专有领域建立自己的停止词库，并建立自己的analyzer实例。 

--关于ik的老大的一些解释，有用

 

9、我觉得你这个需求是为杜撰而杜撰的，首先就与中文的特性违背了。每种语言都有它的切分特性，英文是通过空格分隔，而中文的特性我们采用了词库。这就意味着当“硬盘”是一个词语的时候，“硬”与“硬盘”在词义上是毫无关系的。 

分词器只可能尽可能适应于中文的常规语法切分，而不可能你想怎么分就怎么分。 lucene索引的特性也决定了它的最高效率是“完全索引匹配”，当然你可以使用“前缀匹配”，但这个与lucene的倒排索引设计理念是背道而驰的。--解释的大意同6

 

10、不要强制kill建索引的程序，强制kill很有可能导致索引坏掉，每次关闭前必须保证所有的IndexWriter已经正常的关闭。这点我已经体会到了：我想构建一个可以重用的indexwriter，结果强制kill程序，索引文件被锁了

 

11、如果要做读写分离。同步索引数据要按如下步骤进行：a.停止所有建索引的程序。b.IndexWriter.commit() c.优化所有索引 d。最后再coping or rsyncing。

 

12、每个Document最好都分配一个唯一key，这个key可以是数据库里每个唯一键，也可以是多个字段的组合。用于更新和删除索引--多添加一个field，我选择用数据库当中的唯一键

 

13、把需要更新很频繁的索引和更新不频繁的索引分离成两个目录（要有良好、严密的方案）

 

14、Filter
filter 的作用就是限制只查询索引的某个子集，它的作用有点像SQL语句里的where，但又有区别，它不是正规查询的一部分，只是对数据源进行预处理，然后交给查询语句。注意它执行的是预处理，而不是对查询结果进行过滤，所以使用filter的代价是很大的，它可能会使一次查询耗时提高一百倍。

 

15、关键词区分大小写
or AND TO等关键词是区分大小写的，lucene只认大写的，小写的当做普通单词。

 

16、文件锁
在写索引的过程中强行退出将在tmp目录留下一个lock文件，使以后的写操作无法进行，可以将其手工删除

 

17、时间格式
lucene只支持一种时间格式yyMMddHHmmss，所以你传一个yy-MM-dd HH:mm:ss的时间给lucene它是不会当作时间来处理的

 

18、分词的缺失
比如同义词。用户搜 "北京 饭店" 能不能把" 首都 饭店"也列出来呢？ 这个分词器无能为力。所以这个问题，解决办法就只能是在分词之前，我们再加一层：同义词返回模块。这个思路很不错，也比较简单，很容易实现。关键是词库的建立。

 

19、消除歧义
例如：我还清晰地记得我们坐在江边聊天的情境。
分出来是： 我 还清 晰 地 记得 我们 坐在 江边 聊天 的 情境。
结果： 清晰 被拆开了。
这个是基于词库的分词算法固有的问题。没有很好的解决方法。有统计结果表明，单纯使用正向最大匹配的错误率为1/169，单纯使用逆向最大匹配的错误率为1/245。有一种解决方案是正向匹配结果后再逆向匹配一次，然后比较结果，消除歧义。最好加入词汇概率统计功能.有歧义的用概率决定。

 

20、最大匹配的问题
比如搜索“三季度”这个词，词库里同时有 “三季度” 和 “季度”这两个词，分词时按最大正向匹配 则 “三季度” 被分成一个完整的词，按 “季度” 去检索反而搜不出来了。
解决办法：缩短分词粒度，当字数等于或超过该粒度参数，且能成词，该词就被切分出来。

 

21、新词识别
      新词，也就是那些在字典中都没有收录过，但又确实能称为词的那些词。最典型的是人名，人可以很容易理解句子“王军虎去广州了”中，“王军虎”是个词，因为是一个人的名字，但要是让计算机去识别就困难了。如果把“王军虎”做为一个词收录到字典中去，全世界有那么多名字，而且每时每刻都有新增的人名，收录这些人名本身就是一项巨大的工程。即使这项工作可以完成，还是会存在问题，例如：在句子“王军虎头虎脑的”中，“王军虎”还能不能算词？
     新词中除了人名以外，还有机构名、地名、产品名、商标名、简称、省略语等都是很难处理的问题，而且这些又正好是人们经常使用的词，因此对于搜索引擎来说，分词系统中的新词识别十分重要。目前新词识别准确率已经成为评价一个分词系统好坏的重要标志之一。

 

22、对不同的 field 使用不同的分词器是一个可以考虑的方法。比如 tag 字段，就应该使用一个最简单的分词器，按空格分词就可以了。问题的关键是搜索的时候如何保证创建索引时和查询语句的分词器一致的问题？需要么？--需要考虑