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

可以带着下面问题来阅读：

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）

for( SearchComponent c : components ) {
          rb.setTimer( subt.sub( c.getName() ) );
          c.process(rb);
          rb.getTimer().stop();
        }
复制代码

以上文字主要简单白话了solr的core是个什么东西！那么solr怎么控制这些core进行工作呢？

例如我们输入：http://localhost:8080/solr3.5/core1/select/?q=*%3A*&version=2.2&start=0&rows=10&indent=on

这个是检索的目的是：检索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。

挺好的