JavaEye3.0开发手记之四 － ruby的全文检索

robbin, 我采用的是ruby通过drb 访问jruby下的lucene, 中文分词都是现成的, jruby利用同样的rails代码访问数据库, 定时更新

我们网站想从java转到Ruby。目前最头疼的问题是luccen的移植。我现在是这样考虑的，搜索密集的地方，都用apache proxy到后台的tomcat服务器，也就是仍旧由java luccen来做。但生成的页面URL，是由ruby 服务器来服务。

对于实在难分开的全文检索，仍旧传到java 服务器，服务器返回javascript，通过ajax方式和rhtml生成的代码结合使用。

目前还很两难，以上都是自以为行得通，不知大家有什么意见。

反正全文检索，我不想转到ruby,感觉ruby这方面太不成熟了。

我觉得现在网站上的搜索有个非常大的弊病，就是结果的排序。robbin将各种相关性如点击数，回复数掺杂在相关性排序中，这导致了搜索结果的一成不变，比如搜"lucene",从新搜索功能上线到现在前面几条结果都是一样，对我这样的想掌握javaeyes上的"lucene"动态的人来说非常的郁闷，看来看去都是那些内容在前面。个人建议对历史精华贴做单独的推荐，主要结果还是按时间为主要影响因子进行排序。或者提供两个按钮：按相关度排序和按时间排序

你说的有道理，搜索结果可以提供多种排序结果展示给用户看，记下来放在TODO List里面。

我有点好奇想了解一下，如果有个ruby库能读lucene本机的索引，会不会就能解决这个个问题了？

因为看上去主要问题似乎是ferret索引格式和lucene不兼容，而solr无法运行于本机。

是的，ferret在早期版本的索引格式和lucene是一致的，但是后来ferret作者认为lucene的索引格式不够优化，为了提高性能而采用了自己的索引格式，从而导致不兼容。

但是在我看来，ferret已经实现了lucene的大部分功能了，要说区别，也无非就是ferret做索引的时候速度比lucene慢一些而已。至于中文分词的问题，ferret面临和lucene一样的情形。所以大家用ferret和用lucene是一样的。

最近在用lucene+CJKAnalyzer做项目,现在索引和搜索都已经完成,但是测试时发现,对于一些大的word文档的搜索不完全,超过20页之后就搜索不到,不知问题出在哪里?

lucene有一个属性可以设置一个文档的最大单词数，默认好像是10000来着，你设置一下，应该就可以了。