Solr配置文件说明

运行solr是个很简单的事,如何让solr高效运行你的项目,这个就不容易了。

要考虑的因素太多。这里很重要一个就是对solr的配置要了解。懂得配置文件每个配置项的含义,这样操作起来就会如鱼得水!

在solr里面主要的就是solr的主目录下面的schema.xml,solrConfig.xml。

solrconfig.xml,主要定义solr的处理程序(handler)和一些扩展程序;

schema.xml,主要定义索引的字段和字段类型。

 

1. schema.xml

 

 

schema.xml,这个相当于数据表配置文件,它定义了加入索引的数据的数据类型的。
主要包括types、fields和其他的一些缺省设置。
注:schema.xml里有一个uniqueKey,的配置,这里将id字段作为索引文档的唯一标识符,非常重要。

id

 

1.1. FieldType(类型)


首先需要在types结点内定义一个FieldType子结点,包括name,class,positionIncrementGap等等一些参数,name就是这个FieldType的名称,class指向org.apache.solr.analysis包里面对应的class名称,用来定义这个类型的行为。

在FieldType定义的时候,最重要的就是定义这个类型的数据在建立索引和进行查询的时候要使用的分析器analyzer,包括分词和过滤。

例如:


     
       
       
       
                        ignoreCase="true"
                words="stopwords.txt"
                enablePositionIncrements="true"
                />
       
       
       
       
     

     ……
   

在index的analyzer中使用 solr.WhitespaceTokenizerFactory这个分词包,就是空格分词。

然后使用 solr.StopFilterFactory,solr.WordDelimiterFilterFactory,solr.LowerCaseFilterFactory,solr.EnglishPorterFilterFactory,solr.RemoveDuplicatesTokenFilterFactory 这几个过滤器。

在向索引库中添加text类型的索引的时候,Solr会首先用空格进行分词,然后把分词结果依次使用指定的过滤器进行过滤,最后剩下的结果才会加入到索引库中以备查询。

Solr的analysis包并没有带支持中文分词的包。

 

1.2. Fields(字段)


接下来的工作就是在fields结点内定义具体的字段(类似数据库中的字段),就是filed。

filed定义包括name,type(为之前定义过的各种FieldType),indexed(是否被索引),stored(是否被储存),multiValued(是否有多个值)等等。

例:

 
 
 
 
 
 
 
 

field的定义相当重要,有几个技巧需注意一下,对可能存在多值得字段尽量设置 multiValued属性为true,避免建索引是抛出错误;如果不需要存储相应字段值,尽量将stored属性设为false。

 

1.3. copyField(复制字段)

 

建议建立了一个拷贝字段,将所有的全文字段复制到一个字段中,以便进行统一的检索:

并在拷贝字段结点处完成拷贝设置:


注:“拷贝字段”就是查询的时候不用再输入:userName:张三 and userProfile:张三的个人简介。

直接可以输入"张三"就可以将“名字”含“张三”或者“简介”中含“张三”的又或者“名字”和“简介”都含有“张三”的查询出来。

他将需要查询的内容放在了一个字段中,并且默认查询该字段设为该字段就行了。


1.4. dynamicField(动态字段)

 

除此之外,还可以定义动态字段,所谓动态字段就是不用指定具体的名称,只要定义字段名称的规则。

例如定义一个 dynamicField,name 为*_i,定义它的type为text,那么在使用这个字段的时候,任何以_i结尾的字段都被认为是符合这个定义的,例如:name_i,gender_i,school_i等。

schema.xml配置文件大体上就是这样,更多细节请参见solr wiki:http://wiki.apache.org/solr/SchemaXml

 

 

 

 

 

2. solrConfig.xml

 

 

 

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

配置取决于模式,但模式不取决于配置。solrconfig.xml文件包含了大部分的参数用来配置Solr本身的。


2.1. dataDir parameter

/var/data/solr
用来指定一个替换原先在Solr目录下默认存放所有的索引数据,可以在Solr目录以外的任意目录中。

如果复制使用后应该符合该参数。如果这个目录不是绝对路径的话,那么应该以当前的容器为相对路径。

2.2. mainIndex 

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

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

2.3. mergeFactor

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

2.4. maxBufferedDocs

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

2.5. maxMergeDocs

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

2.6. maxFieldLength

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

2.7. unlockOnStartup

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



    false
    10
    1000
    2147483647
    10000
 

2.8. updateHandler

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


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

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


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


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


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

      snapshooter
      solr/bin
      true
     

exe--可执行的文件类型
dir--可以用该目录做为当前的工作目录。默认为"."
wait--调用线程要等到可执行的返回值
args--传递给程序的参数 默认nothing
env--环境变量的设置 默认nothing


   
    1024

:
控制跟查询相关的一切东东。

 

2.8. Caching

修改这个参数可以做为索引的增长和变化。


          class="solr.LRUCache"
      size="512"
      initialSize="512"
      autowarmCount="256"/>

  
查询结果缓存
          class="solr.LRUCache"
      size="512"
      initialSize="512"
      autowarmCount="256"/>

 
由于Lucene的内部文档ID标识(文档名称)是短暂的,所以这种缓存不会被自动warmed。
          class="solr.LRUCache"
      size="512"
      initialSize="512"
      autowarmCount="0"/>

   
这么做的的关键就是应该明确规定实现solr.search.CacheRegenerator接口如果autowarming是比较理想化的设置。
   

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

   
    false

 

 

 

你可能感兴趣的:(搜索引擎,Solr)