Solr主要配置文件之solrconfig.xml。

最新推荐文章于 2023-05-21 11:08:31 发布

软件求生

最新推荐文章于 2023-05-21 11:08:31 发布

阅读量566

点赞数

分类专栏： # solr 文章标签： solr 搜索

solr 专栏收录该内容

32 篇文章 0 订阅

订阅专栏

在配置方面，solrconfg.xml文件不仅指定了Solr如何处理索引、突出显示、分类、搜索以及其他请求，还指定了用于预定缓存的处理方法的属性，以及用于指定Lucene管理索引的方法的属性。配置取决于模式，但模式不取决于配置。

solrconfig.xml文件包含了大部分的参数用来配置Solr本身的。

dataDirparameter：

用来指定一个替换原先在Solr目录下默认存放所有的索引数据，可以在Solr目录以外的任意目录中。如果复制使用后应该符合该参数。如果这个目录不是绝对路径的话，那么应该以当前的容器为相对路径。

mainindex：

这个参数的值用来控制合并多个索引段。

useCompoundFile：

通过将很多Lucene内部文件整合到单一一个文件来减少使用中的文件的数量。这可有助于减少Solr使用的文件句柄数目，代价是降低了性能。除非是应用程序用完了文件句柄数目，代价是降低了性能。除非是应用程序用完了文件句柄，否则false的默认值应该就已经足够。

mergeFactor：

决定低水平的Lucene段被合并的频率。较小的值（最小为2）使用的内存较少但导致的索引时间也更慢。较大的值可使索引时间变快但会牺牲较多的内存。

maxBufferedDocs：

在合并内存中文档和创建新段之前，定义所需索引的最小文档数。段是用来存储索引信息的Lucene文件。较大的值可使索引时间变快但会牺牲较多的内存。

maxMergeDocs：

控制可由Solr最适合于具有合并的Document的最大数。较小的值大量更新的应用程序。该参数不允许lucene在任何索引段里包含比这个值更多的文档，但是，多余的文档可以创建一个新的索引段进行替换。

maxFieldLength：

对于给定的Document，控制可添加到Field的最大条目数，进而截断该文档。如果文档可能会很大，就需要增加这个数值。然而，若将这个值设置得过高会导致内存不足错误。

unlockOnStartup：

unlockOnStartup告知Solr忽略在多线程环境中用来保护索引的锁定机制。在某些情况下，索引可能会由于不正确的关机或其他错误而一直处于锁定，这就妨碍了添加和更新。将其设置为true可以禁用启动锁定，进而允许进行添加和更新。

<useCompoundFile>false</useCompoundFile>

</mainIndex>

updateHandle：

这个更新处理器主要涉及底层的关于如何更新处理内部的信息（此参数不能跟高层次的配置参数Request Handlers对处理发自客户端的更新相混淆）。

<updateHandlerclass = "solr.DirectUpdateHandler2">
<! -- Limit the number of deletions Solr will buffer during doc updating.

Setting this lower can help bound memory use during indexing.

-->

maxPendingDeletes：

缓冲更新这么多的数目，设置如下比较低的值，可以约束索引时候所用的内存。

autoCommit：

等待文档满足一定的标准后将自动提交，未来版本可以扩展现有的标准。

maxDocs：

触发自动提交前最多可以等待提交的文档数量。

maxTime：

在添加了一个文档之后，触发自动提交之前所最大的等待时间。

listener：

这个参数用来配置执行外部的命令，一个postCommit的事件被触发当每一个提交之后

<str name = "exe">snapshooter</str>

<!--

<arr name = "env"><str>MYVAR=var1</str></arr>

-->

</listener>

exe —— 可执行的文件类型。

dir —— 可以用该目录作为当前的工作目录。默认为“.”。

wait —— 调用线程要等到可执行的返回值。

args —— 传递给程序的参数默认 nothing。

env —— 环境变量的设置默认 nothing。

maxBooleanClauses：

query：

控制跟查询相关的一切。

Caching：

修改这个参数可以做为索引的增长和变化。在过滤器中过滤文档集合的时候，或者是一个无序的所有的文档集合中将在SolrIndexSearcher中使用缓存来匹配符合查询的所有文档。autowarmed，当一次搜索被打开，他可以自动的或者预先从旧的搜索中使用缓存数据。在LRUCACHE中，这个autowarmed项中保存的是最近访问的项。

autowarmCount：这个值是预先设置的数值项。

Parameters：

参数选项。

class —— 实现SolrCache接口的类当前仅有LRUCache。

size —— 在 cache 中最大的上限值。

initialSize —— 在cache中初始化的数量。

autowarmCount —— 从旧的缓存中预先设置的项数。

查询结果缓存：

doucumentCache缓存Lucene的文档对象（存储领域的每一个文件），由于Lucene的内部文档ID标识（文档名称）是短暂的，所以这种缓存不会被自动warmed。

一个通用缓存的例子。这些缓存可以通过在SolrIndexSearcher.getCache().cacheLookup()和cacheInsert()中利用缓存名称访问得到。这样做的目的就是很方便的缓存用户级或应用程序级的数据。这么做的关键就是应该明确规定实现solr.search.CacheRegenerator接口，如果autowarming是比较理想化的设置。

一种优化方式就是利用一个过滤器，以满足搜索寻求。如果请求的不是要求包括得分的类型，filterCache这种过滤器将检查与过滤器相匹配的结果。如果找到，过滤器将被用来作为文档的来源识别码，并在基础上进行排序。

一种优化用于 queryResultCache，当一个搜索被请求，也会收集一定数量的文档ID作为一个超集。举个例子，一个特定的查询请求匹配的文档是10到19，此时，queryWindowSize是50，这样，文档从0到50都会被收集并缓存。这样，任何更多的在这个范围内的请求都会通过缓存来满足查询。