关于我的开源项目JBOX跟LUCENE的区别

有朋友问到，我的这个项目跟LUCENE的区别，下面说说。

开发这个之前我也考虑过LUCENE，但在仔细看了LUCENE之后，有4个地方让我觉得不舒服，于是突然就萌生了想自己做一个这样的东西出来的想法。

1. LUCENE本身只是一个检索框架，需要做成完整的搜索引擎的话还需要再去学NUTCH，然后再去研究两者之间的整合，这过程理解起来不容易；
2. LUCENE对数据库的支持度不好，虽说有数据库扩展包，但LUCENE主页上的FAQ也说了，并不理想。而对于大规模数据我比较倾向于数据库，所以在当时在看LUCENE时第一想法其实是能不能开发一个更好的基于数据库扩展包，不过后来发现这个扩展好复杂。
3. LUCENE对中文的支持度不够(虽然有很多人做了中文的扩展就是了）；
4. 最后一点，也是让我最不舒服的一点，LUCENE的源代码，如果有看的人应该可以发现，很多地方并不是很符合面向对象的，看起来很费劲，也很难理解。例如，因为我英文语法不行，所以英文分析参照了LUCENE（org.apache.lucene.analysis.PorterStemmer这个类），发现LUCENE的处理方法是传入一个字符串后，定义全局变量做下标，利用全局下标在字符串之间移动处理（其中还有一些方法是单纯用于移动下标的，意义不明……）。很难表达我当时那种感觉，总之，感觉很别扭，不自在。或许这样做可以提高分词的性能，但我还是比较喜欢面向对象的处理方法；

在之后做JBOX的时候，就是根据上面对LUCENE不满的地方做的。
1. JBOX最首要的目的，是简单。要让开发变得更简单，个人认为，这是框架的首要责任。当然，或许目前我这个作品可能依然不够简单性，在后续的版本我会继续努力改进。
2. JBOX第二个目的是纯粹的面向数据库。因为相信有很多人跟我一样，应用程序都习惯搭建在数据库上，由其是大规模的数据。目前的版本中，持久层是用HIBERNATE做的，这影响了存储索引时的效率，我在尝试写存储过程来代替HIBERNATE在存储的部分的功能，以提高效率，后续的版本会追加这一点；
3. JBOX分词的出发点不是西方文字，而是中文（毕竟还是母语熟悉，其他语言的分词好难懂，呜呜……）。分词部分完整的我没有看LUCENE怎么实现，JBOX的实现方式是利用责任链对多语言文本进行切词，虽然目前仅实现了英文跟中文就是了。（德文的切法正在看LUCENE的实现中，就如上面所说的，难懂……）；
4. JBOX的结构是尽量按面向对象的思想设计的，目前我还在继续改进中。其实如果单单只是要搜索引擎的功能，3个月前我就已经做好了。但为了让其结构更容易理解，更容易扩展，更加贴近面向对象，这个过程整整消耗了我3个月时间。（想想真很辛苦，我也要上班养活自己，时间都是挤出来的，唉。）；
5. 最后，类似google那样相关词搜索的功能，LUCENE没有吧？这个就如我上面帖子里说的，我已经实现了，只是还没整理。相关算法的论文也在审稿中，9月15号后才能知道结果（编辑部回答时15号后在问，没说15号后多少，呜……）；

最后，JBOX当然不可能代替LUCENE，我也没那么自大去做这种事。例如LUCENE在文件索引，数据库索引方面我是暂时没打算做的。JBOX的当前目的只是，网站上的搜索引擎，其他的检索还是要LUCENE。