JavaEye3.0开发手记之四 － ruby的全文检索
魏健柏
在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.iteye.com/blog/122696
我已经在上一篇博客当中介绍了sphinx。我个人非常青睐sphinx这种独立的第三方全文检索服务器，而且能够和MySQL结合的很好，更不用说其优异的性能了。但是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，差点把服务器搞瘫了，所以此路不通。
由于全文检索并不需要很高的实时性，所以我们的解决办法就是每天晚上把数据库数据下载到本地的台式机上面，然后在本地台式机上面导入数据库，进行全量索引，然后在压缩打包上传到服务器上面去。这样每天的全文检索结果只会迟后一天的时间，基本上可以满足需求了。
在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.iteye.com/blog/122696
我已经在上一篇博客当中介绍了sphinx。我个人非常青睐sphinx这种独立的第三方全文检索服务器，而且能够和MySQL结合的很好，更不用说其优异的性能了。但是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，差点把服务器搞瘫了，所以此路不通。
由于全文检索并不需要很高的实时性，所以我们的解决办法就是每天晚上把数据库数据下载到本地的台式机上面，然后在本地台式机上面导入数据库，进行全量索引，然后在压缩打包上传到服务器上面去。这样每天的全文检索结果只会迟后一天的时间，基本上可以满足需求了。
类似资料：