不选择使用Lucene的6大原因

Lucene是开放源代码的全文搜索引擎工具包，凭借着其强劲的搜索功能和简单易用的实现，在国内已经很普及，甚至一度出现了言搜索必称Lucene的盛景。上个月Lucene的开发团队发布了 Java Lucene 2.3.1 ，相信很多朋友们都用上了。在国内对Lucene的介绍可以分为3块儿：


第一类是：以车东 的Lucene：基于Java的全文检索引擎简介 为代表的基础入门介绍；
第二类是Lucene倒排索引原理和Lucene软件包、实现类的介绍；
第三类是以中文分词为中心的介绍；

任何一个软件，包括所有伟大的软件都有这样或者那样的“缺点”和各自适用的领域，Lucene也不例外。在国内对Lucene这个软件包的批评，似乎没有看到过。可能大家都忙于做项目，纵然Lucene有再大的缺陷，凭借着Lucene良好的口碑，也不会说上一句不是。

今天在阅读LingWay （一个做垂直的语义搜索引擎）的CTO Cedric Champeau 先生的博客是发现有一篇题为：Why lucene isn't that good 为什么Lucene并不是想象的那么棒 的文章：Champeau 开门见山指出了Lucene的6大不足之处，鉴于 Lingway 公司使用Lucene已有好几年的历史，我相信Cedric Champeau的对Lucene的评论还是值得一读。

不选择使用Lucene的6大原因：

6、Lucene 的内建不支持群集。
Lucene是作为嵌入式的工具包的形式出现的，在核心代码上没有提供对群集的支持。实现对Lucene的群集有三种方式：1、继承实现一个 Directory；2、使用Solr 3、使用 Nutch+Hadoop；使用Solr你不得不用他的Index Server ，而使用Nutch你又不得不集成抓取的模块；

5、区间范围搜索速度非常缓慢；
Lucene的区间范围搜索，不是一开始就提供的是后来才加上的。对于在单个文档中term出现比较多的情况，搜索速度会变得很慢。因此作者称Lucene是一个高效的全文搜索引擎，其高效仅限于提供基本布尔查询 boolean queries；

4、排序算法的实现不是可插拔的，因为贯穿Lucene的排序算法的tf/idf 的实现，尽管term是可以设置boost或者扩展Lucene的Query类，但是对于复杂的排序算法定制还是有很大的局限性；

3、Lucene的结构设计不好；
Lucene的OO设计的非常糟，尽管有包package和类class，但是Lucene的设计基本上没有设计模式的身影。这是不是c或者c++程序员写java程序的通病？

A、Lucene中没有使用接口Interface，比如Query 类( BooleanQuery, SpanQuery, TermQuery...) 大都是从超类中继承下来的；

B、Lucene的迭代实现不自然： 没有hasNext() 方法, next() 返回一个布尔值 boolean然后刷新对象的上下文；

2、封闭设计的API使得扩展Lucene变得很困难；