solrconfig.xml 应用解析调优
solrconfig.xml配置文件主要定义了SOLR的一些处理规则,包括索引数据的存放位置,更新,删除,查询的一些规则配置。 <directoryFactory name="DirectoryFactory" class="${solr.directoryFactory:solr.NRTCachingDirectoryFactory}">
<str "solr.hdfs.home">${solr.hdfs.home:}</str>
<"solr.hdfs.confdir">${solr.hdfs.confdir:}</"solr.hdfs.blockcache.enabled">${solr.hdfs.blockcache.enabled:true}</"solr.hdfs.blockcache.global">${solr.hdfs.blockcache.global:true}</str>
</directoryFactory>
5 6 `<mergePolicy class="org.apache.lucene.index.TieredMergePolicy">
<int name="maxMergeAtOnce">20</int>
<"segmentsPerTier">int>
</mergePolicy>`
//合并策略。 7updateHandler节点 `<autoCommit>
<maxDocs>10000</maxDocs>
<maxTime>${solr.autoCommit.maxTime:5000}</maxTime>
<openSearcher>true</openSearcher>
</autoCommit>`
自动硬提交方式:maxTime:设置多长时间提交一次maxDocs:设置达到多少文档提交一次openSearcher:文档提交后是否开启新的searcher,
如果false,文档只是提交到index索引库,搜索结果中搜不到此次提交的文档;如果true,既提交到index索引库,也能在搜索结果中搜到此次提交的内容。
`<autoSoftCommit>`
`<maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime>`
`</autoSoftCommit>` //软提交;
1、把内存文件fsync到磁盘,但不创建index descriptor。也就是说原索引和现在的索引还互不感知,所以如果jvm崩溃,那这部分索引就没了。
2、可以重新打开searcher,使得新的索引可以被查找到。
`<listener event="postCommit" "solr.RunExecutableListener">`
`<"exe">solr/bin/snapshooter</str>` //exe--可执行的文件类型
`<"dir">.</str>`//dir--可以用该目录做为当前的工作目录。默认为 "."
`<bool "wait">true</bool>` //wait--调用线程要等到可执行的返回值
`<arr "args"> <str>arg1</str> <str>arg2</str> </arr>` //args--传递给程序的参数 默认nothing
`<"env"> <str>MYVAR=val1</arr>` //env--环境变量的设置 默认nothing
`</listener>`
//一个postCommit的事件被触发当每一个提交之后,
PS:自己的一些见解,solr提交索引的方式共有三种,通过solr api去提交的方式性能很差,不建议采用;个人建议还是采用autocommit的自动提交,虽然比较消耗资源,但是能最大限度保存意外造成的索引丢失的情况;
更多信息,请查看https://lucidworks.com/blog/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/
8Query查询节点 `<!-- 过滤器缓存 -->
<filterCache "solr.FastLRUCache" size="32768" initialSize=autowarmCount="512"/>`
`<!-- 查询结果缓存 -->
<queryResultCache "8192" <!-- 查询文档缓存 -->
<documentCache "4096" "0"/>`
`<!-- 自定义缓存 -->
<cache "perSegFilter" "solr.search.LRUCache" regenerator="solr.NoOpRegenerator" />`
`<!-- 字段值缓存 -->
<fieldValueCache "512" "128" showItems="32" />`
1)size:cache中可保存的最大的项数,默认是1024
2)initialSize:cache初始化时的大小,默认是1024。
3)autowarmCount:当切换SolrIndexSearcher时,可以对新生成的SolrIndexSearcher做autowarm(预热)处理。autowarmCount表示从旧的SolrIndexSearcher中取多少项来在新的SolrIndexSearcher中被重新生成,如何重新生成由CacheRegenerator实现。在当前的1.4版本的Solr中,这个autowarmCount只能取预热的项数,将来的4.0版本可以指定为已有cache项数的百分比,以便能更好的平衡autowarm的开销及效果。如果不指定该参数,则表示不做autowarm处理。
实现上,LRUCache直接使用LinkedHashMap来缓存数据,由initialSize来限定cache的大小,淘汰策略也是使用LinkedHashMap的内置的LRU方式,读写操作都是对map的全局锁,所以并发性效果方面稍差。
`<enableLazyFieldLoading>true</enableLazyFieldLoading>` //某些字段延时加载,以提高性能,例如内容较多的压缩文件
`<queryResultWindowSize>50</queryResultWindowSize>` //Result Window Size 优化queryResultCache结果cache
`<queryResultMaxDocsCached>800</queryResultMaxDocsCached>` //查询结果文档的最大缓存数
`<!-- 与请求相关的监听器 -->
<!-- QuerySenderListener使用NamedList的数组和每个序列NamedList的执行一个本地查询请求。-->
<"newSearcher" "solr.QuerySenderListener">
<"queries">
</arr>
</listener>
<"firstSearcher" "solr.QuerySenderListener">
<"queries">
<lst>
<"q">static firstSearcher warming in solrconfig.xml</str>
</lst>
</useColdSearcher>true</useColdSearcher>` //使用云搜索
`<maxWarmingSearchers>8</maxWarmingSearchers>`
//该参数用于设置最大的 searcher 数量,这些 searcher 实现预热好的,随时可以调用。如果超过这个数量,将会报错。在一个只读的索引库中,2个预热的 searcher 是相对合理的,如果是读写的索引库中,根据内存和cpu的大小可以给一个相对大一点的值。
9Request Dispatcher(请求转发器) <!-- Request Parsing:请求解析 这些设置说明Solr Requests如何被解析,以及对ContentStreams有什么限制。 enableRemoteStreaming - 是否允许使用stream.file和stream.url参数来指定远程streams。 multipartUploadLimitInKB - 指定多文件上传时Solr允许的最大的size,设置了通过多部分(multi-part)的HTTP POST请求提交的文档大小的上限,单位是Kb。这个值指定为1024的倍数来确定Bytes的大小 formdataUploadLimitInKB - 表单通过POST请求发送的最大size,设置了一个用Kb表示的限制,用以限制HTTP POST请求中提交的表单数据的大小,这个大小可以用来传递请求的参数但并不适合(写入)URL中 addHttpRequestToContext - 用来声明原始的HttpServletRequest对象应该被包括在使用httpRequest的SolrQueryRequest的上下文集合(context map)中。 这个HttpServletRequest不会用于任何Solr的组成部分,但在开发自定义的插件是会很有用 -->`
`<requestParsers enableRemoteStreaming="true" multipartUploadLimitInKB="2048000" formdataUploadLimitInKB="20480" addHttpRequestToContext="false"/>`
`<httpCaching>`元素控制了HTTP缓存控制头(HTTP cache control headers)。不要将这些设置和Solr内部的缓存配置混淆。这个元素控制了W3C HTTP规格定义的HTTP响应的缓存过程。这个元素允许三个属性和一个下级元素。
`<httpCaching>`元素的属性决定了是否允许对一个GET请求进行304响应,如果可以,它应该是什么响应类别(sort)。当一个HTTP用户程序生成一个GET请求,如果资源从上一次被取得后还没有被修改,那么它可以可选择地指定一个可接受的304响应。
never304
如果将这个值设置为true,那么即使请求的资源还没有被修改,一个GET请求也永远不会得到一个304响应。如果这个属性被设置为true,那么接下来的两个属性会被忽略。将这个属性设置为true对于开发来说是方便的,因为当通过支持缓存头的web浏览器或者其他用户修补Solr的响应时,304响应可能会使人混淆。
lastModFrom 这个属性可以设置为openTime(默认值)或者dirLastMod。openTime指示了最后更改时间,相对于客户发送的If-Modified-Since头,
它应该在搜索器开始的时候计算。如果当索引在硬盘上更新时你需要精确同步,那么使用dirLastMod。
etagSeed
这个属性的值被作为ETag头的值。改变这个值可以有助于强制用户重新取得内容,即使索引没有被改变。例如,当你修改了配置的时候。
`<httpCaching never304="false" lastModFrom="openTime" etagSeed="Solr">
<cacheControl>max-age=30,public</cacheControl>
</httpCaching>`
10requestHandler(请求处理器) requestHandler "/query" "solr.SearchHandler">
<lst "defaults">
<"echoParams">explicit</str>
<"wt">json</str> //显示格式
<"indent">true</"df">text</str>
</lst>
</requestHandler>`
这些参数定义了需要返回多少结果(定义值为10),通过参数df定义了搜索的域默认为“text”域。echoParams参数定义了查询中的在调试信息返回的客户端请求中的参数。
另外还要注意在列表中这些默认值定义方法的 变化:当参数是String,integer或其他类型时,定义类型是不同的。
更多信息,请查看https://wiki.apache.org/solr/CoreQueryParameters?action=fullsearch&context=180&value=echoParams&titlesearch=Titles
所有这些在搜索部分描述的参数可以在任何SearchHandlers中定义为默认值(这些参数的细节信息请参考搜索部分)
除了这些默认值,还有一些选择可用于SearchHandler,包括了下面的这些内容:
appends:这个设置允许在用户查询中添加参数的定义。这些参数可能是过滤查询,或者其他可以被加入每一个查询的查询规则。在Solr中没有机制允许客户端覆盖这些添加,所以你应当确定你总是需要在查询中加入这些参数。
`<"appends">
<"fq">inStock:true</lst>`
在这个例子中,过滤查询“inStock:true”会添加到每一个查询上。
Invariants:这个设置允许定义不会被客户端覆盖的参数。在invariants部分定义的值总是会被使用,而不考虑用户或客户端默认的或添加的值。
`<"invariants">
<"facet.field">cat</"facet.field">manu_exact</"facet.query">price:[* TO 500]</"facet.query">price:[500 TO *]</str>
</lst>`
在这个例子中,facet域被定义,这个定义会限制Solr返回的facets。如果客户端请求facets,那么他们只会看到和这个配置的相同的facets。
在request handler最后部分,是组件(component)的定义,它定义了可以被用于一个request
Handler的搜索组件的列表。它们仅在request handler中注册。对搜索组件的更进一步的讨论在搜索组件部分。搜索组件元素只能被用于SearchHandler。
Handler Resolution
客户端可以通过带有“gt”这个参数的“/select/ url”请求,也可以通过在solrconfig.xml配置的方式来决定要访问的SolrRequestHandler。
Solr是通过下面的步骤去选择一个handler并处理请求的.....
寻找name属性跟请求中的qt参数匹配的handler
寻找在配置文件中“default=true”的handler
寻找在配置文件中name属性为“standad”的handler
使用StandardRequestHandler的默认实例
如果你的配置文件solrconfig.xml 包含有name属性为"/select","/update",或"/admin",那么你的程序将不会沿用标准的请求处理过程,而将会是你自己自定义的逻辑。
扩展自己的Handler
实现一个SolrRequestHandler 最简单的方法是去扩展 RequestHandlerBase 类。
更多信息,请参考http://wiki.apache.org/solr/SolrRequestHandler#head-3dfff37b7cc549669ba241eb6050ffdbc80d7e7 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |