solr简单使用

一条索引包含了

Tips

solrJ 创建core只是把自己的文件夹加入到solr中，各种文件还要自建立

field name="5#城市" type="string" indexed="false" stored="true"/

pf 查询字段 qf 设置字段性对查询字段的比重 bf 设置权重的值

Searchers are presented with the indexed terms, along with numerical counts of how many matching documents were found were each term. Faceting makes it easy for users to explore search results, narrowing in on exactly the results they are looking for

简单说,solr的facet特性会搜索特定的facet.item,返回query中查询字段在item字段上的统计值且仅仅返回统计数量.

facet.poivt 实现了多维统计.例如统计班级学生的成绩分布，可以设置poivt=class,poivt=socore 返回的结果就是每个班各个成绩段学生的数量

在SolrJ中使用facet功能需要手动开启: query.setFacet(true) .然后根据需要 query.set(,) 添加条件.

facet 简单使用

什么是solr

SOLR 搜辣 是一款 Apache软件基金会开发的企业搜索服务器软件。

Solr是用Java编写、运行在Servlet容器（如Apache Tomcat或Jetty）的一个独立的全文搜索服务器。Solr 强大的外部配置功能使得无需进行Java编码，便可对其进行调整以适应多种类型的应用程序。Solr有一个插件架构，以支持更多的高级定制。

Solr的提交方式

网上的解释真的不能看，全是错的，因为生产中遇到的一次问题对该原理研究了3天，查看了大量书籍，官方文档终于有了较为深刻的认识

Solr的提交方式只有两种，标准提交（硬提交，hard commit）和软提交(soft commit)，说三种的错误

1.默认的提交即硬提交，commit之后会立刻将文档同步到硬盘，在开启新搜索器之前会阻塞，直到同步完成

2.默认情况下commit后会开启一个新搜索器（newSearcher），然后进行预热，预热完成后顶替旧搜索器，使旧缓存失效，但是开启新searcher及预热的过程（IO消耗）耗费资源过大，且可能被阻塞，所以应尽量避免在高峰期开启newsearcher,搜索器同一时间只能有一个处于active状态

3.为了避免频繁commit，solr提供了***tocommit功能，可以设置每隔多久提交一次，或者待提交文档量达到阀值提交一次，并且可定义是否在提交后开启新的搜索器，若不开启，则缓存不能够被刷新，新更新文档不能够被实时读取到

1.软提交是将文档提交到内存，并不实时写入硬盘，减少了耗时的I/O操作

2.为了保证实时搜索，solr在软提交基础上引入了近实时搜索（NRT），NRT并不会被文档更新所阻塞，也不会等待文档合并完成再打开一个搜索器（以下摘自官方文档）

3.在lucene4.x 之前，solr采用NRTManager实现NRT,之后使用ControlledRealTimeReopenThread实现，它通过IndexWriter对象来监控内存中的文档变化，从而得到最新的文档信息，该过程既不需要高耗时的I/O操作，也不需要刷新搜索器，所以非常之快，耗费资源很少

4.所以 近实时搜索（NRT）是软提交的一个特性

5.同样的软提交也支持自动提交的方式，配置如下

5.这 两种提交方式并不冲突 ，试想我们程序使用了软提交，但何时可以把数据真正同步到磁盘呢？这时候就可以两者结合达到目的

我们设置每隔5000ms进行一次软提交，文档存入了内存，也可以实时搜索，然后每隔300000ms又会进行进行一次硬提交，同步到磁盘，无需刷新Searcher，如此两者兼顾

6.在配置文件中配置后，在客户端就不需要维护提交方式和提交时间了

1.很多人说由于软提交不及时写入硬盘，所以在jvm崩溃时会丢失部分数据，但其实不会，因为软提交和硬提交在commit时都会记录下操作log,若发生崩溃，会在重启时会从log恢复，这点很像mysql的事务日志操作

2.若maxDocs和maxTime都配置了，则那个条件先到就按那个执行，官方建议使用maxTime,因为solr文档较多，通常更新量也大，使用maxTime可能更能减少提交的频次，但在此建议根据实际情况来决定

3.commit操作后，可执行optimize操作，该操作会合并索引碎片，合并后索引性能会有所提升，但该操作消耗较大，每晚定时操作一次即可

Solr备份和恢复

solr目前我们主要使用的是6.x版本，在上面有个类似的backup和restore功能，但是实际测试发现只能对一个core进行操作，而不能对整个collection进行操作，实际中使用solr多采用solrCloud模式，而不是单机或主备模式。

所以在这这种情况下只能采用别的方式进行数据的备份和恢复。

查看solr的帮助文档，发现solr的HTTP接口的API中有删除副本的功能，仔细查看发现删除副本的时候可以保留数据不删除，这不就是我们需要的吗。

所有的副本都下线后，state.json就会变成：

这时候重新建这个索引会报错，已经存在。

通过轮询依次调用各个副本信息后，将整个collection做到完全下线。

但是下线后，这个collection在solr前台仍然存在，还占有一定的资源，***的办法是删除state.json信息，因为solr还对zookeeper上此节点进行监听的。

上线的时候依次恢复多个副本，当然至于先恢复哪个副本，顺序没有关系，

恢复的语句如下：

;location=/data/***s/tmpDirname=test4_20180109140508wt=json

注意：

1、location： 为备份的数据位置，/data/***s/tmpDir 在23主机上必须存在且有权限。

2、name: 为备份的文件夹后缀名字，按照上面的操作，实际的文件夹为：snapshot. test4_20180109140508

3、备份的目录中的文件夹均是索引数据不含有事务日志。

4、如果不提供name参数则是snapshot.xxxxx xxxx为时间戳信息。

5、numberToKeep即可以保存的***备份数目，可以提供也可以不提供。

solr自带的api是对整个collection操作，但是却只操作调用的API，不能做分布式操作。

备份步骤：

1）对各个solr节点均需要调用如下操作：

;location=/data/***s/tmpDirname=test4_20180109140508wt=json

注意：

1、location： 为备份的数据位置，/data/***s/tmpDir 在23主机上必须存在且有权限。

2、name: 为备份的文件夹后缀名字，按照上面的操作，实际的文件夹为：snapshot. test4_20180109140508

3、备份的目录中的文件夹均是索引数据不含有事务日志。

4、如果不提供name参数则是snapshot.xxxxx xxxx为时间戳信息。

5、numberToKeep即可以保存的***备份数目，可以提供也可以不提供。

恢复collection信息调用如下：

;location=/data/***s/tmpDirname=test4_20180109140508wt=json

注意：

1、name不能提供全名和原来的备份的名字一样。

2、如果怕时间长，可以提供异步id，参数为：async = xxxid 然后通过调用查看执行结果：

/admin/collections?action=REQUESTSTATUSrequestid=request-id

3、对于replicationFactor 和maxShardsPerNode、***toAddReplicas 还提供重写功能。

方案优缺点：

优点： 整个过程简单，参数少；备份出来是文件夹形式方便压缩或换地方存储。

缺点： 不能备份一个solr节点多个的情况； 由于也有复制，耗时不定，可以采用异步的方式。

Solr的使用 — 检索

本文是延续 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 的字段。 * 表示返回全部字段，一般情况不需要返回文档的全部字段。

字段别名 ：使用 displ***Name: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 方面的技能也算是上了一个台阶了。

关于solr和丧偶老人再婚好还是不再婚好的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。