1、 solr基础

因为 Solr 包装并扩展了 Lucene，所以它们使用很多相同的术语。更重要的是，Solr 创建的索引与 Lucene 搜索引擎库完全兼容。通过对 Solr 进行适当的配置，某些情况下可能需要进行编码，Solr 可以阅读和使用构建到其他 Lucene 应用程序中的索引。

在 Solr 和 Lucene 中，使用一个或多个 Document 来构建索引。Document 包括一个或多个 Field。Field 包括名称、内容以及告诉 Solr 如何处理内容的元数据。例如，Field 可以包含字符串、数字、布尔值或者日期，也可以包含你想添加的任何类型，只需用在solr的配置文件中进行相应的配置即可。Field 可以使用大量的选项来描述，这些选项告诉 Solr 在索引和搜索期间如何处理内容。现在，查看一下表 1 中列出的重要属性的子集：

2、 solr索引操作

在 Solr 中，通过向部署在 servlet 容器中的 Solr Web 应用程序发送 HTTP 请求来启动索引和搜索。Solr 接受请求，确定要使用的适当 SolrRequestHandler，然后处理请求。通过 HTTP 以同样的方式返回响应。默认配置返回 Solr 的标准 XML 响应。你也可以配置 Solr 的备用响应格式，如json、csv格式的文本。

索引就是接受输入元数据（数据格式在schema.xml中进行配置）并将它们传递给 Solr，从而在 HTTP Post XML 消息中进行索引的过程。你可以向 Solr 索引 servlet 传递四个不同的索引请求：

2.1. add/update

 允许您向 Solr 添加文档或更新文档。直到提交后才能搜索到这些添加和更新。

2.2. commit

告诉 Solr，应该使上次提交以来所做的所有更改都可以搜索到。

2.3. optimize

重构 Lucene 的文件以改进搜索性能。索引完成后执行一下优化通常比较好。如果更新比较频繁，则应该在使用率较低的时候安排优化。一个索引无需优化也可以正常地运行。优化是一个耗时较多的过程。

2.4. delete

可以通过 id 或查询来指定。按 id 删除将删除具有指定 id 的文档；按查询删除将删除查询返回的所有文档。

Lucene中操作索引也有这几个步骤，但是没有更新。Lucene更新是先删除，然后添加索引。因为更新索引在一定情况下，效率没有先删除后添加的效率好。

3、 搜索

添加文档后，就可以搜索这些文档了。Solr 接受 HTTP GET 和 HTTP POST 查询消息。收到的查询由相应的 SolrRequestHandler 进行处理。

solr查询参数描述：

4、 solr模式

上面有提到schema.xml这个配置，这个配置可以在你下载solr包的安装解压目录的apache-solr-3.4.0\example\solr\conf中找到，它就是solr模式关联的文件。打开这个配置文件，你会发现有详细的注释。

模式组织主要分为三个重要配置

4.1. types 部分

是一些常见的可重用定义，定义了 Solr（和 Lucene）如何处理 Field。也就是添加到索引中的xml文件属性中的类型，如int、text、date等

4.2. fileds

是你添加到索引文件中出现的属性名称，而声明类型就需要用到上面的types

4.3. 其他配置

uniqueKey 唯一键，这里配置的是上面出现的fileds，一般是id、url等不重复的。在更新、删除的时候可以用到。

defaultSearchField默认搜索属性，如q=solr就是默认的搜索那个字段

solrQueryParser查询转换模式，是并且还是或者（and/or）

4.4. schema配置类型

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

    <analyzer type="index">

        <tokenizer class="solr.WhitespaceTokenizerFactory" />

        <filter class="solr.StopFilterFactory" ignoreCase="true"

            words="stopwords.txt" />

        <filter class="solr.WordDelimiterFilterFactory"

            generateWordParts="1" generateNumberParts="1" catenateWords="1"

            catenateNumbers="1" catenateAll="0" />

        <filter class="solr.LowerCaseFilterFactory" />

        <filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt" />

        <filter class="solr.RemoveDuplicatesTokenFilterFactory" />

    </analyzer>

    <analyzer type="query">

        <tokenizer class="solr.WhitespaceTokenizerFactory" />

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

        <filter class="solr.LowerCaseFilterFactory" />

        <filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt" />

        <filter class="solr.RemoveDuplicatesTokenFilterFactory" />

    </analyzer>

</fieldType>

上面就是一个type了，然后你在fields配置field的时候就可以用这个type。

首先，上面的fieldType的配置中有两个analyzer，它是分词器。

主要把我们的数据进行分割成一个个的词语。词干提取、停止词删除以及相似的操作都被应用于标记，然后才进行索引和搜索，导致使用相同类型的标记。

上面的应用程序的 Solr 的fieldType配置按以下步骤进行设置：

Ø 根据空白进行断词，然后删除所有的公共词（StopFilterFactory）

Ø 使用破折号处理特殊的大小写、大小写转换等等。（WordDelimiterFilterFactory）；将所有条目处理为小写（LowerCaseFilterFactory）

Ø 使用 Porter Stemming 算法进行词干提取（EnglishPorterFilterFactory）

Ø 删除所有的副本（RemoveDuplicatesTokenFilterFactory）

4.5. schema属性、字段

<field name="id" type="string" indexed="true" stored="true"

    required="true" />

<field name="sku" type="text_en_splitting_tight" indexed="true"

    stored="true" omitNorms="true" />

<field name="name" type="text_general" indexed="true" stored="true" />

<field name="alphaNameSort" type="alphaOnlySort" indexed="true"

    stored="false" />

<field name="manu" type="text_general" indexed="true" stored="true"

    omitNorms="true" />

<field name="cat" type="string" indexed="true" stored="true"

    multiValued="true" />

<field name="features" type="text_general" indexed="true" stored="true"

    multiValued="true" />

<field name="includes" type="text_general" indexed="true" stored="true"

    termVectors="true" termPositions="true" termOffsets="true" />

属性是在添加索引、查询的时候必须的配置，如果你不加这些配置。是无法完成索引的创建的。

4.5.1. id属性

首先id属性是未经分析的字符串类型，是可以索引、存储的，并且是唯一的。

4.5.2. sku属性

sku是一个经过分词器分析出来的英文切割的类型字符，可以索引、存储、不要存储规范

4.5.3. multiValued 属性

multiValued 属性是一个特殊的例子，指 Document 可以拥有一个相同名称添加了多次的 Field。

4.5.4. omitNorms属性

omitNorms 属性告诉 Solr（和 Lucene）不要存储规范。

4.5.6. 动态字段dynamicField

介绍一下字段声明下方的 <dynamicField> 声明。

动态字段是一些特殊类型的字段，可以在任何时候将这些字段添加到任何文档中，由字段声明定义它们的属性。

动态字段和普通字段之间的关键区别在于前者不需要在 schema.xml 中提前声明名称。

Solr 将名称声明中的 glob-like 模式应用到所有尚未声明的引入的字段名称，并根据其 <dynamicField> 声明定义的语义来处理字段。

例如，<dynamicField name="*_i" type="sint" indexed="true" stored="true"/> 指一个 myRating_i 字段被 Solr 处理为 sint，尽管并未将其声明为字段。

这种处理比较方便，例如，当需要用户定义待搜索内容的时候。

5、 索引配置solrconfig.xml

Solr 性能因素，来了解与各种更改相关的性能权衡。

表 1 概括了可控制 Solr 索引处理的各种因素：

6、 查询处理配置solrconfig.xml

6.1. <maxBooleanClauses> 标记

定义了可组合在一起形成一个查询的子句数量的上限。对于大多数应用程序而言，默认的 1024 就应该已经足够；

然而，如果应用程序大量使用了通配符或范围查询，增加这个限值将能避免当值超出时，抛出 TooManyClausesException。

6.2. <enableLazyFieldLoading>标记

若应用程序预期只会检索 Document 上少数几个 Field，那么可以将 <enableLazyFieldLoading> 属性设置为 true。

懒散加载的一个常见场景大都发生在应用程序返回和显示一系列搜索结果的时候，用户常常会单击其中的一个来查看存储在此索引中的原始文档。

初始的显示常常只需要显示很短的一段信息。若考虑到检索大型 Document 的代价，除非必需，否则就应该避免加载整个文档。

6.3. <query>部分

<query> 部分负责定义与在 Solr 中发生的事件相关的几个选项。

Searcher 的 Java 类来处理 Query 实例。要改进这一设计和显著提高性能，把这些新的 Searcher 联机以便为现场用户提供查询服务之前，先对它们进行 “热身”。

<query> 部分中的 <listener> 选项定义 newSearcher 和 firstSearcher 事件，您可以使用这些事件来指定实例化新搜索程序或第一个搜索程序时应该执行哪些查询。

如果应用程序期望请求某些特定的查询，那么在创建新搜索程序或第一个搜索程序时就应该反注释这些部分并执行适当的查询。

6.4. 其它配置

solrconfig.xml 文件的剩余部分，除 <admin> 之外，涵盖了与 缓存、复制 和 扩展或定制 Solr 有关的项目。

admin 部分让您可以定制管理界面。有关配置 admin 节的更多信息，请参看solrconfig.xml 文件中的注释。

7、 监视、记录和统计数据

用于监视、记录和统计数据的 Solr 管理选项

8、 智能缓存

智能缓存是让 Solr 得以成为引人瞩目的搜索服务器的一个关键性能特征。

Solr 提供了四种不同的缓存类型，所有四种类型都可在 solrconfig.xml 的 <query> 部分中配置。

solrconfig.xml 文件中所用的标记名列出了这些缓存类型：

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

class 是缓存实现的 Java 名。

size 是最大的条目数。

initialSize 是缓存的初始大小。

autoWarmCount 是取自旧缓存以预热新缓存的条目数。如果条目很多，就意味着缓存的 hit 会更多，只不过需要花更长的预热时间。

下载说明