开源全文搜索引擎框架JBOX-beta版发布

天刚完成的，做了好久了。一个纯java的全文搜索引擎框架。

做这个的目标是，更简单，更容易，以至任何一个懂java的人都可以很容易地搭建一个个人用的搜索引擎，例如个人站点的站内搜索。

主页：http://j-box.sourceforge.net/index_cn.html
API文档、QUICK START都有。

Jbox目前是beta版本，如果各位朋友发现bug了，麻烦发邮件到j-box-user@lists.sourceforge.net（如果发不成功，则发到yibin_h@users.sourceforge.net ，mailing list刚开通，还不大会用--!)，谢谢了^_^

主页地CVS功能目前还没开通——sourceforge的CVS管理好复杂@_@...

有朋友问起，是否有像现在的GOOGLE一样输入一个词，给出相应相关词的功能。
是有的，不过不是像google一样是给出同一个词的各种组合，而是根据语义给出最相关的词。这个有一套相关性算法的，我的毕业设计做的就是那个。我的论文目前投到《中文信息学报》，还不知道审稿结果。因为没什么时间，那一部分的代码现在还没有整理出来，后续的版本会追加上去。

无论好与坏，可以的话希望能给点意见，我需要大家的意见来做进一步的改进和开发啊！谢谢了！

有朋友问到，我的这个项目跟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。

全新开发的啊！不是用了LUCENE的API!

1. LUCENE本身只是一个检索框架，需要做成完整的搜索引擎的话还需要再去学NUTCH，然后再去研究两者之间的整合，这过程理解起来不容易；
JL:可以不学nutch，自己写个爬虫。一些公司的几个爬虫都是自己写的。精确度比较好。属于垂直类的爬虫。


2. LUCENE对数据库的支持度不好，虽说有数据库扩展包，但LUCENE主页上的FAQ也说了，并不理想。而对于大规模数据我比较倾向于数据库，所以在当时在看LUCENE时第一想法其实是能不能开发一个更好的基于数据库扩展包，不过后来发现这个扩展好复杂。
JL:大规模数据用数据库？多大的规模呢？google没用。是否需要支持数据库，lucene世界一直有两种看法。支持人数少的那部分认为需要支持数据库，多的认为没必要。


3. LUCENE对中文的支持度不够(虽然有很多人做了中文的扩展就是了）；
中文分词的确比较难找合适的。收费的有不错的。


4. 最后一点，也是让我最不舒服的一点，LUCENE的源代码，如果有看的人应该可以发现，很多地方并不是很符合面向对象的，看起来很费劲，也很难理解。
JL:呵呵，我和你看法不同。

我欣赏你自己开发，但我没那么多时间去读源代码，也没时间做小白鼠。

如果你能分享你的设计心得，那么我想会很乐意的学习下。

谢谢imjl的关注^_^

1.就像我在帖子里一开始就说的，JBOX的目的是简单，易用，这也是我设计时考虑的最首要因素。LUCENE从开始学，到知道要如何自己写一个爬虫不那么容易吧？我想各自定位的不一样。JBOX的扩展没那么复杂，实现一个Spider接口里2个方法（boolean hasNext()、Page Next()）,在配置文件指定自己所扩展的Spider就完事了。

2.不过有没有必要，我想既然有人有这个需要，那么做出来就是有意义的了。PS:LUCENE的索引技术确实很强大，我是非常敬佩作者那样的设计的。

3.对这一点我一直有点恼火，国内很多东西，动不动就收钱。不过一个算法，就沾沾自喜，等着钱，钱。技术共享、交流的精神这些人一点都没体会到……？

4.JL要是看的很顺，可以的话，有时间能否把LUCENE分词的设计整理出来共享下？可能我水平不够，看到眼痛啊……

设计心得的话，没个底，不知道讲啥……

最近我也在看这方面的东西, 欣赏楼主的态度,有时间学习一下

你用的算法是？？

你指的哪方面的算法？JBOX当前版本里各个模块接口提供的实现的算法：
Spider： 广度优先算法；
切词： 正向最大匹配；
索引： 反序索引；
排序： 计算TFIDF，简单的根据TFIDF排序。

目前如果需要更好的实现只能自己去实现接口，在后续的版本会逐步改善各个模块。
我的时间不多，没办法一次性全部做的很完美(如果有朋友有兴趣一起来参与这个项目就好了^_^)。