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是一个很好的参考。