solr中Schema.xml跟solrconfig.xml分析

solr中Schema.xml和solrconfig.xml分析

一、字段配置（schema）

schema.xml位于solr/conf/目录下，类似于数据表配置文件，

定义了加入索引的数据的数据类型，主要包括type、fields和其他的一些缺省设置。

1、先来看下type节点，这里面定义FieldType子节点，包括name,class,positionIncrementGap等一些参数。

name：就是这个FieldType的名称。class：指向org.apache.solr.analysis包里面对应的class名称，用来定义这个类型的行为。

?

??<copyField?source="includes"?dest="text"?/>

在添加索引时，将所有被拷贝field（如cat）中的数据拷贝到text field中

作用：

将多个field的数据放在一起同时搜索，提供速度将一个field的数据拷贝到另一个，可以用2种不同的方式来建立索引。

?<dynamicField?name="*_i"?type="int"?indexed="true"?stored="true"?/>

?如果一个field的名字没有匹配到，那么就会用动态field试图匹配定义的各种模式。

"*"只能出现在模式的最前和最后较长的模式会被先去做匹配如果2个模式同时匹配上，最先定义的优先

?<dynamicField?name="*"?type="ignored"?multiValued="true"?/>

如果通过上面的匹配都没找到，可以定义这个，然后定义个type，当String处理。（一般不会发生）

但若不定义，找不到匹配会报错。

?5、其他一些标签

?<uniqueKey>id</uniqueKey>

文档的唯一标识，?必须填写这个field（除非该field被标记required="false"），否则solr建立索引报错。

<defaultSearchField>text</defaultSearchField>

如果搜索参数中没有指定具体的field，那么这是默认的域。

<solrQueryParser?defaultOperator="OR"?/>

配置搜索参数短语间的逻辑，可以是"AND|OR"。

?

二、solrconfig.xml

?1、索引配置

?mainIndex 标记段定义了控制Solr索引处理的一些因素.

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

useCompoundFile：通过将很多Lucene内部文件整合到一个文件，来减少使用中的文件的数量。这可有助于减少Solr使用的文件句柄的数目，代价是降低了性能。除非是应用程序用完了文件句柄，否则false的默认值应该就已经足够了。mergeFacor：决定Lucene段被合并的频率。较小的值（最小为2）使用的内存较少但导致的索引时间也更慢。较大的值可使索引时间变快但会牺牲较多的内存。（典型的 时间与空间 的平衡配置）maxBufferedDocs：在合并内存中文档和创建新段之前，定义所需索引的最小文档数。段 是用来存储索引信息的Lucene文件。较大的值可使索引时间变快但会牺牲较多内存。maxMergeDocs：控制可由Solr合并的 Document 的最大数。较小的值（<10,000）最适合于具有大量更新的应用程序。maxFieldLength：对于给定的Document，控制可添加到Field的最大条目数，进而阶段该文档。如果文档可能会很大，就需要增加这个数值。然后，若将这个值设置得过高会导致内存不足错误。unlockOnStartup：告知Solr忽略在多线程环境中用来保护索引的锁定机制。在某些情况下，索引可能会由于不正确的关机或其他错误而一直处于锁定，这就妨碍了添加和更新。将其设置为true可以禁用启动索引，进而允许进行添加和更新。（锁机制）

?2、查询处理配置

?query标记段中以下一些与缓存无关的特性：

maxBooleanClauses：定义可组合在一起形成以个查询的字句数量的上限。正常情况1024已经足够。如果应用程序大量使用了通配符或范围查询，增加这个限制将能避免当值超出时，抛出TooMangClausesException。enableLazyFieldLoading：如果应用程序只会检索Document上少数几个Field，那么可以将这个属性设置为true。懒散加载的一个常见场景大都发生在应用程序返回一些列搜索结果的时候，用户常常会单击其中的一个来查看存储在此索引中的原始文档。初始的现实常常只需要现实很短的一段信息。若是检索大型的Document，除非必需，否则就应该避免加载整个文档。

?query部分负责定义与在Solr中发生的时间相关的几个选项：

?概念：Solr（实际上是Lucene）使用称为Searcher的Java类来处理Query实例。Searcher将索引内容相关的数据加载到内存中。根据索引、CPU已经可用内存的大小，这个过程可能需要较长的一段时间。要改进这一设计和显著提高性能，Solr引入了一张“温暖”策略，即把这些新的Searcher联机以便为现场用户提供查询服务之前，先对它们进行“热身”。

newSearcher和firstSearcher事件，可以使用这些事件来制定实例化新Searcher或第一个Searcher时，应该执行哪些查询。如果应用程序期望请求某些特定的查询，那么在创建新Searcher或第一个Searcher时就应该反注释这些部分并执行适当的查询。

?query中的智能缓存：

filterCache：通过存储一个匹配给定查询的文档 id 的无序集，过滤器让 Solr 能够有效提高查询的性能。缓存这些过滤器意味着对Solr的重复调用可以导致结果集的快速查找。更常见的场景是缓存一个过滤器，然后再发起后续的精炼查询，这种查询能使用过滤器来限制要搜索的文档数。queryResultCache：为查询、排序条件和所请求文档的数量缓存文档 id 的有序集合。documentCache：缓存Lucene Document，使用内部Lucene文档id（以便不与Solr唯一id相混淆）。由于Lucene的内部Document id 可以因索引操作而更改，这种缓存不能自热。Named caches：命名缓存是用户定义的缓存，可被 Solr定制插件 所使用。

其中filterCache、queryResultCache、Named caches（如果实现了org.apache.solr.search.CacheRegenerator）可以自热。

每个缓存声明都接受最多四个属性：

class：是缓存实现的Java名size：是最大的条目数initialSize：是缓存的初始大小autoWarmCount：是取自旧缓存以预热新缓存的条目数。如果条目很多，就意味着缓存的hit会更多，只不过需要花更长的预热时间。

对于所有缓存模式而言，在设置缓存参数时，都有必要在内存、cpu和磁盘访问之间进行均衡。统计信息管理页（管理员界面的Statistics）对于分析缓存的 hit-to-miss 比例以及微调缓存大小的统计数据都非常有用。而且，并非所有应用程序都会从缓存受益。实际上，一些应用程序反而会由于需要将某个永远也用不到的条目存储在缓存中这一额外步骤而受到影响。

?

转载自：http://blog.csdn.net/escaflone/article/details/5726320