学习搜索开发的重点不在lucene和nutch[ 原创]
2007-09-17 19:59
309 查看
// 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,可以说,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,java,分布[原创]
- Lucene学习总结之七:Lucene搜索过程解析(1)
- 使用Lucene开发简单的站内新闻搜索引擎(索引的搜索)
- (原创)c#学习笔记02--编写c#程序01--开发环境
- Lucene学习总结之七:Lucene搜索过程解析(1)
- Lucene学习总结之七:Lucene搜索过程解析
- Lucene 学习开发
- 20、学习Lucene3.5索引之近实时搜索
- 原创作品 | 盘搜搜-极速搜索你想要的一切资源-爬虫学习项目总结
- Nutch+Lucene搜索引擎开发实践
- [置顶] Lucene开发实例(一般企业搜索平台完全够用全程)
- Lucene.Net 2.3.1开发介绍 —— 四、搜索(二)
- Lucene开发实例(一般企业搜索平台完全够用全程)
- 基于lucene的案例开发:搜索索引
- Lucene学习总结之七:Lucene搜索过程解析(8)
- 零基础学习嵌入式入门以及项目实战开发【手把手教+国内独家+原创】
- 《Lucene in Action》(第二版) 第一章节的学习总结 ---- 用最少的代码创建索引和搜索
- Lucene学习总结之七:Lucene搜索过程解析(3)
- Lucene学习总结之七:Lucene搜索过程解析(7)
- 学习重点向oralce程序开发靠拢