在
Java平台上面，lucene是众望所归的全文检索工具，lucene性能不俗，
程序稳定，第三方扩展和分词算法众多，但是在
RoR方面，就没有那么幸运了，
JavaEye网站要做全文检索，怎么来解决全文检索的问题呢？
在ruby平台上面，全文检索有三个途径：
1、solr, acts_as_solr
solr是apache
开源组织的一个
项目，完全基于lucene的最新版本，在lucene的上层提供了一个基于HTTP/
XML的
Web Services。solr的发行包自己绑定了jetty6.0应用
服务器，可以直接启动，成为一个独立的全文检索的web服务。
由于和solr的通讯方式是标准的基于HTTP的XML，所以你可以使用任何编程
语言，Java，C++，Ruby，
Python都不在话下。你通过向solr发送xml查询请求，让solr在后台运行lucene，返回结果也被封装为xml，当然你也可以让solr去做索引。基本上solr就是lucene的一个Web服务的封装。solr的优势在于为大规模的全文检索做了很多缓存优化，由于采用xml，也不限于客户端的种类。
RoR有一个叫做acts_as_solr的插件，封装了ruby对solr的访问，如果你喜欢用solr作为全文检索，acts_as_solr是一个不错的选择，他可以很方便的让你的RoR应用添加全文检索功能，考虑到lucene的稳定性，这个方案是一个相当不错的选择。
但是这个方案的缺点也是显而易见的，你的RoR应用所有的全文检索都要依赖后台再次向solr服务器发送web请求来获取结果，单个页面的执行速度肯定会受限于后台的跨http的web请求，这对于那些对全文检索功能依赖特别多的网站来说，恐怕很难接受。因此JavaEye3.0不采用solr方案。
2、sphinx
http://robbin.javaeye.com/blog/122696
我已经在上一篇
博客当中介绍了sphinx。我个人非常青睐sphinx这种独立的第三方全文检索服务器，而且能够和My
SQL结合的很好，更不用说其优异的性能了。但是sphinx的缺点在于没有很好的分词扩展的接口，它是一个纯C
开发的服务。这对于
中文分词功能的支持来说，就很难实现了，因此不得不遗憾的放弃。
3、ferret
ferret是ruby平台模仿lucene的一个移植软件，但是ferret并非纯ruby实现，而是基本上用C编写而成，只有少量面向
程序员的接口是ruby写的。ferret虽然和lucene很像，连API也基本一致，但是ferret的成熟度远远不及lucene，这表现在：
1) ferret不支持中文分词
2) ferret用C编写的，其索引格式和lucene不兼容
3) ferret的索引速度很慢，而且很不稳定
4) windows平台的ferret在search的时候会崩溃
尽管ferret有上面这些缺点，但是RoR平台可供选择的余地却不大，因此还是决定使用ferret。
------------------------------ ferret 分割线 ------------------------------
1、acts_as_ferret (AAF)
AAF是一个相当不错的RoR插件，封装对ferret的操作，但是经过我的考察，决定弃用AAF。这是因为AAF是直接绑定到model上面的，这会带来一些问题：
1) 每当model
对象被insert/update/delete的时候，AAF会通过model的回调实时更新全文索引。在生产环境这是一个很可怕的事情，多个ruby进程同时更新索引，就会出问题。所以AAF索性提供一个DRB方式的ferret server让你在生产环境去用。
但即便如此，如果多个ruby进程同时更新索引呢？ 考虑到ruby的green thread性能，drb server也很容易就被阻塞住。而且退一步来说，即便drb性能很好，每个全文检索请求都去发起一次ruby远程调用，恐怕也是很难接受的事实
2) AAF索引每条model记录，但我却不想索引隐藏贴，况且我的索引机制也不想绑定在model上面。
2、中文分词问题
如果只是简单的中文单字拆分，到不难支持，只需要利用RegexpAnalysis写个正则表达式去匹配UTF-8编码的中文就行了，目前JavaEye的全文检索就是这样处理的，貌似搜索结果还过得去。
但是如果要追求非常精确的搜索结果，则必然需要通过词典的最大匹配算法去进行中文分词。那就只能自己用ruby来写中文分词算法了，这个是留待我们今后要做的工作。
2、ferret的索引稳定性问题
JavaEye网站有8万topic，30万post，由于ruby本身性能不佳，ferret又不很稳定，在服务器上面直接做index，差点把服务器搞瘫了，所以此路不通。
由于全文检索并不需要很高的实时性，所以我们的解决办法就是每天晚上把
数据库数据下载到本地的台式机上面，然后在本地台式机上面导入
数据库，进行全量索引，然后在压缩打包上传到服务器上面去。这样每天的全文检索结果只会迟后一天的时间，基本上可以满足需求了。
