indexed fields

    indexed fields 的数量将会影响以下的一些性能：

•         索引时的时候的内存使用量
•         索引段的合并时间
•         优化时间
•         索引的大小

     我们可以通过 将 omitNorms=“true” 来减少indexed fields数量增加所带来的影响。

   stored fields

      Retrieving the stored fields  确实是一种开销。这个开销，受每个文档所存储的字节影响很大。每个文档的所占用的空间越大，文档就显的更稀疏，这样从硬盘中读取数据，就需要更多的i/o操作（通常，我们在存储比较大的域的时候，就会考虑这样的事情，比如存储一篇文章的文档。）

       可以考虑将比较大的域放到solr外面来存储。如果你觉得这样做会有些别扭的话，可以考虑使用压缩的域，但是这样会加重cpu在存储和读取域的时候的负担。不过这样却是可以较少i/0的负担。

       如果，你并不是总是使用 stored fields 的话，可以使用stored field的延迟加载，这样可以节省很多的性能，尤其是使用compressed field 的时候。

 Configuration Considerations

      mergeFactor

         这个是合并因子，这个参数大概决定了segment(索引段)的数量。

         合并因子这个值告诉lucene，在什么时候，要将几个segment合并成为一个segment, 合并因子就像是一个数字系统的基数一样。

         比如说，如果你将合并因子设成10，那么每往索引中添加1000个文档的时候，就会创建一个新的索引段。当第10个大小为1000的索引段添加进来的时候，这十个索引段就会被合并成一个大小为10，000的索引段。当十个大小为10，000的索引段生成的时候，它们就会被合并成一个大小为100，000 的索引段。如此类推下去。

         这个值可以在 solrconfig.xml 中的 *mainIndex*中设置。（不用管indexDefaults中设置）

       mergeFactor Tradeoffs

         较高的合并因子

•         会提高索引速度
•         较低频率的合并，会导致 更多的索引文件，这会降低索引的搜索效率

          较低的合并因子

•         较少数量的索引文件，能加快索引的搜索速度。
•         较高频率的合并，会降低索引的速度。

Cache autoWarm Count Considerations

      当一个新的 searcher 打开的时候，它缓存可以被预热，或者说使用从旧的searcher的缓存的数据来“自动加热”。autowarmCount是这样的一个参数，它表示从旧缓存中拷贝到新缓存中的对象数量。autowarmCount这个参数将会影响“自动预热”的时间。有些时候，我们需要一些折中的考虑，seacher启动的时间和缓存加热的程度。当然啦，缓存加热的程度越好，使用的时间就会越长，但往往，我们并不希望过长的seacher启动时间。这个autowarm 参数可以在solrconfig.xml文件中被设置。

       详细的配置可以参考solr的wiki。

Cache hit rate（缓存命中率）

       我们可以通过solr的admin界面来查看缓存的状态信息。提高solr缓存的大小往往是提高性能的捷径。当你使用面搜索的时候，你或许可以注意一下filterCache,这个是由solr实现的缓存。

Explicit Warming of Sort Fields 

       如果你有许多域是基于排序的，那么你可以在"newSearcher"和"firstSearcher"event listeners中添加一些明显需要预热的查询，这样FieldCache 就会缓存这部分内容。

 Optimization Considerations

        优化索引，是我们经常会做的事情，比如，当我们建立好索引，然后这个索引不会再变更的情况，我们就会做一次优化了。

        但，如果你的索引经常会改变，那么你就需要好好的考虑下面的因素的。

•        当越来越多的索引段被加进索引，查询的性能就会降低， lucene对索引段的数量有一个上限的限制，当超过这个限制的时候，索引段可以自动合并成为一个。
• 在同样没有缓存的情况下，一个没有经过优化的索引的性能会比经过优化的索引的性能少10%……
• 自动加热的时间将会变长，因为它依赖于搜索。
•  优化将会对索引的分发产生影响。
•  在优化期间，文件的大小将会是索引的两倍，不过最终将会回到它原来的大小，或者会更小一点。

      优化，会将所有的索引段合并成为一个索引段，所以，优化这个操作其实可以帮助避免“too many files”这个问题，这个错误是由文件系统抛出的。

Updates and Commit Frequency Tradeoffs

         如果从机太经常从主机更新的话，从机的性能是会受到影响的。为了避免，由于这个问题而引起的性能下降，我们还必须了解从机是怎样执行更新的，这样我们才能更准确去调节一些相关的参数（commit的频率，spappullers,autowarming/autocount）,这样，从机的更新才不会太频繁。

1.      执行commit操作会让solr新生成一个snapshot。如果将postCommit参数设成true的话，optimization也会执行snapShot.
2.      slave上的Snappuller程序一般是在crontab上面执行的，它会去master询问，有没有新版的snapshot。一旦发现新的版本，slave就会把它下载下来，然后snapinstall.
3.      每次当一个新的searcher被open的时候，会有一个缓存预热的过程，预热之后，新的索引才会交付使用。

      这里讨论三个有关的参数：

•      number/frequency of snapshots   ----snapshot的频率。
•      snappullers 是   在crontab中的，它当然可以每秒一次、每天一次、或者其他的时间间隔一次运行。它运行的时候，只会下载slave上没有的，并且最新的版本。
•      Cache autowarming 可以在solrconfig.xml文件中配置。

           如果，你想要的效果是频繁的更新slave上的索引，以便这样看起来比较像“实时索引”。那么，你就需要让snapshot尽可能频繁的运行，然后也让 snappuller频繁的运行。这样，我们或许可以每5分钟更新一次，并且还能取得不错的性能，当然啦，cach的命中率是很重要的，恩，缓存的加热时间也将会影响到更新的频繁度。

       cache对性能是很重要的。一方面，新的缓存必须拥有足够的缓存量，这样接下来的的查询才能够从缓存中受益。另一方面，缓存的预热将可能占用很长一段时间，尤其是，它其实是只使用一个线程，和一个cpu在工作。snapinstaller太频繁的话，solr slave将会处于一个不太理想的状态，可能它还在预热一个新的缓存，然而一个更新的searcher被opern了。

         怎么解决这样的一个问题呢，我们可能会取消第一个seacher，然后去处理一个更新seacher，也即是第二个。然而有可能第二个seacher 还没有被使用上的时候，第三个又过来了。看吧，一个恶性的循环，不是。当然也有可能，我们刚刚预热好的时候就开始新一轮的缓存预热，其实，这样缓存的作用压根就没有能体现出来。出现这种情况的时候，降低snapshot的频率才是硬道理。

    Query Response Compression

        在有些情况下，我们可以考虑将solr xml response 压缩后才输出。如果response非常大，就会触及NIc i/o限制。

        当然压缩这个操作将会增加cpu的负担，其实，solr一个典型的依赖于cpu处理速度的服务，增加这个压缩的操作，将无疑会降低查询性能。但是，压缩后的数据将会是压缩前的数据的6分之一的大小。然而solr的查询性能也会有15%左右的消耗。

       至于怎样配置这个功能，要看你使用的什么服务器而定，可以查阅相关的文档。

     Embedded vs HTTP Post

         使用embeded 来建立索引，将会比使用xml格式来建立索引快50%。

     RAM Usage Considerations（内存方面的考虑）

        OutOfMemoryErrors

           如果你的solr实例没有被指定足够多的内存的话，java virtual machine也许会抛outof memoryError，这个并不对索引数据产生影响。但是这个时候，任何的 adds/deletes/commits操作都是不能够成功的。

         Memory allocated to the Java VM

            最简单的解决这个方法就是，当然前提是java virtual machine 还没有使用掉你全部的内存，增加运行solr的java虚拟机的内存。

           Factors affecting memory usage（影响内存使用量的因素）

             我想，你或许也会考虑怎样去减少solr的内存使用量。

              其中的一个因素就是input document的大小。

              当我们使用xml执行add操作的时候，就会有两个限制。

•      document中的field都是会被存进内存的，field有个属性叫maxFieldLength，它或许能帮上忙。
•      每增加一个域，也是会增加内存的使用的。

（当切换SolrIndexSearcher时可能会有两个同时提供服务），而Solr的各种Cache是依附于SolrIndexSearcher的，SolrIndexSearcher在则Cache 生，SolrIndexSearcher亡则Cache被清空close掉。

Solr中的应用Cache有filterCache、 queryResultCache、documentCache等，这些Cache都是SolrCache的实现类，

并且是 SolrIndexSearcher的成员变量，各自有着不同的逻辑和使命，下面分别予以介绍和分析。

1、SolrCache接口实现类

Solr提供了两种SolrCache接口实现类：solr.search.LRUCache和solr.search.FastLRUCache。

FastLRUCache是1.4版本中引入的，其速度在普遍意义上要比LRUCache更fast些。
下面是对SolrCache接口主要方法的注释：

that match a query.When a new searcher is opened, its caches may be prepopulatedor "autowarmed"

 using data from caches in the old searcher.autowarmCount is the number of items to prepopulate. 

 For LRUCache,the prepopulated items will be the most recently accessed items.-->

<filterCacheclass="solr.LRUCache"size="16384"initialSize="4096"/>

<queryResultCacheclass="solr.LRUCache"size="16384"initialSize="4096"/>

publicQueryResultKey(Query query, List<Query>filters, Sort sort,intnc_flags)

 {

     this.query=query;

     this.sort=sort;

     this.filters=filters;

     this.nc_flags=nc_flags;

     inth=query.hashCode();

     if(filters!=null)h^=filters.hashCode();

     sfields=(this.sort!=null)?this.sort.getSort():defaultSort;

    for(SortField sf:sfields)

    { // mix the bits so that sortFields are position dependent

 // so that a,b won't hash to the same value as b,ah^=(h<<8)|(h>>>25);

 // reversible hashif(sf.getField()!=null)h+=sf.getField().hashCode();h+=sf.getType();

 if(sf.getReverse())h=~h;if(sf.getLocale()!=null)h+=sf.getLocale().hashCode();

 if(sf.getFactory()!=null)h+=sf.getFactory().hashCode();}hc=h;

 }

of document idsare collected.  For example, of a search for a particular queryrequests matching documents 10 

through 19, and queryWindowSize is 50,then documents 0 through 50 will be collected and cached.  

Any furtherrequests in that range can be satisfied via the cache.-->

<queryResultWindowSize>50</queryResultWindowSize>

相比filterCache来说，queryResultCache内存使用上要更少一些，但它的效果如何就很难说。

就索引数据来说，通常我们只是在索引上存储应用主键id，再从数据库等数据源获取其他需要的字段。

这使得查询过程变成，首先通过solr得到document id set，再由Solr得到应用id集合，

最后从外部数据源得到完成的查询结果。如果对查询结果正确性没有苛刻的要求，可以在Solr之外独立的缓存完整的



查询结果（定时作废），这时queryResultCache就不是很有必要，否则可以考虑使用queryResultCache。当然，如果发现在

queryResultCache生命周期内，query重合度很低，也不是很有必要开着它。 

又顾名思义，documentCache用来保存<doc_id,document>对的。如果使用documentCache，就尽可能开大



些，至少要大过<max_results> *<max_concurrent_queries>，否则因为cache的淘汰，

一次请求期间还需要重新获取document一次。也要注意document中存储的字段的多少，避免大量的内存消耗。

下面是documentCache的配置示例：<!-- documentCache caches Lucene Document objects (the stored fields for each document).-->

<documentCacheclass="solr.LRUCache"size="16384"initialSize="16384"/>

5、User/Generic Caches 

Solr支持自定义Cache，只需要实现自定义的regenerator即可，下面是配置示例：<!-- Example of a generic cache.  These caches may be accessed by namethrough SolrIndexSearcher.getCache(),

cacheLookup(), and cacheInsert().The purpose is to enable easy caching of user/application level data.

The regenerator argument should be specified as an implementationof solr.search.CacheRegenerator if

 autowarming is desired.--><!--<cache name="yourCacheNameHere"class="solr.LRUCache"size="4096"

initialSize="2048"regenerator="org.foo.bar.YourRegenerator"/>-->

6、The Lucene FieldCache 

lucene中有相对低级别的FieldCache，Solr并不对它做管理，所以，lucene的FieldCache还是由lucene的IndexSearcher来搞。 

上面有提到autowarm，autowarm触发的时机有两个，一个是创建第一个Searcher时（firstSearcher），一个是创建个新



Searcher（newSearcher）来代替当前的Searcher。在Searcher提供请求服务前，Searcher中的各个Cache可以

做warm处理，处理的地方通常是SolrCache的init方法，而不同cache的warm策略也不一样。

1）filterCache：filterCache注册了下面的CacheRegenerator，就是由旧的key查询索引得到新值put到新cache中。solrConfig.filterCacheConfig.setRegenerator(newCacheRegenerator(){publicbooleanregenerateItem

(SolrIndexSearcher newSearcher, SolrCache newCache, SolrCache oldCache,ObjectoldKey,ObjectoldVal)

throwsIOException{newSearcher.cacheDocSet((Query)oldKey,null,false);returntrue;}});

 2）queryResultCache：queryResultCache的autowarm不在SolrCache的init（也就是说，不是去遍历已

 有的queryResultCache中的query key执行查询），而是通过SolrEventListener接口的void

newSearcher(SolrIndexSearcher newSearcher, SolrIndexSearcher

currentSearcher)方法，来执行配置中特定的query查询，达到显示的预热lucene FieldCache的效果。

queryResultCache的配置示例如下：

<listenerevent="newSearcher"class="solr.QuerySenderListener"><arrname="queries"><!-- seed common sort fields --><lst>

<strname="q">anything</str><strname="sort">name desc price desc populartiy desc</str></lst></arr>

</listener><listenerevent="firstSearcher"class="solr.QuerySenderListener"><arrname="queries">

<!-- seed common sort fields --><lst><strname="q">anything</str><strname="sort">

name desc, price desc, populartiy desc</str></lst><!-- seed common facets and filter queries -->

<lst><strname="q">anything</str><strname="facet.field">category</str>

<strname="fq">inStock:true</str><strname="fq">price:[0 TO 100]</str></lst></arr></listener>

3）documentCache：因为新索引的document id和索引文档的对应关系发生变化，所以documentCache没有warm的过程，

落得白茫茫一片真干净。尽管autowarm很好，也要注意autowarm带来的开销，这需要在实际中检验其warm的开销，

也要注意Searcher的切换频率，避免因为warm和切换影响Searcher提供正常的查询服务。



8、参考文章 

http://wiki.apache.org/solr/SolrCaching

• 中心化集群配置
• 自动容灾
• 近实时搜索
• 领导选举
• 索引持久化

http://zhoujianghai.iteye.com/blog/1540176

首先介绍一下solr：

Apache Solr (读音: SOLer) 是一个开源、高性能、采用Java开发、基于Lucene的全文搜索服务器，文档通过Http利用XML加到一个搜索集合中，查询该集合也是通过 http收到一个XML/JSON响应来实现。Solr 中存储的资源是以 Document 为对象进行存储的。每个文档由一系列的 Field 构成，每个 Field 表示资源的一个属性。Solr 中的每个 Document 需要有能唯一标识其自身的属性，默认情况下这个属性的名字是 id，在 Schema 配置文件（schema.xml）中使用：<uniqueKey>id</uniqueKey>进行描述。solr有两个核心文件，solrconfig.xml和schema.xml。solrconfig.xml是solr的基础文件，里面配置了各种web请求处理器、请求响应处理器、日志、缓存等;schema.xml配置映射了各种数据类型的索引方案，分词器的配置、索引文档中包含的字段也在此配置。

工作中主要用来分词和搜索，简单的工作原理是：利用分词器对数据源进行分词处理，然后根据分词结果建立索引库;查询的时候，利用分词器对查询语句进行分词，根据查询语句分词的结果在索引库中进行匹配，最后返回结果。

废话少说，下面开始solr之旅吧：

一.安装JDK和Tomcat

（2）：安装tomcat，下载tomcat安装包，解压到apache-tomcat目录下

修改tomcat安装目录下的conf目录的server.xml

找到<Connector port="8080" .../>，加入URIEncoding="UTF-8"，为了支持中文。

设置Java和tomcat环境变量

上面两步比较简单，这里就只简单描述一下，不明白的可以网上查资料。

二. 安装solr

下载solr包，http://labs.renren.com/apache-mirror/lucene/solr/3.5.0/apache-solr-3.5.0.zip

解压缩到apache-solr目录，把apache-solr/dist目录下的apache-solr-3.5.0.war 复制到$TOMCAT_HOME/webapps目录下，重命名为solr.war

复制apache-solr/example/solr到tomcat根目录下（如果你想配置多core（实例），就复制apache-solr /example/multicore到tomcat根目录下，不用复制solr了），作为solr/home，以后也可以往该目录添加 core，每个core下面都可以有自己的配置文件。

在apache-tomcat/conf/Catalina/localhost/下创建solr.xml（跟webapps下的solr项目同名），指定solr.war和solr/home的位置，让tomcat启动时就自动加载该应用。

solr.xml内容如下：

<?xml version="1.0" encoding="UTF-8"?>

<Context docBase="/home/zhoujh/java/apache-tomcat7/webapps/solr.war" debug="0" crossContext="true" >

   <Environment name="solr/home" type="java.lang.String" value="/home/zhoujh/java/apache-tomcat7/solr" override="true" />

</Context>

然后在tomcat的bin目录下执行./startup.sh，启动tomcat

在地址栏访问http://localhost:8080/solr/

将会出现solr欢迎界面和admin入口

注：如果出现org.apache.solr.common.SolrException: Error loading class 'solr.VelocityResponseWriter' 异常，最简单的解决方法：找到$TOMCAT_HOME/solr/conf/solrconfig.xml，把<queryResponseWriter name="velocity" class="solr.VelocityResponseWriter" enable="${solr.velocity.enabled:true}"/>注释掉或者enable:false即可。如果一切顺利的话，现在可以看到solr的web管理界面了。不过要想实现分词的功能，得安装一个中文分词器，这里推荐IKAnalyzer或mmseg4j。

IKAnalyzer是一个开源的，基于java语言开发的轻量级的中文分词工具包，采用了特有的“正向迭代最细粒度切分算法“，具有60万字/秒的高速处理能力，采用了多子处理器分析模式，支持：英文字母（IP地址、Email、URL）、数字（日期，常用中文数量词，罗马数字，科学计数法），中文词汇（姓名、地名处理）等分词处理。优化的词典存储，更小的内存占用。支持用户词典扩展定。

mmseg4j 用 Chih-Hao Tsai 的 MMSeg 算法(http://technology.chtsai.org/mmseg/ )实现的中文分词器，并实现 lucene 的 analyzer 和 solr 的TokenizerFactory 以方便在Lucene和Solr中使用。MMSeg 算法有两种分词方法：Simple和Complex，都是基于正向最大匹配。Complex 加了四个规则过虑。官方说：词语的正确识别率达到了 98.41%。mmseg4j 已经实现了这两种分词算法。

三. 配置中文分词器

下面分别安装这两个中文分词器，当然选择安装其中一个也是可以的。

（1）安装IKAnalyzer

下载地址： http://code.google.com/p/ik-analyzer/downloads/list

在当前目录下新建IKAnalyzer目录，解压到该目录下：unzip IKAnalyzer2012_u5.zip -d ./IKAnalyzer

把IKAnalyzer目录下的IKAnalyzer2012.jar文件拷贝到 $TOMCAT_HOME/webapps/solr/WEB-INF/lib/下

配置schema.xml，编辑$TOMCAT_HOME/solr/conf/schema.xml，在文件中添加下面这个fieldtype

注：下面的代码中多了很多“<span style="font-size: x-small;">”标签，这个是设置字体时iteye编辑器自己生成的。

<span style="font-size: x-small;"><span style="font-size: x-small;"><span style="font-size: small;"><fieldType name="text" class="solr.TextField" positionIncrementGap="100">
        <analyzer type="index">
            <tokenizer class = "org.wltea.analyzer.solr.IKTokenizerFactory" isMaxWordLength="false" /> 
            <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" />  
            <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="1" />                
            <filter class="solr.LowerCaseFilterFactory" />  
            <filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt" />      
            <filter class="solr.RemoveDuplicatesTokenFilterFactory" />  
        </analyzer>
        <analyzer type="query">
            <tokenizer class = "org.wltea.analyzer.solr.IKTokenizerFactory" isMaxWordLength="true" />  
            <filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true" />  
            <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" />  
            <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="0" catenateNumbers="0" catenateAll="0" splitOnCaseChange="1" />  
            <filter class="solr.LowerCaseFilterFactory" />  
            <filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt" />  
            <filter class="solr.RemoveDuplicatesTokenFilterFactory" />  
        </analyzer>
    </fieldType></span></span></span>

<field name="game_name" type="text" indexed="true" stored="true" required="true" />

然后找到这一句：<defaultSearchField>text</defaultSearchField>把它改成<defaultSearchField>game_name</defaultSearchField>

在浏览器打开http://localhost:8080/solr/admin/analysis.jsp，就可以进行分词处理了。

IKAnalyzer添加自定义分词词典：词典文件格式为无BOM的UTF-8编码的文本文件,文件扩展名不限，一次可以添加多个词库，每个词库以";"分开。把IKAnalyzer 目录下的IKAnalyzer.cfg.xml和stopword.dic拷贝到$TOMCAT_HOME/webapps/solr/WEB_INF /classes目录下，可以自己新建一个mydic.dic文件，然后在IKAnalyzer.cfg.xml里进行配置。

（2）安装mmseg4j

 下载地址：http://code.google.com/p/mmseg4j/downloads/list

在当前目录下新建mmseg4j目录，解压到该目录下：unzip mmseg4j-1.8.5.zip -d ./mmseg4j

把mmseg4j目录下的mmseg4j-all-1.8.5.jar文件拷贝到 $TOMCAT_HOME/webapps/solr/WEB-INF/lib/下

配置schema.xml，编辑$TOMCAT_HOME/solr/conf/schema.xml，在文件中添加下面这个fieldtype

<fieldtype name="textComplex" class="solr.TextField" positionIncrementGap="100">
        <analyzer>
            <tokenizer class="com.chenlb.mmseg4j.solr.MMSegTokenizerFactory" mode="complex" dicPath="/home/zhoujh/java/apache-tomcat7/solr/dict">
            </tokenizer>
        </analyzer>
    </fieldtype>
    <fieldtype name="textMaxWord" class="solr.TextField" positionIncrementGap="100">
        <analyzer>
            <tokenizer class="com.chenlb.mmseg4j.solr.MMSegTokenizerFactory" mode="max-word" dicPath="/home/zhoujh/java/apache-tomcat7/solr/dict">
            </tokenizer>
        </analyzer>
    </fieldtype>
    <fieldtype name="textSimple" class="solr.TextField" positionIncrementGap="100">
        <analyzer>
            <tokenizer class="com.chenlb.mmseg4j.solr.MMSegTokenizerFactory" mode="simple" dicPath="/home/zhoujh/java/apache-tomcat7/solr/dict">
            </tokenizer>
        </analyzer>
    </fieldtype>

注意：dicPath的值改成你自己机器上相应的目录。

然后修改之前添加的filed，让其使用mmseg4j分词器

<field name="game_name" type="textComplex" indexed="true" stored="true" required="true" />

配置mmseg4j分词词典：MMSEG4J的词库是可以动态加载的，词库的编码必须是UTF-8，mmseg4j 默认从当前目录下的 data 目录读取上面的文件，当然也可以指定别的目录，比如我就放在自定义的dict目录下。自定义词库文件名必需是 "words" 为前缀和 ".dic" 为后缀。如：/data/words-my.dic。

这里直接把mmseg4j/data目录下的所有.dic文件拷贝到$TOMCAT_HOME/solr/dict目录下。共有：4个dic文件，chars.dic、units.dic、 words.dic、 words-my.dic。下面简单解释一下这几个文件的作用。

1、chars.dic，是单个字，和对应的频率，一行一对，字在全面，频率在后面，中间用空格分开。这个文件的信息是 complex 模式要用到的。在最后一条过虑规则中使用了频率信息。

2、units.dic，是单位的字，如：分、秒、年。

3、words.dic，是核心的词库文件，一行一条，不需要其它任何数据（如词长）。

4、words-my.dic，是自定义词库文件

在浏览器打开http://localhost:8080/solr/admin/analysis.jsp，就可以看到分词效果了。

现在，这两种分词方法都已配置好了，想用哪种就把查询的filed的type设置成哪种。

一、字段配置（schema）

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

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

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

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

必要的时候fieldType还需要自己定义这个类型的数据在建立索引和进行查询的时候要使用的分析器analyzer，包括分词和过滤，如下：

2、再来看下fields节点内定义具体的字段（类似数据库的字段），含有以下属性：

• name：字段名
• type：之前定义过的各种FieldType
• indexed：是否被索引
• stored：是否被存储（如果不需要存储相应字段值，尽量设为false）
• multiValued：是否有多个值（对可能存在多值的字段尽量设置为true，避免建索引时抛出错误）

3、建议建立一个拷贝字段，将所有的 全文本 字段复制到一个字段中，以便进行统一的检索：

     以下是拷贝设置：

4、动态字段，没有具体名称的字段，用dynamicField字段

如：name为*_i，定义它的type为int，那么在使用这个字段的时候，任务以_i结果的字段都被认为符合这个定义。如name_i, school_i

schema.xml文档注释中的信息：

1、为了改进性能，可以采取以下几种措施：

• 将所有只用于搜索的，而不需要作为结果的field（特别是一些比较大的field）的stored设置为false
• 将不需要被用于搜索的，而只是作为结果返回的field的indexed设置为false
• 删除所有不必要的copyField声明
• 为了索引字段的最小化和搜索的效率，将所有的 text fields的index都设置成field，然后使用copyField将他们都复制到一个总的 text field上，然后对他进行搜索。
• 为了最大化搜索效率，使用java编写的客户端与solr交互（使用流通信）
• 在服务器端运行JVM（省去网络通信），使用尽可能高的Log输出等级，减少日志量。

2、< schema name =" example " version =" 1.2 " >

• name：标识这个schema的名字
• version：现在版本是1.2

3、filedType

< fieldType name =" string " class =" solr.StrField " sortMissingLast =" true " omitNorms =" true " />

• name：标识而已。
• class和其他属性决定了这个fieldType的实际行为。（class以solr开始的，都是在org.appache.solr.analysis包下）

可选的属性：

• sortMissingLast和sortMissingFirst两个属性是用在可以内在使用String排序的类型上（包括：string,boolean,sint,slong,sfloat,sdouble,pdate）。
• sortMissingLast="true"，没有该field的数据排在有该field的数据之后，而不管请求时的排序规则。
• sortMissingFirst="true"，跟上面倒过来呗。
• 2个值默认是设置成false

StrField类型不被分析，而是被逐字地索引/存储。

StrField和TextField都有一个可选的属性“compressThreshold”，保证压缩到不小于一个大小（单位：char）

< fieldType name =" text " class =" solr.TextField " positionIncrementGap =" 100 " >

solr.TextField 允许用户通过分析器来定制索引和查询，分析器包括一个分词器（tokenizer）和多个过滤器（filter）

• positionIncrementGap：可选属性，定义在同一个文档中此类型数据的空白间隔，避免短语匹配错误。

name:    字段类型名 
class:    java类名 
indexed:    缺省true。 说明这个数据应被搜索和排序，如果数据没有indexed，则stored应是true。 
stored:    缺省true。说明这个字段被包含在搜索结果中是合适的。如果数据没有stored,则indexed应是true。 
sortMissingLast:    指没有该指定字段数据的document排在有该指定字段数据的document的后面 
sortMissingFirst:    指没有该指定字段数据的document排在有该指定字段数据的document的前面 
omitNorms:    字段的长度不影响得分和在索引时不做boost时，设置它为true。一般文本字段不设置为true。 
termVectors:    如果字段被用来做more like this 和highlight的特性时应设置为true。 
compressed:    字段是压缩的。这可能导致索引和搜索变慢，但会减少存储空间，只有StrField和TextField是可以压缩，这通常适合字段的长度超过200个字符。 
multiValued:    字段多于一个值的时候，可设置为true。 
positionIncrementGap:    和multiValued
一起使用，设置多个值之间的虚拟空白的数量

< tokenizer class =" solr.WhitespaceTokenizerFactory " />

空格分词，精确匹配。

< filter class =" solr.WordDelimiterFilterFactory " generateWordParts =" 1 " generateNumberParts =" 1 " catenateWords =" 1 " catenateNumbers =" 1 " catenateAll =" 0 " splitOnCaseChange =" 1 " />

在分词和匹配时，考虑 "-"连字符，字母数字的界限，非字母数字字符，这样 "wifi"或"wi fi"都能匹配"Wi-Fi"。

< filter class =" solr.SynonymFilterFactory " synonyms =" synonyms.txt " ignoreCase =" true " expand =" true " />

同义词 

< filter class =" solr.StopFilterFactory " ignoreCase =" true " words =" stopwords.txt " enablePositionIncrements =" true " />

在禁用字（stopword）删除后，在短语间增加间隔

stopword：即在建立索引过程中（建立索引和搜索）被忽略的词，比如is this等常用词。在conf/stopwords.txt维护。

4、fields

< field name =" id " type =" string " indexed =" true " stored =" true " required =" true " />

• name：标识而已。
• type：先前定义的类型。
• indexed：是否被用来建立索引（关系到搜索和排序）
• stored：是否储存
• compressed：[false]，是否使用gzip压缩（只有TextField和StrField可以压缩）
• mutiValued：是否包含多个值
• omitNorms：是否忽略掉Norm，可以节省内存空间，只有全文本field和need an index-time boost的field需要norm。（具体没看懂，注释里有矛盾）
• termVectors：[false]，当设置true，会存储 term vector。当使用MoreLikeThis，用来作为相似词的field应该存储起来。
• termPositions：存储 term vector中的地址信息，会消耗存储开销。
• termOffsets：存储 term vector 的偏移量，会消耗存储开销。
• default：如果没有属性需要修改，就可以用这个标识下。

< field name =" text " type =" text " indexed =" true " stored =" false " multiValued =" true " />

包罗万象（有点夸张）的field，包含所有可搜索的text fields，通过copyField实现。

< copyField source =" cat " 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 比例以及微调缓存大小的统计数据都非常有用。而且，并非所有应用程序都会从缓存受益。实际上，一些应用程序反而会由于需要将某个永远也用不到的条目存储在缓存中这一额外步骤而受到影响。

Having at hand a sample data of the albums and performers, I decided to show my way of dealing with such cases. For simplicity and clarity, I assume that after the first import, the data can only decrease.

Test data

My test data are located in the PostgreSQL database table defined as follows:

Table "public.albums"
Column |  Type   |                      Modifiers
--------+---------+-----------------------------------------------------
id     | integer | not null default nextval('albums_id_seq'::regclass)
name   | text    | not null
author | text    | not null
Indexes:
"albums_pk" PRIMARY KEY, btree (id)

The table has 825,661 records.

Test installation

For testing purposes I used the Solr instance having the following characteristics:

Definition at schema.xml:

Deleting Data

Looking at the table shows that when we remove the record, he is deleted without leaving a trace, and the only way to update our index would be to compare the documents identifiers in the index to the identifiers in the database and deleting those that no longer exist in the database. Slow and cumbersome. Another way is adding a column deleted_at: instead of physically deleting the record, only add information to this column. DIH can then retrieve all records from the set date later than the last crawl. The disadvantage of this solution may be necessary to modify the application to take such information into consideration.

I apply a different solution, transparent to applications. Let’s create a new table:

This table will automagically add an identifier of those items that were removed from the table albums and information when they were removed.

Now we add the function:

and a trigger:

How it works

Each entry deleted from the albums table should result in addition to the table deletes. Let’s check it out. Remove a few records:

So the database part works.

We fill up the DIH configuration file so that the entity has been defined as follows:

This allows the import DIH incremental import to use the deletedPkQuery attribute to get the identifiers of the documents which should be removed.

A clever reader will probably begin to wonder, are you sure we need the column with the date of deletion. We could delete all records that are found in the table deletes and then delete the contents of this table. Theoretically this is true, but in the event of a problem with the Solr indexing server we can easily replace it with another – the degree of synchronization with the database is not very important – just the next incremental imports will sync with the database. If we would delete the contents of the deletes table such possibility does not exist.

We can now do the incremental import by calling the following address:  /solr/dataimport?command=delta-import
In the logs you should see a line similar to this:
INFO: {delete=[35, 36],optimize=} 0 2
Which means that DIH properly removed from the index the documents, which were previously removed from the database.

大家知道在解压开solr的web程序（apache-solr-3.2.0.war）时，在其WEB-INF/lib目录下有slf4j- api-1.5.5.jar，slf4j-jdk14-1.5.5.jar这两个jar包，故可知其默认使用的是jdk的日志数据，其日志都是输入到 tomcat的logs中；再看其是结合slf4j进行jdk的日志数据；slf4j并不是一种具体的日志系统，而是一个用户日志系统的facade，允许在部署最终应用时方便的变更其日志系统。故solr使用log4j也是ok的，即采用log4j替换jdk的日志输入；做法如下：
1.  将solr/WINF-WEB/lib中的slf4j-api-1.5.5.jar，slf4j-jdk14-1.5.5.jar删除，新加入 log4j-1.2.15.jar  slf4j-api-1.5.0.jar  slf4j-log4j12-1.5.0.jar或是其对应的jar包；
2.在solr/WEB-INF/下创建classes目录，因为默认的包中没有该目录，其都是使用jsp操作；
3. 将写好的log4j.properties放到solr/WEB-INF/classes中, 其内容如下，

log4j.rootLogger=INFO
log4j.logger.org.apache.solr=INFO,ROLLING_FILE

log4j.appender.ROLLING_FILE=org.apache.log4j.RollingFileAppender
log4j.appender.ROLLING_FILE.Append=false
log4j.appender.ROLLING_FILE.File=/var/log/solr.log
log4j.appender.ROLLING_FILE.MaxBackupIndex=50
log4j.appender.ROLLING_FILE.MaxFileSize=200MB
log4j.appender.LOGFILE.Threshold=INFO
log4j.appender.ROLLING_FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.ROLLING_FILE.layout.ConversionPattern=%d{yyyy-MM-dd HH\:mm\:ss} %p [%c]\:%L Line – %m%n

4.重启tomcat即可
PS：如果是采用JNDI部署，最好将以上的重新打包war，在替换旧的