chengg0769 来自四川,在东莞虚度十载

PB反编译_Powerbuilder DeCompiler_PB反编译器_PB混淆器_PB加密

学习搜索开发的重点不在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最多局部改善或者提高效率。

阅读更多
想对作者说点什么? 我来说一句

Lucene.Nutch搜索引擎开发

2014年05月22日 40MB 下载

Lucene+nutch搜索引擎开发.part1.rar

2012年10月29日 45.78MB 下载

没有更多推荐了,返回首页

不良信息举报

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

最多只允许输入30个字

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭