关闭

为什么使用solr----solr与Lucene比较及solr 的结构分析

865人阅读 评论(0) 收藏 举报
分类:


原文链接:http://www.aboutyun.com/thread-7018-1-1.html






本帖最后由 nettman 于 2014-2-28 22:46 编辑


可以带着下面问题来阅读:
1.搜索为什么使用solr?
2.一个索引越来越大,solr是如何应对的?
3.Solr是什么,一句话描述?
4.solr比Lucene有什么优势?

一、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 的结构分析


solr在lucene外边做了一层厚厚的封装,主要是为了简化二次开发,提供了一些成熟的解决方案。

solr和solrCore

solr可以对多个core进行综合管理,并接受请求选择特定的一个或者多个core执行相关任务。下面来回答什么是solr的core。
core从文件结构的角度来看的话,主要包括一份索引(也可能还包括拼写检查的索引)、一堆配置文件。最主要的配置文件是:solrconfig.xml和schema.xml。solrconfig.xml从整体上对core进行了配置,例如索引的存放路径、字段的最大长度(maxFiedlLength)、写锁的超时时间(writeLockTimeout)、锁类型(lockType)、是否压缩索引(useCompoundFile)、内存索引缓冲区大小(ramBufferSizeMB)、合并因子(mergeFactor)、删除策略、自动提交策略、缓存设置等,它好比是一份组装机器人的说明书,里面详细描述了各个部件(handler)的参数。schema.xml主要是对索引的配置,例如分词器、字段名称+索引方法+存储方式+分词方式、唯一标识字段等,它好比是机器人学习的学习方法,机器人主动或被动接受特定数据,按照配置转化成索引,然后通过其部件(handler)展示出来,例如:search、moreLikeThis、spellCheck、factedSearcher等。
core从功能方面来说的话,主要是通过各种handler进行工作,这个在上文中也提及过。solr的功能之多让我想到瑞士军刀,看图:
       
常见的有:morelikeThis、search、 spellCheck、dataImport等。

然而不同的部件有复杂简易之分,我们常见的searchHandler就比较复杂,他包括多个零件(component)。
多个component进行组合就可以完成特定的工作。(以下代码摘自:SearchHandler.java)
  1. for( SearchComponent c : components ) {
  2.           rb.setTimer( subt.sub( c.getName() ) );
  3.           c.process(rb);
  4.           rb.getTimer().stop();
  5.         }
复制代码
以上文字主要简单白话了solr的core是个什么东西!那么solr怎么控制这些core进行工作呢?
这个是检索的目的是:检索core1下的所有内容,并返回前10条。
solr通过request获取requestPath,解析出对应的core名称(这里coreName=core1),然后获取core实例(找到相应的机器人)。
然后解析出select指令,明确告诉core是进行检索任务,任务的具体参数通过solrRequestParser进行解析。solrRequestParser可以看出是将url转换成core识别指令的“翻译器”。下面core就可以调用相应的handler执行任务了。
从外往里看,solr可以看成是:
solr Manager -> solr core -> handler -> component

简单说说solr的分布式(version:solr3.5)

当一个索引越来越大,一个服务器放不下了,怎么办?
当一个大索引的单次请求慢得想死,怎么办?
选择分布式吧!他能将索引进行切分放到不同的服务器上(shards),还可以将处理的计算压力进行分摊。他会将各个shard上的结果进行合并,并“完美”的呈现给您!
然而、但是......solr的分布式并不完美。最主要的就是idf的计算问题。这个问题会在单个shard进行打分运算过程中就发生了,如果每个shard在计算过程中实时去其他shards去获取df和文档总数,请求的消耗是不能忍受的。要解决这个问题就得在每个shard中实时保存每个单词的df和文档总数。

简单说说solr的服务发布方式和客户端solr

solr部署在服务器上,提供各种服务。服务发布的方式主要是基于http协议的,传输数据格式为xml、json,不同开发语言都可以通过socket编程进行访问。官方的java客户端就是solrJ,他利用HttpClient进行客户端开发。
我曾经毫无理由的怀疑过这种方式——如果我要用标准的webService,然后又不想改动太多源码,是不是还得通过slorJ做个中间桥梁?是不是无缘无故的多了一次http请求?虽然有embedded!感觉就是solr的这层服务接口被http侵入得有点深。深入的研究后续跟进= =。

为什么solr没有multiSearcher?

lucene3.5中的multiSearcher已经过时了,取而代之的是multiReader。
If you are using MultiSearcher over IndexSearchers, please use MultiReader instead; this class does not properly handle certain kinds of queries.
从lucene早起版本开始,或者说是受数据库思想的影响,会将数据按照某一性质进行划分,放到不同的索引里面。理由是便于管理、防止单一索引过大。如果需要同时检索多个索引,自然就用到了multiSearcher。到了solr发现一个core中只能一份索引,于是纠结solr为什么没有multiSearcher?难道solr不担心单一索引过大吗?难道同时检索多个索引就得使用它并不完善的distributedSearch吗?当时这个思想一直影响了我对solr的好感。

现在“改革开发”的思想就是:在业务需求下,不支持对多个索引同时进行检索。当单个索引的检索压力出现效率问题后,再考虑分布式检索,将数据分发到不同的shards上。如果不是单次检索的运算量瓶颈,而是并发量带来的压力,考虑使用负载均衡。这里很类似于mongodb,并发压力大作replSet,单库太大做sharding。
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:6993次
    • 积分:124
    • 等级:
    • 排名:千里之外
    • 原创:3篇
    • 转载:18篇
    • 译文:0篇
    • 评论:0条