solr-in-action-ch4-Configuring Solr

Solr基本的三个XML配置文件：

solr.xml: solr 日志、shard、solrcould等配置

solrconfig.xml: 某个solr core的配置

schema.xml：某个solr core的索引结构的配置，包含field 和field类型

这一章主要介绍solrconfig.xml, 某个solr core的配置。

1、Core的发现过程

扫描启动某个core的过程是这种：Solr webserver依据配置的java System Property(solr.solr.home),找到solr的home路径，然后solr会扫描这个home路径以下的包括有core.properties的子文件夹。core.properties定义了core的名称、以及其它一些配置信息（非必须，一般如今都在之类只定义name=your_collection_name）。其它一些參数例如以下左图。一旦solr发现了这个core之后就会到这个文件夹以下的conf文件夹下找到solrconfig.xml来開始初始化这个core。

Overview of solrconfig.xml

<!--solrconfig.xml中的配置项主要分下面几大块：

     1.依赖的lucene版本号配置，这决定了你创建的Lucene索引结构。由于Lucene各版本号之间的索引结构并非全然兼容的，这个须要引起你的注意。

     2.索引创建相关的配置。如索引文件夹，IndexWriterConfig类中的相关配置(它决定了你的索引创建性能)

     3.solrconfig.xml中依赖的外部jar包载入路径配置

     4.JMX相关配置

     5.缓存相关配置，缓存包含过滤器缓存，查询结果集缓存，Document缓存，以及自己定义缓存等等

     6.updateHandler配置即索引更新操作相关配置

     7.RequestHandler相关配置。即接收clientHTTP请求的处理类配置

     8.查询组件配置如HightLight。SpellChecker等等

     9.ResponseWriter配置即响应数据转换器相关配置。决定了响应数据是以什么样格式返回给client的。

     10.自己定义ValueSourceParser配置。用来干预Document的权重、评分，排序

-->

<config>

    <!--依赖的lucene
版本号-->

    <luceneMatchVersion>4.7</luceneMatchVersion>

    <!--Solr怎样去载入solr
plugins(Solr插件)依赖的jar包-->

    <lib dir="../../../contrib/extraction/lib" regex=".*\.jar"/>

    <!--用来指定一个solr的索引数据文件夹，solr创建的索引会存放在data\index文件夹下，默认dataDir是相对于当前core文件夹(假设solr_home下存在core的话)。

    假设solr_home下不存在core的话，那dataDir默认就是相对于solr_home啦，只是一般dataDir都在core.properties下配置。

-->

    <dataDir>${solr.data.dir:}</dataDir>

    <!--solr
索引存储方案-->

    <directoryFactory name="DirectoryFactory”
class="..."/>

    <!--索引相关配置-->

    <indexConfig>...</indexConfig>

    <!--这个配置是用来在Solr中启用JMX-->

    <jmx/>

    <!--指定索引更新操作处理类-->

    <updateHandler class="solr.DirectUpdateHandler2">

        <updateLog>...</updateLog>

        <autoCommit>...</autoCommit>

    </updateHandler>

    <!--索引查询相关的配置项-->

    <query>

        <!--缓存相关-->

        <filterCache ...
/>

        <queryResultCache ...
/>

        <documentCache ...
/>

        <!--
QuerySenderListener用来监听查询发送过程。即你能够在Query请求发送之前做一些处理，比方追加一些请求參数-->

        <listener event="newSearcher" class="solr.QuerySenderListener">

            <arr name="queries">...</arr>

        </listener>

        <listener event="firstSearcher" class="solr.QuerySenderListener">

            <arr name="queries">...</arr>

        </listener>

    </query>

    <!--request分发器-->

    <requestDispatcher handleSelect="false">

        <requestParsers ...
/>

        <httpCaching never304="true"/>

    </requestDispatcher>

    <!--Request
handler to process queries using a chain of search components (see section 4.2.4).-->

    <requestHandler name="/select" class="solr.SearchHandler">

        <lst name="defaults">...</lst>

        <lst name="appends">...</lst>

        <lst name="invariants">...</lst>

        <arr name="components">...</arr>

        <arr name="last-components">...</arr>

    </requestHandler>

    <!--Example
search component for doing spell correction on queries.-->

    <searchComponent name="spellcheck"

                     class="solr.SpellCheckComponent">...

    </searchComponent>

    <!--Extends
indexing behavior using update-request processors, such as language detection.-->

    <updateRequestProcessorChain name="langid">...

    </updateRequestProcessorChain>

    <!--Formats
the response as JSON.-->

    <queryResponseWriter name="json"

                         class="solr.JSONResponseWriter">...

    </queryResponseWriter>

    <!--自己定义ValueSourceParser配置，用来干预Document的权重、评分，排序-->

    <valueSourceParser name="myfunc" ...
/>

    <!--transforms
转换器 。对doc进行转换-->

    <transformer name="db"

                 class="com.mycompany.LoadFromDatabaseTransformer">

        ...

    </transformer>

</config>

solrconfig.xml中有大量类似<arr> <list> <str> <int>这种自己定义标签，以下做个统一的说明：

arr:即array的缩写，表示一个数组，name即表示这个数组參数的变量名

lst即list的缩写。但注意它里面存放的是key-value键值对

bool表示一个boolean类型的变量,name表示boolean变量名，

同理还有int,long,float,str等等

Str即string的缩写，唯一要注意的是arr下的str子元素是没有name属性的，而list下的str元素是有name属性的

2、Query request handling

2.1、Request-handling overview

Solr 查询请求的处理过程:

1、Client（浏览器或者solrjclient）发送查询请求到solrserver

2、Jetty（或者tomcat等其它的webserver）会将/solr的请求路由到solr统一的request dispatcher，dispatcher会依据/collection1找到相应的core，并找到这个core的solrconfig.xml中定义的处理请求的 request handle

3、request handler  使用各个组件串行的处理这个请求

4、处理完毕后，Reponse writer组件会将结果处理成某个格式（xml、json等等）并返回client，默认是返回xml格式。

2.2、search handler

request handler主要有两类search handler和update handler。search handler负责处理查询请求、update handler用来更新索引的请求，这里主要介绍一下search handler，update handler 下一章介绍。下图是solrconfig.xml中/select request handler的定义。

ps:solrconfig.xml文件里定义的solr.开头的class（如这里的solr.SearchHandler）,都会相应于solr core java package：

"analysis.", "schema.", "handler.", "search.", "update.", "core.", "request.", "update.processor.", "util.", "spelling.", "handler.component.", or"handler.dataimport." 。

这里的SearchHandler相应于

org.apache.solr.handler.component.SearchHandler 。

一个Search handler能够定义一下几个处理阶段：

1.请求參数处理

加入请求中没有的默认查询參数

覆盖改动请求的參数值

加入额外的參数

2.search first-components（可选）

3.search process components

4.search last-components （可选）

2.3、search components

2.3.1 QUERY COMPONENT

query处理的核心，通过active searcher 解析和运行查询。查询解析是通过參数控制的defType（如edismax，dismax）。query
组件查询初匹配查询參数的doc。这些doc能够被兴许的组件继续处理。query组件是默认开启的，兴许其它的组件须要在查询參数里显示的指定。

2.3.2 FACET COMPONENT

solr将以导航为目的的查询结果称为facet. 它并不会改动查询结果信息, 仅仅是在查询结果上依据分类加入了count信息, 然后用户依据count信息做进一步的查询, 比方淘宝的查询列表中, 上面会表示不同的类目相关查询结果的数量，，兴许会具体介绍

2.3.3 MORE LIKE THIS COMPONENT

假设启用这个组件。会搜索出和查询结果相似的doc，兴许会具体介绍

2.3.4 HIGHLIGHT COMPONENT

假设启用这个组件，会高亮显示匹配的文本，兴许会具体介绍

2.3.5 STATS COMPONENT

统计组件。假设启用，能够统计指定数字field的统计信息。如最小值、最大值、总和、平均值...等等统计信息。详细能够看以下的实例。

2.3.6、DEBUG COMPONENT

开启debug组件。能够看到solr 打分的详情，有助于排查一些诸如排序错误的问题。

开启debug组件仅仅用在请求參数添加debugQuery=true就能够了。

2.3.7 ADDING SPELLCHECK AS A LAST-COMPONENT

兴许再介绍

3、Managing searchers

solrconfig.xml中<query>标签包括了一些能够优化查询性能的參数。如缓存、field懒载入、新searcher预热等。

3.1 New searcher overview

searcher是solr处理query的组件。solr中仅仅有一个active 的searher。

这个active searcher 拥有全部lucene索引的仅仅读快照，假设提交一个新的doc到solr，这个doc在当前这个searcher中是不可见的。那么怎样才干使得新提交的doc可见呢？solr的解决方式是关闭当前的searcher，新开一个searcher。新的searcher拥有新提交的doc的索引的仅仅读快照。这就是solr
commit的须要做的一部分工作（每一个commit都要new 一个searcher）。

当进行一次commit之后，在旧的searcher上还有未运行完的查询，所以旧searcher的销毁是在其上面搜有查询运行完才运行的。销毁旧的searcher的时，其上面全部的缓存也都会被删除（由于原有的缓存都是基于旧的索引快照的，commit之后索引是有更新的。所以旧的缓存也应该是要失效的）。

而生成新的searcher须要运行一些计算（如又一次计算缓存），所以生成新的searcher是代价比較耗时的操作。

为了不正确用户的查询产生影响。solr採用的后台生成新的searcher的方式。当新的searcher就绪之前，旧的searcher一直是提供查询的，直到新的searcher 预热完成。

3.2、Warming a new searcher

预热新的searcher有两种方式：通过旧的cache自己主动预热新的cache、运行cache预热的查询。下一节会具体介绍自己主动预热。

这里先看一下运行cache预热的查询的配置。

通过配置一个listener，当newSeacher事件发生时。会运行queries里面的查询用来预热缓存。配置成预热的query一般都是应用最频繁的查询，配置queries不能过多，过多会造成预热的时间太久。耗费太多server的资源。

这样的预热方式方式一个非常实用的场景是solr服务启动first searcher的预热。配置first searcher的预热。仅仅须要将上面的event="firstSeacher"即可了。

solr推断事件是firstSeacher是依据当前Seacher是否是null推断的，假设当前seacher是null则为firstSearcher。

searcher预热还有两个重要的配置标签useColdSearcher和maxWarmingSearchers

<useColdSearcher>false</useColdSearcher>，当配置为true的时候，不等新的searcher预热完成就直接使用，而配置为false的时候，就是等到新的searcher预热完才会使用
<maxWarmingSearchers>2</maxWarmingSearchers>， 配置同一时候预热的searcher数量，假设searcher预热的时间过长，commit又比較频繁的话，会导致同一时候有多个searcher在预热。假设同一时候预热的数量超过配置的參数。之后的commit就会报错。假设常常出现报错，就须要考虑是否这个值设置的不合理或者预热时间过长。solr默认配置的是2。

4、cache management

4.1、cache fundamentals

  • cache 大小
  • 命中率与缓存踢除
  • 缓存失效
  • cache预热

cache大小

solr cache在都在内存中，须要有限制大小

LRU、LFU

假设内存够大。cache也不宜设置过大，过大会造成fullgc 时间太长

命中率与缓存踢除

命中率越接近1越好，太小solr的cache益处不大

缓存踢除过多，说明缓存size设置太小

命中率和缓存是有关联关系的

缓存失效

缓存失效导致查询结果错误的问题在solr中不存在，由于solr的缓存是和searcher实例绑定的，当searcher关闭的时候，全部缓存一起失效。searcher是一个对索引的一个仅仅读快照。

缓存预热

solr commit之后创建一个新的searcher实例

创建新的searcher能够设置预热缓存

4.2、filter cache

针对fq參数。fq參数对查询结果进行过滤。不会影响打分

fq的查询结果缓存，key是fq的參数，value是docid的bitmap（所以假设maxdoc是100w个，那每一个cache的最大的大小是100w bit=1Mb）

autowarm的时间不能超过commit的间隔

最好用LFU

size和autowarmCount 须要依据应用的fq的数量以及commit的间隔



version=1&modificationDate=1439025599000&api=v2" style="margin:0px 2px; padding:0px; border:0px; display:block">

4.3、Query result cache

queryResultCache是对查询结果的缓存（SolrIndexSearcher中的cache缓存的都是document id set），这个结果就是针对查询条件的全然有序的结果

<queryResultWindowSize> 每次查询返回的doc的数量，比方设置为30。一个查询每页是10个。但一次查询实际是返回30个docid的

<queryResultMaxDocsCached> 对于每一个查询缓存的doc的最大数量，比方设置为90，这个查询最多能缓存的doc数量

queryResultCache 永远缓存第一个doc到查询的出的最后一个doc，而不是start 的docid

參考：http://ronaldxq.blogspot.hk/2015/01/solr-queryresultcache.html

4.4、Document cache

documentCache用来保存<doc_id,document>对的。

假设使用documentCache，就尽可能开大些，至少要大过<max_results> * <max_concurrent_queries>，否则由于cache的淘汰，一次请求期间还须要又一次获取document一次。也要注意document中存储的字段的多少，避免大量的内存消耗。

预热是否必要：要看情况而定，返回比較固定，就能够设置预热

4.5、Field value cache

lucene缓存。不是solr管理的，缓存了docId和stored field。

5、Summary

上面仅仅是介绍了solrconfig.xml的一部分经常使用的配置，solrconfig.xml里面有大量的具体凝视。能够通过查看solrconfig.xml  的配置文件的了解其它的一些配置。如配置返回格式、怎样定义一个新的search handler、生产环境调优等。

时间： 2024-08-06 07:57:10

solr-in-action-ch4-Configuring Solr的相关文章

Solr In Action 笔记(2) 之 评分机制(相似性计算)

Solr In Action 笔记(2) 之评分机制(相似性计算) 1 简述 <这就是搜索引擎>里面对相似性计算进行了简单的介绍. 内容的相似性计算由搜索引擎的检索模型建模,它是搜索引擎的理论基础,为量化相关性提供了一种数学模型,否则没法计算.当然检索模型理论研究存在理想化的隐含假设,即假设用户需求已经通过查询非常清晰明确地表达出来了,所以检索模型的任务不牵扯到对用户需求建模,但实际上这个和实际相差较远,即使相同的查询词,不同用户的需求目的可能差异很大,而检索模型对此无能为力.几种常见的检索模

Solr In Action 笔记(4) 之 SolrCloud分布式索引基础

Solr In Action 笔记(4) 之 SolrCloud Index 基础 SolrCloud Index流程研究了两天,还是没有完全搞懂,先简单记下基础的知识,过几天再写个深入点的.先补充上前文来不及写的内容. 1. Solr.xml的重要配置 Solr.xml的内容如下: 1 <solr> 2 <solrcloud> 3 <str name="host">${host:}</str> 4 <int name="

Solr In Action 笔记(3) 之 SolrCloud基础

Solr In Action 笔记(3) 之 SolrCloud基础 在Solr中,一个索引的实例称之为Core,而在SolrCloud中,一个索引的实例称之为Shard:Shard 又分为leader和replica. 1. SolrCloud的特质 作为分布式搜索引擎的SolrCloud具有以下几个特质: 可扩展性 所谓的可扩展性就是指可以通过扩大集群的规模来实现性能的提升.有两种方式来实现可扩展性,一种是纵向扩展,即加快CPU速度,增加RAM,提升磁盘I/O性能等,另一种是横向扩展,就是分

Solr In Action 笔记(1) 之 Key Solr Concepts

Solr In Action 笔记(1) 之 Key Solr Concepts 题记:看了下<Solr In Action>还是收益良多的,只是奈何没有中文版,只能查看英语原版有点类,第一次看整本的英语书,就当复习下英语并顺便做下笔记吧. 1. Solr的框架 从这张图上看Solr的组件还是很齐全以及清楚明了的,但是当你看Solr源码的时候就会发现,哎呀咋看起来这么类呢. 2. Solr的查询方式 上面两张图分别举例了Solr的几个QueryComponent,比如facet,More li

自译Solr in action中文版

目录 Part 1 初识 SOLR 1 Solr 简介 2 开始熟悉 Solr 3 Solr 核心概念 4 配置 Solr 5 建立索引 6 文本分析 Part 2 Solr 核心功能 7 发起查询 和 处理结果 8 分类索引 9 命中结果高亮 10 查询建议引导 11 结果分组 合并域 12 将Solr产品化 Part 3 Solr 高级应用 13 扩展Solr云 14 多语言搜索 15 复杂数据操作 16 相关性的调整 17 跳出思维定势 附录: A 从源代码编译Solr B 玩转Solr社

Solr In Action 中文版 第一章(一)

1.1我到底需要一个搜索引擎吗? 第一章           Solr 简介 本章速览: ·搜索引擎处理的数据特性 ·常见搜索引擎用例 ·Solr核心模块介绍 ·选择Solr的理由 ·功能概述 伴随着社交媒体.云计算.移动互联网和大数据等技术的高速发展,我们正迎来一个令人激动的计算时代.软件架构师们开始面对的主要挑战之一,便是如何处理全球巨大的用户基数所产生及使用的海量数据.此外,用户们开始期待在线软件应用永远都是稳定可用的,并且能够一直保持响应,这对应用就提出了更高的可扩展性和稳定性需求.为了

Solr In Action 中文版 第一章 (二)

Solr到底是什么? 在本节中,我们通过从头设计一个搜索应用来介绍Solr的关键组件.这个过程将有助于你理解Solr的功能,以及设计这些功能的初衷.不过在我们开始介绍Solr的功能特性之前,还是要先澄清一下Solr并不具有的一些性质: 1)  Solr并不是一个像Google或是Bing那样的web搜索引擎 2)  Solr和网站优化中经常提到的搜索引擎SEO优化没有任何关系 好了,现在假设我们准备为潜在的购房客户设计一个不动产搜索的网络应用.该应用的核心用例场景是通过网页浏览器来搜索全美国范围

Solr In Action 中文版 第一章（三）

3.1              为什么选用Solr? 在本节中,我们希望可以提供一些关键信息来帮助于你判断Solr是否是贵公司技术方案的正确选择.我们先从Solr吸引软件架构师的方面说起. 3.1              软件架构师眼中的Solr 在评估一项新技术时,软件架构师必须要考虑一系列的因素,其中就包括系统的稳定性,可伸缩性,还有容错性.Solr在这三方面的得分都很不错. 说到稳定性,Solr是一个由活跃的开源社区和经验丰富的代码提交者共同维护的一项成熟技术.Solr和Lucene的

Solr In Action 中文版 第一章（四、五）

1.1             功能概览1. 4 最后,让我们再按照下面的分类,快速的过一下Solr的主要功能: ·用户体验 ·数据建模 ·Solr 4的新功能 在本书中,为你的用户提供良好的搜索体验会一直贯穿全书的主题.所以我们就从用户体验开始,看看Solr是如何让你的用户感觉到爽的. 1.4.1             用户体验类功能 Solr提供了一系列的重要功能来帮助你搭建一个易用的,符合用户直觉的,功能强大的搜索引擎.不过你需要注意的是Solr仅仅是提供了类REST风格的HTTP AP

Solr in Action 第一章翻译(待整理)

Solr in action读书笔记第一篇第一章   第1章 Solr简介 本章速览: ·搜索引擎处理的数据特性 ·常见搜索引擎用例 ·Solr核心模块介绍 ·选择Solr的理由 ·功能概述 Solr 定义: 可扩展性:Solr可以把建立索引和查询处理的运算分布到一个集群内的多台服务器上. 快速部署:Solr是开源软件,安装和配置都很方便,可以根据安装包内的Sample配置直接上手. 优化搜索 :Solr搜索够快.对于复杂的搜索查询,Solr可以做到亚秒级的处理,通常几十毫秒就能处理完一次复杂查