为什么使用solr----solr与Lucene比较及solr 的结构分析
2016-06-02 09:40
218 查看
原文链接:http://www.aboutyun.com/thread-7018-1-1.html 本帖最后由 nettman 于 2014-2-28 22:46 编辑 [align=left]可以带着下面问题来阅读:[/align] [align=left]1.搜索为什么使用solr?[/align] [align=left]2.一个索引越来越大,solr是如何应对的?[/align] [align=left]3.Solr是什么,一句话描述?[/align] [align=left]4.solr比Lucene有什么优势?[/align] 一、Lucene与solr有什么不一样 首先Solr是基于Lucene做的,Lucene是一套信息检索工具包,但并不包含搜索引擎系统,它包含了索引结构、读写索引工具、相关性工具、排序等功能,因此在使用Lucene时你仍需要关注搜索引擎系统,例如数据获取、解析、分词等方面的东西。 而Solr的目标是打造一款企业级的搜索引擎系统,因此它更接近于我们认识到的搜索引擎系统,它是一个搜索引擎服务,通过各种API可以让你的应用使用搜索服务,而不需要将搜索逻辑耦合在应用中。而且Solr可以根据配置文件定义数据解析的方式,更像是一个搜索框架,它也支持主从、热换库等操作。还添加了飘红、facet等搜索引擎常见功能的支持。 因而,Lucene使用上更加灵活,但是你需要自己处理搜素引擎系统架构,以及其他附加附加功能的实现。而Solr帮你做了更多,但是是一个处于高层的框架,Lucene很多新特性不能及时向上透传,所以有时候可能发现需要一个功能,Lucene是支持的,但是Solr上已经看不到相关接口。 Lucene更像是一个SDK。 有完整的API族以及对应的实现。你可以利用这些在自己的应用里实现高级查询(基于倒排索引技术的),Lucene对单机或者桌面应用很实用很方便。但是Lucene,需要开发者自己维护索引文件,在多机环境中备份同步索引文件很是麻烦。于是,就有了Solr。 而Solr是一个有HTTP接口的基于Lucene的查询服务器,封装了很多Lucene细节。 solr ,更多是和nutch 的结合使用 ----------------------------------------------------------------------------------------------------------------------------------------------- 二、solr 的结构分析 [align=left]solr在lucene外边做了一层厚厚的封装,主要是为了简化二次开发,提供了一些成熟的解决方案。[/align] [align=left]solr和solrCore[/align] [align=left]solr可以对多个core进行综合管理,并接受请求选择特定的一个或者多个core执行相关任务。下面来回答什么是solr的core。[/align] [align=left]core从文件结构的角度来看的话,主要包括一份索引(也可能还包括拼写检查的索引)、一堆配置文件。最主要的配置文件是:solrconfig.xml和schema.xml。solrconfig.xml从整体上对core进行了配置,例如索引的存放路径、字段的最大长度(maxFiedlLength)、写锁的超时时间(writeLockTimeout)、锁类型(lockType)、是否压缩索引(useCompoundFile)、内存索引缓冲区大小(ramBufferSizeMB)、合并因子(mergeFactor)、删除策略、自动提交策略、缓存设置等,它好比是一份组装机器人的说明书,里面详细描述了各个部件(handler)的参数。schema.xml主要是对索引的配置,例如分词器、字段名称+索引方法+存储方式+分词方式、唯一标识字段等,它好比是机器人学习的学习方法,机器人主动或被动接受特定数据,按照配置转化成索引,然后通过其部件(handler)展示出来,例如:search、moreLikeThis、spellCheck、factedSearcher等。[/align] [align=left]core从功能方面来说的话,主要是通过各种handler进行工作,这个在上文中也提及过。solr的功能之多让我想到瑞士军刀,看图:[/align] [align=left]常见的有:morelikeThis、search、 spellCheck、dataImport等。[/align] [align=left]然而不同的部件有复杂简易之分,我们常见的searchHandler就比较复杂,他包括多个零件(component)。[/align] [align=left]多个component进行组合就可以完成特定的工作。(以下代码摘自:SearchHandler.java)[/align] for( SearchComponent c : components ) { rb.setTimer( subt.sub( c.getName() ) ); c.process(rb); rb.getTimer().stop(); } 复制代码 [align=left]以上文字主要简单白话了solr的core是个什么东西!那么solr怎么控制这些core进行工作呢?[/align] [align=left]例如我们输入:http://localhost:8080/solr3.5/core1/select/?q=*%3A*&version=2.2&start=0&rows=10&indent=on[/align] [align=left]这个是检索的目的是:检索core1下的所有内容,并返回前10条。[/align] [align=left]solr通过request获取requestPath,解析出对应的core名称(这里coreName=core1),然后获取core实例(找到相应的机器人)。[/align] [align=left]然后解析出select指令,明确告诉core是进行检索任务,任务的具体参数通过solrRequestParser进行解析。solrRequestParser可以看出是将url转换成core识别指令的“翻译器”。下面core就可以调用相应的handler执行任务了。[/align] [align=left]从外往里看,solr可以看成是:[/align] [align=left]solr Manager -> solr core -> handler -> component[/align] [align=left]简单说说solr的分布式(version:solr3.5)[/align] [align=left]当一个索引越来越大,一个服务器放不下了,怎么办?[/align] [align=left]当一个大索引的单次请求慢得想死,怎么办?[/align] [align=left]选择分布式吧!他能将索引进行切分放到不同的服务器上(shards),还可以将处理的计算压力进行分摊。他会将各个shard上的结果进行合并,并“完美”的呈现给您![/align] [align=left]然而、但是......solr的分布式并不完美。最主要的就是idf的计算问题。这个问题会在单个shard进行打分运算过程中就发生了,如果每个shard在计算过程中实时去其他shards去获取df和文档总数,请求的消耗是不能忍受的。要解决这个问题就得在每个shard中实时保存每个单词的df和文档总数。[/align] [align=left]简单说说solr的服务发布方式和客户端solr[/align] [align=left]solr部署在服务器上,提供各种服务。服务发布的方式主要是基于http协议的,传输数据格式为xml、json,不同开发语言都可以通过socket编程进行访问。官方的java客户端就是solrJ,他利用HttpClient进行客户端开发。[/align] [align=left]我曾经毫无理由的怀疑过这种方式——如果我要用标准的webService,然后又不想改动太多源码,是不是还得通过slorJ做个中间桥梁?是不是无缘无故的多了一次http请求?虽然有embedded!感觉就是solr的这层服务接口被http侵入得有点深。深入的研究后续跟进= =。[/align] [align=left]为什么solr没有multiSearcher?[/align] [align=left]lucene3.5中的multiSearcher已经过时了,取而代之的是multiReader。[/align] [align=left]If you are using MultiSearcher over IndexSearchers, please use MultiReader instead; this class does not properly handle certain kinds of queries.[/align] [align=left]从lucene早起版本开始,或者说是受数据库思想的影响,会将数据按照某一性质进行划分,放到不同的索引里面。理由是便于管理、防止单一索引过大。如果需要同时检索多个索引,自然就用到了multiSearcher。到了solr发现一个core中只能一份索引,于是纠结solr为什么没有multiSearcher?难道solr不担心单一索引过大吗?难道同时检索多个索引就得使用它并不完善的distributedSearch吗?当时这个思想一直影响了我对solr的好感。[/align] [align=left]现在“改革开发”的思想就是:在业务需求下,不支持对多个索引同时进行检索。当单个索引的检索压力出现效率问题后,再考虑分布式检索,将数据分发到不同的shards上。如果不是单次检索的运算量瓶颈,而是并发量带来的压力,考虑使用负载均衡。这里很类似于mongodb,并发压力大作replSet,单库太大做sharding。[/align] |
相关文章推荐
- svn 不能直接提交.a 文件的解决方法
- 弹性盒模型
- 多线程学习(十)并发协作-死锁
- 关于css元素居中
- POJ2240-Arbitrage
- COMSOL提示错误及解决办法
- http
- 集中精力的重要性(The Importance of Focus)
- 从此sudo不再输密码
- Linux基本命令-解压缩
- 声明double变量的时候,加d与不加d有什么区别
- CentOS 6.5 PYPI本地源制作
- SQL Server 2016新特性:DROP IF EXISTS
- android 录音时报 MediaRecorder: setOutputFile called in an invalid state(1)
- 转帖文章(感谢作者)-pyenv安 3ff0 装与使用-多版本python共存解决方法
- Android APP工程结构搭建:几种常见Android代码架构分析
- windows 下 openGLES 3.0 配合 vs 环境搭建(一)
- 站立会议04(冲刺2)
- 基因数据处理44之cloud-scale-bwamem安装
- java 启动命令与git常用命令