【郑州校区】知识点解析之solrconfig.xml

这个配置文件主要配置跟索引库和请求处理相关的配置。solr服务的优化主要通过这个配置文件进行

<lib/>标签：

· 用途：配置插件依赖的jar包

· 注意事项：

o 如果引入多个jar包，要注意包和包的依赖关系，被依赖的包配置在前面

o 这里的jar包目录如果是相对路径，那么是相对于core所在目录

例如，在配置文件中默认有以下配置：

        这些是Solr中插件所依赖的Jar包

这里的相对路径其实是相对于 core所在目录。

        我们把所以来的Jar包复制到solr的HOME中：

然后修改配置文件：

效果：

<requestHandler/>标签：

· 用途：配置Solr处理各种请求（搜索/select、更新索引/update、等）的各种参数

· 主要参数：

o name：请求类型，例如：select、query、get、update

o class：处理请求的类

o initParams：可选。引用<initParams>标签中的配置

o <lst name="defaults">：定义各种缺省的配置，比如缺省的parser、缺省返回条数

例子： 负责搜索请求的Handler

        这里有一个默认选项：rows=10 ，就是设置默认查10条数据

        <str name=”df”> text</str> 这个是设置默认搜索的字段为：text，我们可以设置为title,因为我们没有text字段

<initParams/>标签：

· 用途：为一些requestHandlers定义通用的配置，以便在一个地方修改后，所有地方都生效

· 主要参数：

o path：指明该配置应用于哪些请求路径，多个 的话用逗号分开，可以用通配符（*表示一层子路径，**表示无限层）

o name：如果不指定path，可以指定一个name，然后在<requestHander>配置中可以引用这个name

例子（配置一个缺省的df）：  <initParams path="/update/**,/query,/select,/tvrh,/elevate,/spell,/browse">    <lst name="defaults">      <str name="df">_text_</str>    </lst>  </initParams>
如果配置name，在<requestHander>中引用的例子：<requestHandler name="/dump1" class="DumpRequestHandler"  initParams="myParams"/>

<updateHandler/>标签：

· 用途：定义一些更新索引相关的参数，比如定义commit的时机

· 主要参数：

o autoCommit：定义自动commit的触发条件。如果没配置这个参数，则每次都必须手动commit

§ maxDocs

§ maxTime（毫秒）

§ openSearcher：autoCommit结束后，是否开启一个新的searcher让更改生效。缺省为false

o autoSoftCommit：定义自动softCommit的触发条件。相关参数同autoCommit

o listener：配置事件监听器

§ event：监听哪个事件，比如：event="postCommit", event="postOptimize"

§ class：处理的类，可以是自己的实现类。如果是RunExecutableListener，可以配置下面的参数：

§ exe：可执行文件，包括Solr Home的相对路径和文件名

§ dir：工作目录，缺省是“.”

§ wait： 调用者是否等待可执行文件执行结束，缺省是true

§ args：传递给可执行文件的参数

§ env：其他所需要的环境变量

o updateLog：配置log的保存路径、等

§ dir：保存路径

§ numRecordsToKeep：一个log保存的记录数，缺省为100

§ maxNumLogsToKeep：log的数量，缺省为10

§ numversionBuckets：追踪max version的bucket数量（？），缺省为65535

配置这些参数要考虑到搜索的准确度和性能的平衡。^_^
注：commit和softCommit：

· commit：正式提交、对索引的修改会被保存到永久存储中（比如磁盘），会比较耗时

· softCommit：软提交，对索引的修改会被立即应用到工作中的索引中，即立即生效，但没有保存进磁盘

<query/>标签：

· 用途：配置Solr如何处理和返回搜索的相关参数

· 主要参数：

o filterCache：当搜索带有“fq”参数时，使用这个配置，它保存未经过排序的所有文档

§ class：实现类，有三种：solr.search.LRUCache, solr.search.FastLRUCache, solr.search.LFUCache

§ size：最大保存的记录数量

§ initialSize：初始数量

§ autowarmCount：新Index Searcher启动的时候从旧的Index Searcher缓存拷贝过来的数据量

o queryResultCache：存储最终的搜索结果（排序后的、有范围的文档id）

§ class：实现类，有三种：solr.search.LRUCache, solr.search.FastLRUCache, solr.search.LFUCache

§ size：最大保存的记录数量

§ initialSize：初始数量

§ autowarmCount：新Index Searcher启动的时候从旧的Index Searcher缓存拷贝过来的数据量

§ maxRamMB：最大分配的容量（兆）

o documentCache：缓存Lucene Document对象（就是每个文档的fields）

§ class：实现类，有三种：solr.search.LRUCache, solr.search.FastLRUCache, solr.search.LFUCache

§ size：最大保存的记录数量

§ initialSize：初始数量

§ autowarmCount：因为Lucene的内部文档 id 是临时的，所以这个缓存不应该被auto-warm，这个值应该为“0”

o cache：配置自定义的缓存，通过SolrIndexSearcher类的getCache()方法和name参数调用这个缓存

§ name：被调用时的标识

§ 其他参数同上

o maxBooleanClauses：BooleanQuery的最大子句数量

o enableLazyFieldLoading：没有知道被请求的field是否懒加载，true/false

o useFilterForSortedQuery：如果不是按照score排序，是否从filterCache中获取数据

o queryResultWindowsize：配合queryResultCache使用，缓存一个超集。如果搜索请求第10到19条记录，而这个参数是50，那么会缓存0到49条记录

o queryResultMaxDocsCached：queryResultCache缓存的最大文档数量

o useColdSearcher：但一个新searcher正在warm-up的时候，新请求是使用旧是searcher（true）还是等待新的search（false）

o maxWarmingSearchers：定义同时在warn-up的searcher的最大数量

o listener：监听一些事件并指定处理的类，比如在solr启动时加载一些数据到缓存中，相关参数：

§ event：被监听的事件，比如：firstSearcher是第一个searcher启动、也就是solr启动的事件，newSearcher是当已经有searcher在运行的时候有新searcher启动的事件

§ class：处理类

§ name：="queries"就是需要处理的是query

§ lst, name：针对哪些搜索条件需要处理

<requestDispatcher/>标签：

· 用途：控制Solr HTTP RequestDispatche r响应请求的方式，比如：是否处理/select url、是否支持对流的处理、上传文件的大小、如何处理带有cache头的HTTP请求、等等

· 主要参数：

o handleSelect：true/false，如果是false，则由requestHandler来处理/select请求。因为现在的requestHandler中/select是标配，所以这里应该填false

o requestParsers：

§ enableRemoteStreaming：是否接受流格式的内容，缺省为ture

§ multipartUploadLimitInKB：multi-part POST请求，上传文件的大小上限（K）

§ formdataUploadLimitInKB：HTTP POST的form data大小上限（K）

§ addHttpRequestToContext：原始的HttpServletRequest对象是否应该被包含在SolrQueryRequest的httpRequest中……一般自定义的插件使用这个参数……

o httpCaching：如何处理带有cache control头的HTTP请求

§ nerver304：如果设为true（开发阶段），则就算所请求的内容没被修改，也不会返回304，并且下面两个参数会失效

§ lastModFrom：最后修改时间的计算方式，openTime：Searcher启动的时刻；dirLastMod：索引更新的时刻

§ etagSeed：HTTP返回的ETag头内容

§ cacheControl：HTTP返回的Cache-Control头内容

<updateProcessor/>和<updateProcessorChain/>标签：

· 用途：配置处理update请求的处理器、处理器链。如果不配置的话，Solr会使用缺省的三个处理器：

o LogUpdateProcessorFactory：追踪和记录日志

o DistributedUpdateProcessorFactory：分流update请求到不同的node，比如SolrCloud的情况下把请求分配给一个shard的leader，然后把更新应用到所有replica中

o RunUpdateProcessorFactory：调用Solr的内部API执行update操作

· 如果需要自定义update处理器：

o updateProcessor：

§ class：负责处理的类

§ name：名字，给updateProcessorChain引用是使用

o updateProcessorChain：

§ name：自己的名字标记

§ processor：指定updateProcessor的name，多个的话用逗号“,”分开

传智播客·黑马程序员郑州校区地址

河南省郑州市 高新区长椿路11号大学科技园（西区）东门8号楼三层

联系电话 0371-56061160/61/62

来校路线  地铁一号线梧桐街站A口出

【郑州校区】知识点解析之solrconfig.xml

这个配置文件主要配置跟索引库和请求处理相关的配置。solr服务的优化主要通过这个配置文件进行

<lib/>标签：

· 用途：配置插件依赖的jar包

· 注意事项：

o 如果引入多个jar包，要注意包和包的依赖关系，被依赖的包配置在前面

o 这里的jar包目录如果是相对路径，那么是相对于core所在目录

例如，在配置文件中默认有以下配置：

        这些是Solr中插件所依赖的Jar包

这里的相对路径其实是相对于 core所在目录。

        我们把所以来的Jar包复制到solr的HOME中：

然后修改配置文件：

效果：

<requestHandler/>标签：

· 用途：配置Solr处理各种请求（搜索/select、更新索引/update、等）的各种参数

· 主要参数：

o name：请求类型，例如：select、query、get、update

o class：处理请求的类

o initParams：可选。引用<initParams>标签中的配置

o <lst name="defaults">：定义各种缺省的配置，比如缺省的parser、缺省返回条数

例子： 负责搜索请求的Handler

        这里有一个默认选项：rows=10 ，就是设置默认查10条数据

        <str name=”df”> text</str> 这个是设置默认搜索的字段为：text，我们可以设置为title,因为我们没有text字段

<initParams/>标签：

· 用途：为一些requestHandlers定义通用的配置，以便在一个地方修改后，所有地方都生效

· 主要参数：

o path：指明该配置应用于哪些请求路径，多个 的话用逗号分开，可以用通配符（*表示一层子路径，**表示无限层）

o name：如果不指定path，可以指定一个name，然后在<requestHander>配置中可以引用这个name

例子（配置一个缺省的df）：  <initParams path="/update/**,/query,/select,/tvrh,/elevate,/spell,/browse">    <lst name="defaults">      <str name="df">_text_</str>    </lst>  </initParams>
如果配置name，在<requestHander>中引用的例子：<requestHandler name="/dump1" class="DumpRequestHandler"  initParams="myParams"/>

<updateHandler/>标签：

· 用途：定义一些更新索引相关的参数，比如定义commit的时机

· 主要参数：

o autoCommit：定义自动commit的触发条件。如果没配置这个参数，则每次都必须手动commit

§ maxDocs

§ maxTime（毫秒）

§ openSearcher：autoCommit结束后，是否开启一个新的searcher让更改生效。缺省为false

o autoSoftCommit：定义自动softCommit的触发条件。相关参数同autoCommit

o listener：配置事件监听器

§ event：监听哪个事件，比如：event="postCommit", event="postOptimize"

§ class：处理的类，可以是自己的实现类。如果是RunExecutableListener，可以配置下面的参数：

§ exe：可执行文件，包括Solr Home的相对路径和文件名

§ dir：工作目录，缺省是“.”

§ wait： 调用者是否等待可执行文件执行结束，缺省是true

§ args：传递给可执行文件的参数

§ env：其他所需要的环境变量

o updateLog：配置log的保存路径、等

§ dir：保存路径

§ numRecordsToKeep：一个log保存的记录数，缺省为100

§ maxNumLogsToKeep：log的数量，缺省为10

§ numversionBuckets：追踪max version的bucket数量（？），缺省为65535

配置这些参数要考虑到搜索的准确度和性能的平衡。^_^
注：commit和softCommit：

· commit：正式提交、对索引的修改会被保存到永久存储中（比如磁盘），会比较耗时

· softCommit：软提交，对索引的修改会被立即应用到工作中的索引中，即立即生效，但没有保存进磁盘

<query/>标签：

· 用途：配置Solr如何处理和返回搜索的相关参数

· 主要参数：

o filterCache：当搜索带有“fq”参数时，使用这个配置，它保存未经过排序的所有文档

§ class：实现类，有三种：solr.search.LRUCache, solr.search.FastLRUCache, solr.search.LFUCache

§ size：最大保存的记录数量

§ initialSize：初始数量

§ autowarmCount：新Index Searcher启动的时候从旧的Index Searcher缓存拷贝过来的数据量

o queryResultCache：存储最终的搜索结果（排序后的、有范围的文档id）

§ class：实现类，有三种：solr.search.LRUCache, solr.search.FastLRUCache, solr.search.LFUCache

§ size：最大保存的记录数量

§ initialSize：初始数量

§ autowarmCount：新Index Searcher启动的时候从旧的Index Searcher缓存拷贝过来的数据量

§ maxRamMB：最大分配的容量（兆）

o documentCache：缓存Lucene Document对象（就是每个文档的fields）

§ class：实现类，有三种：solr.search.LRUCache, solr.search.FastLRUCache, solr.search.LFUCache

§ size：最大保存的记录数量

§ initialSize：初始数量

§ autowarmCount：因为Lucene的内部文档 id 是临时的，所以这个缓存不应该被auto-warm，这个值应该为“0”

o cache：配置自定义的缓存，通过SolrIndexSearcher类的getCache()方法和name参数调用这个缓存

§ name：被调用时的标识

§ 其他参数同上

o maxBooleanClauses：BooleanQuery的最大子句数量

o enableLazyFieldLoading：没有知道被请求的field是否懒加载，true/false

o useFilterForSortedQuery：如果不是按照score排序，是否从filterCache中获取数据

o queryResultWindowsize：配合queryResultCache使用，缓存一个超集。如果搜索请求第10到19条记录，而这个参数是50，那么会缓存0到49条记录

o queryResultMaxDocsCached：queryResultCache缓存的最大文档数量

o useColdSearcher：但一个新searcher正在warm-up的时候，新请求是使用旧是searcher（true）还是等待新的search（false）

o maxWarmingSearchers：定义同时在warn-up的searcher的最大数量

o listener：监听一些事件并指定处理的类，比如在solr启动时加载一些数据到缓存中，相关参数：

§ event：被监听的事件，比如：firstSearcher是第一个searcher启动、也就是solr启动的事件，newSearcher是当已经有searcher在运行的时候有新searcher启动的事件

§ class：处理类

§ name：="queries"就是需要处理的是query

§ lst, name：针对哪些搜索条件需要处理

<requestDispatcher/>标签：

· 用途：控制Solr HTTP RequestDispatche r响应请求的方式，比如：是否处理/select url、是否支持对流的处理、上传文件的大小、如何处理带有cache头的HTTP请求、等等

· 主要参数：

o handleSelect：true/false，如果是false，则由requestHandler来处理/select请求。因为现在的requestHandler中/select是标配，所以这里应该填false

o requestParsers：

§ enableRemoteStreaming：是否接受流格式的内容，缺省为ture

§ multipartUploadLimitInKB：multi-part POST请求，上传文件的大小上限（K）

§ formdataUploadLimitInKB：HTTP POST的form data大小上限（K）

§ addHttpRequestToContext：原始的HttpServletRequest对象是否应该被包含在SolrQueryRequest的httpRequest中……一般自定义的插件使用这个参数……

o httpCaching：如何处理带有cache control头的HTTP请求

§ nerver304：如果设为true（开发阶段），则就算所请求的内容没被修改，也不会返回304，并且下面两个参数会失效

§ lastModFrom：最后修改时间的计算方式，openTime：Searcher启动的时刻；dirLastMod：索引更新的时刻

§ etagSeed：HTTP返回的ETag头内容

§ cacheControl：HTTP返回的Cache-Control头内容

<updateProcessor/>和<updateProcessorChain/>标签：

· 用途：配置处理update请求的处理器、处理器链。如果不配置的话，Solr会使用缺省的三个处理器：

o LogUpdateProcessorFactory：追踪和记录日志

o DistributedUpdateProcessorFactory：分流update请求到不同的node，比如SolrCloud的情况下把请求分配给一个shard的leader，然后把更新应用到所有replica中

o RunUpdateProcessorFactory：调用Solr的内部API执行update操作

· 如果需要自定义update处理器：

o updateProcessor：

§ class：负责处理的类

§ name：名字，给updateProcessorChain引用是使用

o updateProcessorChain：

§ name：自己的名字标记

§ processor：指定updateProcessor的name，多个的话用逗号“,”分开

传智播客·黑马程序员郑州校区地址

河南省郑州市 高新区长椿路11号大学科技园（西区）东门8号楼三层

联系电话 0371-56061160/61/62

来校路线  地铁一号线梧桐街站A口出