Solr in action学习笔记 第四章 Solr Config

本章关注solrconfig.xml
Solr为web应用，有一个系统变量solr.solr.home指明Solr目录，
启动Solr核后，有一个/server下有一个应用目录，该目录下有一个core.properties，一个conf文件夹和一个data文件夹。
core.properties用于配置core，所以solr可以用该文件自动发现core，然后Solr用solrconfig初始化core。

4.1 Overview of solrconfig.xml

4.1.1Common XML data-structure and type elements

arr的子元素没名字，而lst的子元素有名字

4.1.2Applying configuration changes

Sorl Admin界面中core Admin中的Reload可以使新的solrconfig生效！

4.1.3Miscellaneous settings

*LUCENE VERSION

如果使用升级版solr时，对应的lucene版本也最后升级。这时需要重新索引所有文档，或使用lucene内置的索引升级工具进行升级！

*LOADING DEPENDENCY JAR FILES

导入任何Solr运行时需要的jar，包括分词使用的分词器和过滤器等，相对路径为core的文件夹，如果jar有依赖性，则在solrconfig中也要按顺序定义。

dir选项导入目录中所有的jar，若果有regex正则表达式，则匹配的jar被导入

lib可以导入具体的jar，但如果找不到，则会出错！

将jar包放在/server/solr/lib下将自动导入！

*ENABLE JMX

开启JMX功能，详见第12章

Solr为Mbeans提供管理界面

 

4.2Query request handling 

Solr主要目的是搜索，所以搜索请求是Solr中最重要的过程之一。本节介绍Solr的搜索请求以及定制请求处理器

4.2.1 Request-handling overview

对Solr的请求通过HTTP协议，向Solr的query实质上是一个HTTP GET请求。如果向索引文档，向Solr发送HTTP POST请求

处理流程如下

1.客户端程序提交HTTP GET请求给solr

2.Jetty接收请求，并转发。原理是servlet：org.apache.solr.servlet.SolrDispatchFilter

3.分发器有url找到core，和/select，在solrconfig中定义的selec处理器

4.select处理器使用搜索组件管道处理请求

5.处理完毕，有response writer返回结果

一般情况下，默认的处理器可以满足大多数需求，但也允许用户定制处理器以满足特殊需求！

4.2.2 search handler(/select)

<requestHandler name="/select"　class="solr.SearchHandler">
　　<lst name="defaults">
　　　　<str name="echoParams">explicit</str>
　　　　<int name="rows">10</int>
　　　　<str name="df">text</str>
　　</lst>
</requestHandler>

使用Java类solr.SearchHandler处理请求，运行时定位到org.apache.solr.handler.component.SearchHandler（怎么定位的？？？）

 

（应该是自动搜索solr下的各个包，需要保证整个solr下的类名不冲突！）

Solr中有两大类处理器：搜索处理器用于query和更新处理器用于index。本节专注于搜索处理器！

搜索处理器流程：

1.参数：可以配3类参数：

　　default：客户端不提供的默认参数，例如可以在电商网站中默认开启facet功能

　　append：自动添加的参数，如附加query限制，应该慎用

　　invariants：不变量，强制覆盖其他参数，限制客户端功能等，更加慎用！

2.first-components：可选择的预处理组件

3.components：基本搜索组件，至少要包含query组件

4.last-components：可选择的最后处理组件

不需要在solrconfig中定义所有的过程，未定义的继承SearchHandler的实现

4.2.3Browse request handler for Solritas: an example

使用default等参数可以减少客户端程序的编码。

 

4.2.4Extending query processing with search components

Solr 默认搜索处理器内置了6个搜索组件，用户可以增加预处理和后处理组件

*Query组件：分析和执行query。具体的策略有defTpye参数控制，第7章

query组件提供匹配的文档集供后面的组件使用，query组件总是可用的，其它组件需要明确的开启。

*FACET COMPONENT：如果开启，提供field层面的分组，第8章

*MORE L IKE T HIS COMPONENT：提供相似文档

*Highlight

*Stats组件：统计组件，对数值field进行数据统计

*Debug组件：提供分析后的query和评分的详细信息等

*内置组件前后可以加入定制组件，如spell check（也可以由客户端参数还开启spell check）

 

4.3Managing searchers

query标签配置query时间的参数，例如缓存,new searcher?等，用来优化query的性能

4.3.1New searcher overview

Solr 中，query由searcher处理，任何时候只有一个活跃的searcher，对lucene index进行只读操作，若果更新index，则新的index是不可见的，只有关闭searcher，重新打开，才使新的索引可见，这个过程又成为文档的commit过程。

如果用post更新索引，可以在solr管理见面观察到searcher名称的变化，因为post命令在添加文档后执行commit。

（理解：searcher可以理解为query component中用来读取lucene索引的类）

new searcher内部过程：老的searcher必须销毁，但如果有当前执行的query，就必须等待当前query执行完毕。并且所有基于老的searcher的对象也需要销毁，例如缓存中的结果文档对new searcher应该是无效的。

所以new searcher是一个耗时的操作。

好消息是solr有很多工具还减轻这一情况。首要的，Solr提供new searcher哎后台“热身”warming的概念，旧的searcher仍工作，知道新的searcher热身好。

4.3.2 Warming a new searcher

两种类型：autowarming new caches from the old caches and executing cache-warming queries

autowarming下节介绍

 executing cache-warming queries：在new searcher创建时执行，在solrconfig中配置

理解：预先执行一些query放入new searcher的缓存。通过事件监听器配置，可以用自己的监听器。

*应使用尽量少的warming queries，避免warming过慢，耗费cpu和内存资源

*first searcher：solr初始化时候的warming（没有老的searcher）。大多数应用new和first使用相同的queries。

*USE COLD SEARCHER：默认为false，表示在没有当前searcher的情况下请求等待热身，true表示立即执行请求，忽视热身程度。

*MAX WARMING SEARCHERS：如果频繁commit且warm时间过长，则会出现多个searcher同时warming的情况。solr运行配置最大的热身searcher数量，默认为2

 

4.4 Cache management

4.4.1 Cache fundamentals

Solr caches的四个主要关注点。

■Cache sizing and eviction policy
■Hit ratio and evictions
■Cached-object invalidation

■Autowarming new caches

cache需要持续关注并配置好，UI界面是个好帮手

CACHE SIZING：

　　不希望缓存过大。Solr把缓存放在内存中，需要设置一个缓存上限。如果达到上限，Solr会驱逐缓存中的对象，有一个驱逐策略类似于页面调度。

　　LRU基于对象最后使用的时间进行驱逐。是Solr的默认配置。

　　LFU基于对象使用的频率。

　　Cache是对应于searcher的，commit之后cache就失效了，所以即使内存足够大，也不希望cache太大！

*HIT RATIO AND EVICTIONS

 命中率是cache读请求命中的比例？揭示应用受益于cache的程度。eviction对被驱逐的对象计数，如果过大，暗示cache的存储上限过小。命中率和计数是相关的。

*CACHED-OBJECT INVALIDATION 

 Cache中的对象同searcher的生命周期相同！

*AUTOWARMING NEW CACHES

自动热身：自动复制旧的cache到新的cache？（不对，有些对象改变了，不能复制）

　　　　     自动执行热身工作，例如重写执行旧的query等工作

4.4.2 Filter cache

Solr filter用于过滤搜索结果，但不影响评分。

在相同的过滤执行不同的query时，可以利用缓存，优化性能，详细见第7章！具体怎么利用缓存暂时不清楚。

我的理解：先执行filter，将结果缓存。再执行相同filter的query时，只需要在缓存结果中query！

*AUTOWARMING THE FILTER CACHE：

因为索引变了，对象不容易从旧的缓存移动到新的缓存，例如filter缓存。缓存中每个对象都有一个key。filter缓存的key就是filter的query语句。自动热身filter缓存实际上就是重新执行filter query。所以自动热身是一个耗费时间和资源的操作。如果对太多的filter自动热身，会耗费大量的时间，这是一个糟糕的搜索引擎设计。

我们建议自动热身较小的filter，并使用lfu策略更加合理。

具体的配置则需要更具具体的应用，试验性的配置。

内存耗费：MaxDoc(索引中文档书)位内存。

理解：每一位表示给文档是否命中，是一种按位编码压缩数据的方式，1千万的文档每一个filter就需要1.2mb左右的内存。

 

4.4.3 Query result cache

如果执行重复query，那么搜索结果chace将会极大的提高性能。

搜索结果cahce保存query作为key，lucene的index ID。与searcher生命周期相同。

Solr还提供多样化的配置来fine-tune缓存设置

*QUERY RESULT WINDOW SIZE

设置为每页显示数的2-3倍以防用户进入第2页，这样就会直接返回结果而不用再去取结果和生成结果

可以通过log数据来挖掘用户行为，设置合理的QUERY RESULT WINDOW SIZE

*QUERY RESULT MAX DOCS CACHED

设置搜索结果缓存的文档数上限以防浪费太多的内存。

*ENABLE LAZY FIELD LOADING

Solr的query可能只要求返回一些特定的field，设置<enableLazyFieldLoading>为true可以避免载入不用的field

4.4.4 Document cache

搜索结果缓存只保存文档id，需要读取磁盘来生成结果。文档缓存用来保存文档以供搜索结果缓存使用。如果index更新频繁，solr将不会从这个特性收益。如果index相对稳定，则可以优化性能。

4.4.5 Field value cache

lucene用的缓存，用来保存域值，进行排序和生成结果等，不在solr中配置

 

4.5Remaining configuration options

Solr还提供很多额外的配置，包括超出本书范围的专家级别配置。solr example提供的solrconfig是一个很好的参考。