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

haixin3036

　　本章关注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)
　　
　　
　　　　explicit
　　　　10
　　　　text
　　

　　使用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，设置为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是一个很好的参考。