Solr基本配置（三）——Searcher

<query />

在标签<query/>里面可以进行一些优化搜索的配置。在Solr的查询过程中，运用到一个叫searcher的组件，在一个特定的时间只能有一个“active”的searcher。这个active searcher在Lucene索引中有一个只读的映射。当新的document加入到Solr的时候，当前的searcher在搜索结果中是看不到这个新加的document的。那么问题就来了：怎么样才能让新添加的文件出现在搜索结果中？一个解决这个问题的办法就是关闭当前的searcher并对新的索引文件打开一个新的searcher。

在admin界面中，查看collection1的Plugins/Status，点击core：

第一行展示的就是当前的Searcher，当我们重新对文件建立索引，在example的exampledocs下运用：

Java -jar post.jar *.xml:

刷新界面：　

可以看到Searcher改变了。这是因为post.jar提交个commit指令。从上面的示例我们知道commit指令可以创建一个新的searcher，使得可以检索到最新的文件，当新searcher创建的时候要先销毁旧的searcher。这时候如果还有基于旧searcher的查询在进行中，Solr就要等待所有进行中的查询结束。然后，所有基于当前searcher的cached对象都要失效。因为之前建立起来的cache都失效了，所以建立一个新的searcher可能是很耗时的。假设一个用户在返回的结果中进行翻页 *** 作，当用户从第二页翻到第三页的时候一个新的searcher打开了，此时用户就会一直等待第三页的加载，但是这时候之前加载的document都已经失效，所以就会让用户感觉到加载很慢。

对于上述问题，Solr提供了一系列的工具，Solr在建立一个searcher的时候有称为warming的概念，即让新的searcher在后台建立，并让当前的searcher继续工作直到后台的searcher完全warm。

Warming a new searcher

Solr运用这个策略来使得在一段时间内还是返回旧的结果，而避免用户因为新建searcher而降低查询的性能。有两种warming的策略：autowarming new caches from the old caches（从旧的cache中创建新的cache）和execute cache-warming queries(重新执行一些queries来填充新的cache)。

Cache-warming queries是一种preconfigured query来构建新searcher的cache。

上面的配置定义了一系列的queries当newSearcher事件出现的时候就执行（如在commit之后）。

<useColdSearcher/>

如果为false，那么Solr就会阻塞直到warming searcher完成所有的warming queries。

<useColdSearcher>false</useColdSearcher>

如果为true，Solr会马上注册一个warming searcher。

<maxWarmingSearchers>

定义在后台可以同时warming的最大searcher数量。默认值为2.

本文是延续 Solr的使用 系列，前一篇文章已经讲了 Solr 的部署和数据推送，这里主要以示例方式讲述 Solr 的常见查询语法，同时介绍如何使用 PHP 语言的客户端 solarium 同 Solr 集群进行数据交互。

想要详细地了解 Solr 查询语法，可参考 官方wiki 。

用于示例的数据，我已经推送到了 Solr ， 见这里 。数据 Core 为 rooms，数据格式形如：

通过向 Solr 集群 GET 请求 /solr/core-name/select?query 形式的查询 API 完成查询，其中 core-name 为查询的 Core 名称。查询语句 query 由以下基本元素项组成，按使用频率先后排序：

wt 设置结果集格式，支持 json、xml、csv、php、ruby、pthyon，序列化的结果集，常使用 json 格式。

fl 指定返回的字段，多指使用“空格”和“,”号分割，但只支持设置了 stored=true 的字段。 * 表示返回全部字段，一般情况不需要返回文档的全部字段。

字段别名 ：使用 displayName:fieldName 形式指定字段的别名，例如：

函数 ：fl 还支持使用 Solr 内置函数 ，例如根据单价算总价：

fq 过滤查询条件，可充分利用 cache，所以可以利用 fq 提高检索性能。

sort 指定结果集的排序规则，格式为 <fieldName>+<sort>，支持 asc 和 desc 两种排序规则。例如按照价格倒序排列：

也可以多字段排序，价格和面积排序：

查询字符串 q 由以下元素项组成，字段条件形如 fieldName:value 格式：

以上元素项的默认值由 solrconfig.xml 配置文件定义。通常查询时设置 q=*:* ，然后通过 fq 过滤条件来完成查询，通过缓存提高查询性能。

Solr 的模糊查询使用占位符来描述查询规则，如下：

查询小区名称中包含“嘉”的房源信息：

Solr 的模糊查询为：

单精确值查询是最简单的查询，类似于 SQL 中 = *** 作符。查询小区 id 为 1111027377528 的房源信息：

Solr 中查询为：

多精确值查询是单精确值查询的扩展，格式为 (value1 value2 ...) ，功能类似于 SQL 的 IN *** 作符。查询小区 id 为 1111027377528 或者 1111047349969 的房源信息：

Solr 中查询为：

范围查询是查询指定范围的值（数字和时间），格式为 [value1 TO value2] ，类似于 SQL 的 BETWEEN *** 作符。查询价格在 [2000, 3000] 的房源信息：

Solr 中范围查询为：

几个特殊的范围查询：

将基本查询结合布尔查询，就可以实现大部分复杂的检索场景。布尔查询支持以下几种布尔 *** 作：

查询北京市价格区间在 [2000, 3000] 或者上海市价格区间在 [1500, 2000] 的房源信息：

转换为逻辑与布尔查询：

在实际中分组查询比较常见，当然 Solr 也支持分组查询。分组查询语句由以下基本元素项组成（常用部分）：

查询西二旗内价格最便宜小区的房源信息：

Group 分组查询为：

结果为：

在大多数情况下，Group 分组已经能满足我们的需求，但是如果待分组字段为多值，Group 分组已经无能为力了，这时使用 Facet 就能轻松解决。

Solr 的 Facet 语句由以下基本元素构成（常用）：

例如，统计每个商圈的房源分布情况并倒序排列，由于 bizcircleCode 字段为多值，Facet 查询为：

结果如下：

Solr 的 geofilt 过滤器可以实现 LBS 检索，但要在 schema.xml 配置中将需检索字段的字段类型设置为 solr.LatLonType 类型。geofilt 过滤器参数列表如下：

示例中的 location 字段，值为 “40.074203,116.315445”，类型配置为：

则检索坐标点 40.074203,116.315445 附近 2 公里的房源信息：

Solr 提供一些函数以实现逻辑或数学运算。其中常用 数学运算 函数列表如下：

常用的 逻辑运算 函数：

这些函数可以使用在返回值或者查询条件上。例如返回每个房源的每平方米价格信息：

PHP 可以使用 solarium 客户端，实现 Solr 数据源的检索，详细使用说明 见这里 。

solarium 客户端需要配置 Solr 的基本信息。如下：

solarium 提供的查询方法较丰富，整理后如下表所示：

查询北京市的所有房源信息，如下：

solarium 提供的分组查询方法如下表所示（常用）：

获取西二旗每个小区的房源分布信息，如下：

solarium 提供的 Facet 查询方法，如下表（常用）：

获取北京市每个商圈的房源分布信息，如下：

到这里，Solr 系列就整理完毕了，未涉及的部分后续接触时再补充。这两天利用休息时间充电，自己在 Solr 方面的技能也算是上了一个台阶了。

---