学习搜索开发的重点不在lucene和nutch[ 原创]

// http://blog.csdn.net/chengg0769 　转载或抓取请勿篡改内容或者加一些标记在里面，本人非常反感。

设想：如果现在没有lucene,nutch，可以说，99.999%的人不知道搜索是怎么原理，怎么个做法，如果实现更别谈了。我就是其中一个。

而：现在已经有这个开源的东东，如果你要仔细研究lucene并试图写一个C++的版本，那不是不可以，而是耗费可以说十年之功的事情(cutting已经耗费7年了，而且前提他早就是作这个技术的人)，当然你也不会从java版本开始去研究，而会从基本原理＋CLucene研究开始，而至于java版的有速度的说法，当然你再试图研究除c++,java版本以外的版本毫无疑义，为什么呢？因为剩下的都是无法跨平台(如C#)或者解释执行的(perl,ruby等)。更谈不上改进效率了，甚至有些版本搞出空实现来，不害死你我不信。

其实如我所认为，我们应该解决的是xwjbs和化柏林论文里告诉我们的那些难题点(就是我指的point)。而不是要解决怎么用lucene的问题。我们可以认为现在作一个垂直搜索，检索部分和搜索部分，可以先考虑成一个抽象的空实现。解决其它问题更为关键。算我说的不好听，lucene经过这么久的发展，谁想在他的基础上在独立改进一个版本而不去跟java版本的改进同步的话，这是不可能的。也就是说，如果你打算作出一个原型的，谁来作这两个未实现的部分都可以。可以问一下哪个人如果去应聘他会说不知道lucene?

今天看到 xwjbs的文章，才明白原来自己想的那些细节问题是方向正确的。至少流水模式，监控和任务分派，分布，单独的链接分析和下载分开，任务拆解，这些概念我还是从上千的文章中真正领悟到了(我实现黄页抓取，分析，抽取就是分开的，而且一开始就考虑了多线程，多电脑分布，并考虑对某个站点的线程数控制，全局ID编号，link消重(没实现好)，甚至DNS cache也考虑了。。。想太多了)。他文章正好解决了我构思的一些未解决问题。并使得问题点明朗化。

总结：搞这个，或商业或学习，或只是学习全文检索以利其它方面整和运用，学习的方法是重要的。不要围绕到lucene就认为是关键核心。为大众认知并掌握的东西就不是核心了(比如xeon的图纸如果公布了，它的设计就不是核心了)其实，如果你把数据量定位到10亿，更新率，去重，查全，查准率这些目标定出来，你会发现你学习的知识完全不够，到处都是问题，没有哪一个问题你能解决。这就是yetiantian说的光是可行性就足以让99.999%的人放弃。

所以对我而言。作这个其实是在学习。如果你看了两篇文字就在那里摸来摸去，讨论来讨论去有什么必要呢。如果你没有把上千篇文章理解，没有看过分析过已经存在的产品，你有什么理由动手呢？你问问cutting摸这么久，代码才2W行，他在摸什么呢？这是关键的问题。

//20070926 append

举例说，很多人都在看切词问题，而很少有人能写出好的实用程序，为什么呢？这里有几个因素：

1.词典问题。必须全面，而且普通词典要结合各种专业词典，就如金山一样。

2.需要好的算法能兼顾效率，因为切词是索引的瓶颈

3.需要新词发现，审核和补索引。比如说"芙蓉姐姐",本身切开是两个词语，但是这是一个流行的网络新词，关键是采用什么技术，从什么专业的角度，去发现新词，是否经过人工审核，审核后的新词，要不要把以前的html重新作索引，还是实现无痛自动增加，后续按新词表切分。这就是cutting关注的一些算法，流程，处理逻辑，即如何实现，怎样实现，结构是什么的问题。而模块，程式化后的单元我想交由专业的程序员来实现就足够了。这就是本文的结论：我们应该学习design,而不是拿coding来讨论。design能使得搜索有质的提升，coding最多局部改善或者提高效率。