hadoop,nutch,solr整合到eclipse上开发

艾辉

hadoop,nutch,solr整合到eclipse上开发
　　版本：
　　eclipse：
　　eclipse-jee-juno-SR2-linux-gtk
　　tomcat7：
　　apache-tomcat-7.0.39
　　一，下载安装eclipse，tomcat
　　下载安装eclipse后，解压，运行eclipse
　　在菜单栏里
　　window->preferences->server->runtime environment   
　　add tomcat7
　　二，集成hadoop。
　　hadoop之前的版本有集成好的eclipse插件，现在需要自己编译，具体步骤可以百度。
　　这里是我用的插件 。
　　将hadoop-eclipse-plugin-1.0.4放在/eclipse/plugins下(如果是用软件中心安装的话是/usr/share/eclipse/plugins/)
　　重启eclipse，然后可以看到在project Explorer中看到DFS locations
　　window->show view->other->Map/Reduce Locations 确认后配置Hadoop installation directory即可
         
　　点“蓝色大象“新建

　　修改参数

　　此处Map/Reduce Master与mapred-site.xml对应
　　DFS   Master与hadoop/conf/core-site.xml中对应
　　重启eclipse，点开DFS location就可以看到hdfs(记得启动hadoop)
　　
　　三，nutch，solr集成在hadoop上
　　nutch是一个应用程序，在我的这个项目里主要是做爬虫用，爬取后的内容存放在hdfs上，所以在hdfs整合模块已经整合上去了。
　　solr：
　　在eclipse新建动态网页项目，删除WebContent的所有内容。
　　在solr/dist下（或者/solr3.6.2/example/webapps下）解压solr.war  将所有内容拷贝到WenContent里。
　　修改WEB-INF里的web.xml
　　添加




solr/home
/home/hadoop/solr3.6.2/example/solr
java.lang.String

　　到最后的前。
　　解释下这个地方是你的solr core的位置
　　采用solr多核的话可以将

/home/hadoop/solr3.6.2/example/multicore，同时修改multicore中的solr.xml






　　instanceDir为core的存放位置
　　在server中新建tomcat7服务，然后添加你刚新建的动态网页工程

　　启动tomcat7，在正常情况下，你可以选择运行wencontent下的index.jsp 避免你弄错url的路径。

　　这样，hadoop+nutch+solr的eclipse环境就搭建好了。
　　本系列文章也就结束了，这一两个月的摸索与学习，收获很多，比如MapReduce机制，信息检索的一些知识。
　　当然后续还会继续主要学习hadoop。
　　这应该是acm后第一个知识积累的阶段。很好，继续努力。
　　Sleeper_qp,Fighting!!!
　　梦想就在眼前了。
　　最近开始研究MySQL和MongoDB，发现这方面资料不多。尤其是真正的说到点子上的文章，太少了。
　　有一些对比测试的文章基本上都是瞎测，测试方法都测到了马腿上，得出的结论基本上都是NoSQL毫无价值
　　容我借用Russell Smith 的那句话：不是MongoDB不行，是你不懂。
　　让我来分析一下MongoDB的真正性能吧。
　　有说MongoDB慢
　　反对：不设其他唯一索引的情况下，只用_id 在普通办公电脑上每秒插入几万，在普通x86服务器上每秒插入十几万，你好意思说这个性能低？比mysql强出一个数量级。
　　赞同：检索是真的慢，和sql数据库不同，越复杂的条件搜索MangoDB越吃亏，CPU和IO的双重压力。面对那些直接把SQL查询改写成MangoDB的用法，别转了，你不会收获任何性能提升。
　　你不行：说你不行还是真的不行，MongoDB领导了NoSQL运动，NoSQL请注意，我们最主要反对的就是SQL的方法论，按SQL方法使用MangoDB你只能收获失望。再想想MongoDB的设计思想：文档化。_id 就是文件名，MongoDB是个文件系统。全文检索？别闹了，用文件名找文件，一个文件名对应一个文件，你绝对不会失望。
　　那么MongoDB究竟应该怎么用呢？

首先，忘记SQL
　　你应该忘记你学过的那些优雅无敌的SQL，不是说为了提升检索性能，扔索引就有好处。
　　有一个简单的事实如下：只有一个默认的_id 索引，此时插入性能为1，你再加一个索引，插入性能约1/2,再加一个约1/3 ,以此类推......
　　如果这个事实对你是很震撼的，那说明你还没有忘记SQL，接着忘。
　　MongoDB的索引对插入性能有着不可忽略的拖后腿效应，所以，我们应该使用且仅使用 _id 作为插入key，作为查询key，作为所有的那个key。

其次，直接忘记搜索这件事。
　　把MongoDB当做你的硬盘，给他文件名去操作文件.这就是Key-Value数据库的做法，你稍加设计就能这么用。
　　那么其实你所有的操作可以简化为两个指令，逻辑上 就是一个字典
　　你给他_id,往字典里插一个数据，或者拿一个数据。
　　Save({_id:xxx,.....})
　　FindOne({_id:xxx})
　　要想高性能，善用那个_id,把你原来准备当主键的那个玩意，hash成_id.
　　把你原来准备的查询条件，什么？查询，拿_id来，别的全砍掉。

第三、这不是数据表
　　记住，这不是数据表，一个_id对应的东西不是一行数据，而是一个文件。
　　文件存储和表存储有什么不同呢？
　　我举个例子，比如我们要存储用户列表和每个用户的道具列表。
　　数据表的做法是建一张用户表，一张道具表，道具表里有个字段表示他属于哪个用户。
　　然后，你就离不开万恶的查询了。
　　然后如果一个用户有100条道具，100万用户意味着道具表有一亿条记录。
　　这时候就开始考验你的小数据库了，但这都是过去式了，这一亿的道具，用MongoDB，根本不是个事儿
　　因为MongoDB的方法是当做文件存，只设计一个用户集合，每个用户的信息是一个文件，然后这100个道具就分开存在每个用户的文件里。
　　然后来比较一下，我们取得用户的记录，然后从中拿出100个道具，NoSQL方法。
　　查一亿的表，找出属于某个用户的记录。
　　熟快熟慢？
　　然后你可能回想，SQL方法，我也可以搞个道具字段，把用户的100个道具用某种协议打包，然后操作啊，一样可以取得巨大的优化呀。
　　没错，你的想法很好，你正在用NOSQL的方式用SQL。

第四、文件存储的精华之处
　　如果问题止于此处，MongoDB就毫无优势可言了，如果这个方法在SQL数据库上也是如此容易使用，那还费劲搞MongoDB干什么？
　　我们再折腾一点，如果每个道具还要存100条转手记录，你还是可以打包，但你这个打包字段已经1M了。
　　于是每次存取这个打包字段都是一个系统工程了，还要负担1M的流量。
　　MongoDB这边呢？我们可以直接对文件的一部分进行读写，比如我只返回一个用户的第二个道具的信息，和返回第二个道具的第1~30条转手记录。
　　这，是一种怎样的差距啊。
　　你想要一张美女的照片，你朋友有，但是他只有一个压缩包，他那里没有解包工具，于是他把整个包传给了你。他想问你要一张照片，但是他没有压缩工具，为了存档需要，他让你再压进包里传给他。
　　这个朋友就是你的用户表的一行，如果换成真实世界的事件是多么的不可思议，这就是在一个字段里打包数据的问题。
　　MongoDB的一条记录就是一个脑筋更正常的朋友，你要他一张照片，他从包里找出来给你。你给他一张照片，他分门别类的放置到他的包里去。
　　用文件的思维去访问，MongoDB是一个更好的朋友。
　　审视一下你项目中的大部分的数据需求，是不是都可以用这种方式去组织呢？
　　如果是，加入NOSQL吧，我们的口号是：很暴力不SQL

还有什么好处
　　1.不用逻辑关心的水平切分
　　无需多言，对MongoDB而言，这是运维人员的工作了
　　2.不用对齐的数据结构
　　不用对齐意味着你不用为以前表结构变化的迁移烦恼，有些文件里有一个部分，有些没有，这对MongoDB而言，很正常。