认真思考评估站内全文搜索方案

 

　　对于网站的站内全文检索功能，从前我的做法基本上是实行自动摘录一定长度的文体，然后根本这一个域使用like方式实现全文搜索。也由于这种搜索不是经常需要的，所以也不太舍得为之花太大的资源，无论是处理什么站点，都不希望从界面上一开始就诱导用户使用全文检索；而倾向于作为高级选项，甚至是有一定权限的用户才允许使用全文搜索。这种方式不太难实现，而且站内查询量都不太大，只要关键词不是选得太弱智，基本上可以得到需要的搜索结果。这实际上是把搜索应用分级处理。在实际操作中，浏览客户绝大部分的站内搜索要求都可以通过分类搜索达到，部分关键词搜索象上面这样处理也就可以了。

　　典型的就是中国博客，这是一个lucene应用的样版工程，它的基本架构是html目录和apache过滤request实现的计数器。不知有没有看错，它把所有的文章变成静态网页的目的可能有三个：一是减轻数据库负担;二是方便google这样的搜索引擎的spider在静态网页上爬，三就是针对站内搜索的要求。对第一点，等同于对数据库的行记录在html静态页面这一级别上进行非规范化处理；代价是付出很大的管理成本的妥协。很早以前就有这样的争论，认为预先把动态网页转换静态网页可以大幅度提高网站的性能；这是有两个前提根据；其一是数据库建立连接是一个高消耗操作；其二是数据库保持连接对数据库性能是一个高的要求；这都是实情。但预先转存成静态网页相当于放弃对数据的结构性管理的功能，这个代价也是极大的，是否值得，还有没有其他办法可想，实在值得斟酌。所以一些朋友说笔者顽固，拒不接受把页面转换成HTML的先进技术；笔者却认为，那不是新技术，而是向老传统（静态网站）靠拢的临时措施，临时性的技术方案都不会有生命力的。

　　第二条也不太成立。因为google和其他主要的新的搜索引擎完全具备搜索动态网址和连接串；唯一的要求就是要求使用固定的连接，而不是跳转。所谓动态网页多变是站不住脚的，事实上数据标识（ID）是不变的，如果变，就一定是有很大的必要去变；因此静态网页并不具备搜索结果不变的优点，这个优点是动静态网页一样的。第三条就回到本文开始，是否有必要？就以博客中国来说，固然可以在站内通过关键词搜索，但是相信博客针对的观众不是博客社区本身左转右转的浏览者，而是外界的随机阅读者，这些人是不会上博客本身的搜索的，最大可能是直接从googld/baidu/msn连入具体的网页。因此，为了这些并不必要的用例把整个网站变成难以管理（可以从博客中国提交经常出错，以及单调的功能上看出来），是极不值得的。在博客中国甚至连分类管理文章的简单功能都不能提供，可见受到的限制有多么严重。何况目前象google这样的搜索引擎的pagerank算法对于站内搜索一点作用也没有，因此，企图在站内弄一个类 google的引擎是荒唐的！

　　站内全文搜索的错误倾向就是使用全文关键词检索代替其他所有的站内分类检索措施，这是假定所有用户都不使用分类检索而使用关键词检索。如果实际需求的确如此，这种全文搜索技术是值得的，它可以大大降低总的系统成本；但如果相反，一般浏览客倾向于分类搜索，（笔者习惯就是这样），那么，这种技术就是划蛇添足，平添了许多成本却降低了实用性。最后，当谈及全文搜索时，很多业务人员甚至不少技术人员都把站内搜索混同于互联网的搜索。这就更加是错误的，两者完全不一样。 因此，站内全文搜索可以搞，但一定要注意控制模块的规模，不应该超出模块的范围让整个站点向其妥协；换言之，这应该是一个人一天半天就搞出来的东西，也不需要特别的维护工作，如果达不到，宁愿不提供。象博客这类项目，详细的多对多分类可能更具实用性。

　　笔者没有打定主意用lucene,不过对于它还是挺喜欢的，这是一个与应用和平台无关的开源项目，通过对流解析形成一批文件系统级的索引文件，在查找时定位各自的索引文件，得到hits的document集合，集合本身可以是多个名值对；这样，它可以适应不同的使用方式，可以是是互联网的url，也可以是站内的url,静态的或者是动态的都没有关系）。lucene的缺点不是它本身的缺点（笔者还没有发现它本身的弱点），而是维护成本上的不安。使用 lucene，意味着在通常的java环境外多了一块肉！要定期运行一个cron,让它从数据库读指定的域的流，然后生成连接等待查询。一般系统架构要简洁，就是为了减轻后期的维护成本；现在无端多了一块东西，笔者估计意味着总体维护成本对于一般网站来说是多一半到一倍。除非这个网站足够大，就把这个 lucene全文搜索功能挪出主系统，作为一个局域网内部的全文搜索应答服务，通过corba/rmi与主应用对接，或者，反而显得合理一点。

　　简单的才是有生命力的。所以笔者打算用简单的办法完成简单的全文检索，暂时不考虑目前的lucene方案，当然，其它的就更不用谈的。