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

古城微笑少年丶 2024-02-18 15:59 42阅读 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都会被收集并缓存。这样，任何更多的在这个范围内的请求都会通过缓存来满足查询。