全文检索引擎 Solr 部署与基本原理

lbdbzj110

全文检索引擎 Solr 部署与基本原理

• 
  搜索引擎Solr环境搭建实例
  

• 
  关于 solr ， schema.xml 的配置说明
  

• 
  全文检索引擎Solr系列—–全文检索基本原理
  

一、搜索引擎Solr环境搭建实例
　　Solr服务器采用java5开发的，是基于Lucene全文搜索的。要想搭建Solr，首先进行java环境的配置，安装对应的jdk以及tomcat，在此就不多讲。
　　以下是在jdk1.7和tomcat1.7的环境下搭建最新版本的solr4.10.3。
　　具体步骤如下：
　　1.到官网http://lucene.apache.org/solr/mirrors-solr-latest-redir.html下载.
　　2.建目录/webapps/mysolr/solr
　　3.解压压缩包solr-4.10.3，找到example下的webapps中的solr.war包，并将其解压。
　　4.将解压完的war包（solr文件夹）拷贝到第2步建的目录：/webapps/mysolr下
　　5.拷贝两个地方的jar包到/webapps/mysolr/solr/WEB-INF/lib下
　　（1）example下lib包的所有jar包
　　（2）example下lib包下的ext包中的所有jar包
　　6.拷贝example/resource下的log4j.properties文件到/webapps/mysolr/solr/classpath 下
　　7.solrhome的配置：
　　先创建一个solrhome目录：/webapps/mysolr/solrhome，然后将example/solr下的所有文件拷贝到/webapps/mysolr/solrhome下
　　然后修改配置文件/webapps/mysolr/solr/WEB-INF/web.xml，将solr/home的注解放开并配置如下：
　　

<env-entry>　　<env-entry-name>solr/home</env-entry-name>
　　<env-entry-value>/webapps/mysolr/solrhome</env-entry-value>
　　<env-entry-type>java.lang.String</env-entry-type>
　　
</env-entry>
　　

　　8.把/webapps/mysolr/solr部署到tomcat下，并启动tomcat。
　　以上就完成了solr环境的基本搭建，访问http://loclhost:8080/solr  可看到如下界面：

　　Solr3.6.1 在Tomcat6下的环境搭建 http://www.cnblogs.com/chinway/p/6187260.html
　　基于Tomcat的Solr3.5集群部署 http://www.cnblogs.com/chinway/p/6187271.html
　　在Linux上使用Nginx为Solr集群做负载均衡 http://www.cnblogs.com/chinway/p/6187292.html
　　Linux下安装使用Solr http://www.cnblogs.com/chinway/p/6187322.html
　　Solr实现Low Level查询解析（QParser） http://www.cnblogs.com/chinway/p/6187332.html
　　Solr 4.0 部署实例教程 http://www.cnblogs.com/chinway/p/6187382.html

二、 关于 solr ， schema.xml 的配置说明
　　schema.xml位于solr/conf/目录下，类似于数据表配置文件，
　　定义了加入索引的数据的数据类型，主要包括type、fields和其他的一些缺省设置。
　　1、先来看下type节点，这里面定义FieldType子节点，包括name,class,positionIncrementGap等一些参数。

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

　　

< schema name = "example" version = "1.2" >　　
< types >

　　
< fieldType name = "string">
　　
< fieldType name = "boolean">
　　
< fieldtype name = "binary">
　　
< fieldType name = "int">　　
positionIncrementGap = "0" />

　　
< fieldType name = "float">　　
positionIncrementGap = "0" />

　　
< fieldType name = "long">　　
positionIncrementGap = "0" />
　　
< fieldType name = "double">　　
positionIncrementGap = "0" />
　　
...
　　
</ types >
　　
...
　　
</ schema >
　　

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

< fieldType name = "text_ws">
< analyzer >

　　
< tokenizer>　　
</ analyzer >
　　
</ fieldType >

　　
< fieldType name = "text">　　
< analyzer type = "index" >
　　
<!--这个分词包是空格分词，在向索引库添加text类型的索引时，Solr会首先用空格进行分词
　　
然后把分词结果依次使用指定的过滤器进行过滤，最后剩下的结果，才会加入到索引库中以备查询。
　　
注意:Solr的analysis包并没有带支持中文的包，需要自己添加中文分词器，google下。
　　
-->

　　
< tokenizer>　　
<!-- in this example, we will only use synonyms at query time

　　
< filter>　　
ignoreCase = "true" expand = "false" />
　　
-->
　　
<!-- Case insensitive stop word removal.
　　
add enablePositionIncrements = true in both the index and query
　　
analyzers to leave a 'gap' for more accurate phrase queries.
　　
-->

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

　　
< filter>　　
generateNumberParts = "1" catenateWords = "1" catenateNumbers = "1"
　　
catenateAll = "0" splitOnCaseChange = "1" />

　　
< filter>
　　
< filter>　　
protected = "protwords.txt" />
　　
</ analyzer >
　　
< analyzer type = "query" >

　　
< tokenizer>
　　
< filter>　　
expand = "true" />

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

　　
< filter>　　
generateNumberParts = "1" catenateWords = "0" catenateNumbers = "0"
　　
catenateAll = "0" splitOnCaseChange = "1" />
　　
< filter>　　
< filter>　　
protected = "protwords.txt" />
　　
</ analyzer >
　　
</ fieldType >
　　

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

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

　　

< fields >　　
< field name = "id" type = "integer" indexed = "true" stored = "true" required = "true" />
　　
< field name = "name" type = "text" indexed = "true" stored = "true" />
　　
< field name = "summary" type = "text" indexed = "true" stored = "true" />
　　
< field name = "author" type = "string" indexed = "true" stored = "true" />
　　
< field name = "date" type = "date" indexed = "false" stored = "true" />
　　
< field name = "content" type = "text" indexed = "true" stored = "false" />
　　
< field name = "keywords" type = "keyword_text" indexed = "true" stored = "false" multiValued = "true" />
　　
<!--拷贝字段-->
　　
< field name = "all" type = "text" indexed = "true" stored = "false" multiValued = "true" />
　　
</ fields >
　　

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

< copyField source = "name" dest = "all" />　　
< copyField source = "summary" dest = "all" />
　　

　　4、动态字段，没有具体名称的字段，用dynamicField字段
　　如：name为*_i，定义它的type为int，那么在使用这个字段的时候，任务以_i结果的字段都被认为符合这个定义。如name_i, school_i
　　

< dynamicField name = "*_i" type = "int" indexed = "true" stored = "true" />　　
< dynamicField name = "*_s" type = "string" indexed = "true" stored = "true" />
　　
< dynamicField name = "*_l" type = "long" indexed = "true" stored = "true" />
　　
< dynamicField name = "*_t" type = "text" indexed = "true" stored = "true" />
　　
< dynamicField name = "*_b" type = "boolean" indexed = "true" stored = "true" />
　　
< dynamicField name = "*_f" type = "float" indexed = "true" stored = "true" />
　　
< dynamicField name = "*_d" type = "double" indexed = "true" stored = "true" />
　　
< dynamicField name = "*_dt" type = "date" indexed = "true" stored = "true" />
　　

　　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 ">　　

• 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 ">　　

　　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>　　

　　空格分词，精确匹配。
　　

  < filter>　　

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

< filter>　　

　　同义词
　　

  < filter>　　

　　在禁用字（stopword）删除后，在短语间增加间隔
　　stopword：即在建立索引过程中（建立索引和搜索）被忽略的词，比如is this等常用词。在conf/stopwords.txt维护。
　　4、fields
　　

< field name =">　　

• 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 " />

< copyField source =" name " dest =" text " />
< copyField source =" manu " dest =" text " />
< copyField source =" features " dest =" text " />
< 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 >>　　

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

< defaultSearchField > text </ defaultSearchField >　　

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

< solrQueryParser defaultOperator =" OR " />　　

　　配置搜索参数短语间的逻辑，可以是"AND|OR"。
　　Solr3.6.1 在Tomcat6下的环境搭建 http://www.cnblogs.com/chinway/p/6187260.html
　　基于Tomcat的Solr3.5集群部署 http://www.cnblogs.com/chinway/p/6187271.html
　　在Linux上使用Nginx为Solr集群做负载均衡 http://www.cnblogs.com/chinway/p/6187292.html
　　Linux下安装使用Solr http://www.cnblogs.com/chinway/p/6187322.html
　　Solr实现Low Level查询解析（QParser） http://www.cnblogs.com/chinway/p/6187332.html
　　Solr 4.0 部署实例教程 http://www.cnblogs.com/chinway/p/6187382.html

三、全文检索引擎Solr系列—–全文检索基本原理
　　新华字典,我们都使用过，如叫你翻开第38页，找到“坑爹”所在的位置，此时你会怎么查呢？毫无疑问，你的眼睛会从38页的第一个字开始从头至尾地扫描，直到找到“坑爹”二字为止。这种搜索方法叫做顺序扫描法。对于少量的数据，使用顺序扫描是够用的。但是妈妈叫你查出坑爹的“坑”字在哪一页时，你要是从第一页的第一个字逐个的扫描下去，那你真的是被坑了。此时你就需要用到索引。索引记录了“坑”字在哪一页，你只需在索引中找到“坑”字，然后找到对应的页码，答案就出来了。因为在索引中查找“坑”字是非常快的，因为你知道它的偏旁，因此也就可迅速定位到这个字。
　　那么新华字典的目录（索引表）是怎么编写而成的呢？首先对于新华字典这本书来说，除去目录后，这本书就是一堆没有结构的数据集。但是聪明的人类善于思考总结，发现每个字都会对应到一个页码，比如“坑”字就在第38页，“爹”字在第90页。于是他们就从中提取这些信息，构造成一个有结构的数据。类似数据库中的表结构：
　　

word    page_no　　
---------------
　　
坑        38
　　
爹        90
　　
...       ...
　　

　　这样就形成了一个完整的目录（索引库），查找的时候就非常方便了。对于全文检索也是类似的原理，它可以归结为两个过程：1.索引创建（Indexing）2. 搜索索引（Search）。那么索引到底是如何创建的呢？索引里面存放的又是什么东西呢？搜索的的时候又是如何去查找索引的呢？带着这一系列问题继续往下看。
　　


索引
　　Solr/Lucene采用的是一种反向索引，所谓反向索引：就是从关键字到文档的映射过程，保存这种映射这种信息的索引称为反向索引

• 左边保存的是字符串序列
  
• 右边是字符串的文档（Document）编号链表，称为倒排表（Posting List）
  

　　字段串列表和文档编号链表两者构成了一个字典。现在想搜索”lucene”，那么索引直接告诉我们，包含有”lucene”的文档有：2，3，10，35，92，而无需在整个文档库中逐个查找。如果是想搜既包含”lucene”又包含”solr”的文档，那么与之对应的两个倒排表去交集即可获得：3、10、35、92。

索引创建
　　假设有如下两个原始文档：
　　
文档一：Students should be allowed to go out with their friends, but not allowed to drink beer.
　　
文档二：My friend Jerry went to school to see his students but found them drunk which is not allowed.
　　
创建过程大概分为如下步骤：
　　

　　一：把原始文档交给分词组件(Tokenizer)
　　
分词组件(Tokenizer)会做以下几件事情(这个过程称为：Tokenize)，处理得到的结果是词汇单元（Token）

• 将文档分成一个一个单独的单词
  
• 去除标点符号
  
• 去除停词(stop word)
  
  
  
  • 所谓停词(Stop
    word)就是一种语言中没有具体含义，因而大多数情况下不会作为搜索的关键词，这样一来创建索引时能减少索引的大小。英语中停词(Stop
    word)如：”the”、”a”、”this”，中文有：”的，得”等。不同语种的分词组件(Tokenizer)，都有自己的停词(stop
    word)集合。经过分词(Tokenizer)后得到的结果称为词汇单元(Token)。上例子中，便得到以下词汇单元(Token)：　　
    
    "Students"，"allowed"，"go"，"their"，"friends"，"allowed"，"drink"，"beer"，"My"，"friend"，"Jerry"，"went"，"school"，"see"，"his"，"students"，"found"，"them"，"drunk"，"allowed"　　
    
    
    
  
  

　　二：词汇单元(Token)传给语言处理组件(Linguistic Processor)
　　
语言处理组件(linguistic processor)主要是对得到的词元(Token)做一些语言相关的处理。对于英语，语言处理组件(Linguistic Processor)一般做以下几点：

• 变为小写(Lowercase)。
  
• 将单词缩减为词根形式，如”cars”到”car”等。这种操作称为：stemming。
  
• 将单词转变为词根形式，如”drove”到”drive”等。这种操作称为：lemmatization。
  

　　语言处理组件(linguistic processor)处理得到的结果称为词(Term)，例子中经过语言处理后得到的词(Term)如下：
　　

"student"，"allow"，"go"，"their"，"friend"，"allow"，"drink"，"beer"，"my"，"friend"，"jerry"，"go"，"school"，"see"，"his"，"student"，"find"，"them"，"drink"，"allow"。　　

　　经过语言处理后，搜索drive时drove也能被搜索出来。Stemming 和 lemmatization的异同：

• 相同之处：
  
  
  • Stemming和lemmatization都要使词汇成为词根形式。
    
  
  
• 两者的方式不同：
  
  
  • Stemming采用的是”缩减”的方式：”cars”到”car”，”driving”到”drive”。
    
  • Lemmatization采用的是”转变”的方式：”drove”到”drove”，”driving”到”drive”。
    
  
  
• 两者的算法不同：
  
  
  • Stemming主要是采取某种固定的算法来做这种缩减，如去除”s”，去除”ing”加”e”，将”ational”变为”ate”，将”tional”变为”tion”。
    
  • Lemmatization主要是采用事先约定的格式保存某种字典中。比如字典中有”driving”到”drive”，”drove”到”drive”，”am, is, are”到”be”的映射，做转变时，按照字典中约定的方式转换就可以了。
    
  • Stemming和lemmatization不是互斥关系，是有交集的，有的词利用这两种方式都能达到相同的转换。
    
  
  

　　三：得到的词(Term)传递给索引组件(Indexer)

• 利用得到的词(Term)创建一个字典　　
  
  Term    Document>
  student     1
  　　
  allow       1
  　　
  go          1
  　　
  their       1
  　　
  friend      1
  　　
  allow       1
  　　
  drink       1
  　　
  beer        1
  　　
  my          2
  　　
  friend      2
  　　
  jerry       2
  　　
  go          2
  　　
  school      2
  　　
  see         2
  　　
  his         2
  　　
  student     2
  　　
  find        2
  　　
  them        2
  　　
  drink       2
  　　
  allow       2
  　　
  
  
  
• 对字典按字母顺序排序：　　
  
  Term    Document>
  allow       1
  　　
  allow       1
  　　
  allow       2
  　　
  beer        1
  　　
  drink       1
  　　
  drink       2
  　　
  find        2
  　　
  friend      1
  　　
  friend      2
  　　
  go          1
  　　
  go          2
  　　
  his         2
  　　
  jerry       2
  　　
  my          2
  　　
  school      2
  　　
  see         2
  　　
  student     1
  　　
  student     2
  　　
  their       1
  　　
  them        2
  　　
  
  
  
• 合并相同的词(Term)成为文档倒排(Posting List)链表
  
  
  
  
• 
  
  
  
  • Document Frequency：文档频次，表示多少文档出现过此词(Term)
    
  • Frequency：词频，表示某个文档中该词(Term)出现过几次
    
  
  

　　对词(Term) “allow”来讲，总共有两篇文档包含此词(Term)，词（Term)后面的文档链表总共有两个，第一个表示包含”allow”的第一篇文档，即1号文档，此文档中，”allow”出现了2次，第二个表示包含”allow”的第二个文档，是2号文档，此文档中，”allow”出现了1次
　　至此索引创建完成，搜索”drive”时，”driving”，”drove”，”driven”也能够被搜到。因为在索引中，”driving”，”drove”，”driven”都会经过语言处理而变成”drive”，在搜索时，如果您输入”driving”，输入的查询语句同样经过分词组件和语言处理组件处理的步骤，变为查询”drive”，从而可以搜索到想要的文档。

搜索步骤
　　搜索”microsoft job”，用户的目的是希望在微软找一份工作，如果搜出来的结果是:”Microsoft does a good job at software industry…”，这就与用户的期望偏离太远了。如何进行合理有效的搜索，搜索出用户最想要得结果呢？搜索主要有如下步骤：
　　一：对查询内容进行词法分析、语法分析、语言处理

• 词法分析：区分查询内容中单词和关键字，比如：english and janpan，”and”就是关键字，”english”和”janpan”是普通单词。
  
• 根据查询语法的语法规则形成一棵树　　
  
  
  
• 语言处理，和创建索引时处理方式是一样的。比如：leaned–>lean，driven–>drive
  

　　二：搜索索引，得到符合语法树的文档集合
　　
三：根据查询语句与文档的相关性，对结果进行排序
　　我们把查询语句也看作是一个文档，对文档与文档之间的相关性（relevance）进行打分（scoring），分数高比较越相关，排名就越靠前。当然还可以人工影响打分，比如百度搜索，就不一定完全按照相关性来排名的。
　　如何评判文档之间的相关性？一个文档由多个（或者一个）词（Term）组成，比如：”solr”，“toturial”，不同的词可能重要性不一样，比如solr就比toturial重要，如果一个文档出现了10次toturial，但只出现了一次solr，而另一文档solr出现了4次，toturial出现一次，那么后者很有可能就是我们想要的搜的结果。这就引申出权重（Termweight）的概念。
　　权重表示该词在文档中的重要程度，越重要的词当然权重越高，因此在计算文档相关性时影响力就更大。通过词之间的权重得到文档相关性的过程叫做空间向量模型算法(Vector Space Model)
　　影响一个词在文档中的重要性主要有两个方面：

• Term Frequencey（tf），Term在此文档中出现的频率，ft越大表示越重要
  
• Document Frequency（df），表示有多少文档中出现过这个Trem，df越大表示越不重要　　
  物以希为贵，大家都有的东西，自然就不那么贵重了，只有你专有的东西表示这个东西很珍贵，权重的公式：
  　　
  
  

空间向量模型
　　文档中词的权重看作一个向量
　　

Document = {term1, term2, …… ,term N}　　
Document Vector = {weight1, weight2, …… ,weight N}
　　

　　把欲要查询的语句看作一个简单的文档，也用向量表示：
　　

Query = {term1, term 2, …… , term N}　　
Query Vector = {weight1, weight2, …… , weight N}
　　

　　把搜索出的文档向量及查询向量放入N维度的空间中，每个词表示一维：
　　

　　夹角越小，表示越相似，相关性越大
　　Solr3.6.1 在Tomcat6下的环境搭建 http://www.cnblogs.com/chinway/p/6187260.html
　　基于Tomcat的Solr3.5集群部署 http://www.cnblogs.com/chinway/p/6187271.html
　　在Linux上使用Nginx为Solr集群做负载均衡 http://www.cnblogs.com/chinway/p/6187292.html
　　Linux下安装使用Solr http://www.cnblogs.com/chinway/p/6187322.html
　　Solr实现Low Level查询解析（QParser） http://www.cnblogs.com/chinway/p/6187332.html
　　Solr 4.0 部署实例教程 http://www.cnblogs.com/chinway/p/6187382.html