关于Solr的使用总结的心得体会

摘要：在项目中使用Solr做为搜索引擎对大数据量建立索引，提供服务，本文是做者对Solr的使用总结的一点心得体会，

具体包括使用DataImportHandler从数据库中近实时同步数据、测试Solr建立索引的性能、以及测试Solr的搜索效率总结等。

具体搜索引擎概念、Solr搭建方法、数据库mysql使用方法，假设读者已有了基础。本文操做均是在linux上进行的。 

1.      Solr

1.1  Solr从数据库中读取数据并建立索引速度（使用DataImportHandler）

l 一次性建立索引

在JVM内存配置为256M时，创建索引至1572865时出现Java heap异常；增长JVM内存配置至512M，设置系统环境变量：JAVA_OPTS -Xms256m -Xmx512m，能成功创建2112890条(花费2m 46s)。

平均索引建立速度为：12728/s（两个string字段，长度大约为20字符）。

l 增量建立索引

注意：近实时增量索引须要写数据库服务的时间与搜索引擎服务器时间同步（数据库服务时间先于搜索引擎服务器时间才行）。

       使用默认的DIH建立增量索引速度较慢（50/s~400/s），不如全索引（1W/s），由于须要从数据库中读取多遍（1、要更新的IDs；2、每1ID去数据库中重取全部列）。

     故须要更改DIH增量索引程序，以全索引的方式读数据；或采起全读出的方式，一次全读出全部列，具体文件配置以下：

 

<?xml version="1.0" encoding="UTF-8" ?>          <dataConfig>                    <dataSource name="mysqlServer"                             type="JdbcDataSource"                             driver="com.mysql.jdbc.Driver"                             batchSize="-1"                              url="jdbc:mysql://192.103.101.110:3306/locationplatform"                             user="lpuser"                             password="jlitpassok"/>                    <document>                             <entity name="locatedentity" pk="id"                                      query="select id,time from locationplatform.locatedentity where isdelete=0 and my_date > '${dataimporter.last_index_time}'"                                      deletedPkQuery="select id from locationplatform.locatedentity where isdelete=1 and my_date > '${dataimporter.last_index_time}'"                                      deltaQuery="select -1 id"                                      deltaImportQuery="select id,time from locationplatform.locatedentity where isdelete=0 and my_date > '${dataimporter.last_index_time}'">                                      <field column="id" name="id"/>                                      <field column="time" name="time"/>                             </entity>                    </document>          </dataConfig>

经过这样的配置能够达到增量索引9000/s（两个string字段）（数据库里对时间创建索引，对这里的性能影响不大）。

l  注意：做者不推荐使用DataImportHandler，有其它更好更方便的实现可使用。

 

1.2  Solr建立索引效率

l ConcurrentUpdateSolrServer使用http方式，embedded方式官方不推荐使用。ConcurrentUpdateSolrServer不须要commit，solrServer.add(doc)便可添加数据。SolrServer solrServer = newConcurrentUpdateSolrServer(solrUrl, 队列大小, 线程数)其须要与autoCommit、autoSoftCommit配置搭配使用，网上建议配置以下：

<autoCommit>                  <maxTime>100000(1-10min)</maxTime>                  <openSearcher>false</openSearcher> </autoCommit> <autoSoftCommit>                  <maxTime>1000(1s)</maxTime> </autoSoftCommit>

17个各类类型字段（原纯文本Size约为200B，SolrInputDocument对象Size约为930B），以只保存ID、每字段均创建索引的方式建立索引。

如需具体的测试代码能够联系本人。

l 17个字段，四核CPU，16G内存，千兆网络

数据量(W条)	线程数	队列大小	时间(s)	网络(MB/s)	速率(W条/s)
200	20	10000	88	10.0	2.27
200	20	20000	133	9.0	1.50
200	40	10000	163	10.0	1.22
200	50	10000	113	10.5	1.76
200	100	10000	120	10.5	1.67

l 速度：Solr建立索引速度与Solr机器CPU正相关，通常状况下CPU占用率能达到接近100%，内存占用率在默认状况下需达到接近100%，网络、磁盘占用率均小。所以建立索引的效率瓶颈在CPU及内存。当内存占用率维持在接近100%，索引大小达到物理内存大小时，插入新的数据容易出现OOM错误，这时须要使用ulimit –v unlimited命令更改virtual memory配置为unlimited再启动Solr便不会出现OOM错误。在64位机器系统上，官方推荐使用MMapDirectory。

l NRTCachingDirectory速度偏慢，会在某一时间索引添加停滞，Size先大后小，减少后索引添加继续。

l 大小：1亿索引大小约为13-16GB，2亿索引大小约为30GB。

 

1.3  Solr搜索方式

l  交集：{name:亿度 AND address:海淀} {text:海淀 AND 亿度}。

l  联集：{name:亿度 OR address:海淀} {text:海淀 OR 亿度}。

l  排除：{text:海淀 -亿度}。

l  通配符：{bank:中国*银}。

l  范围：{num:[30 TO60]}。

l  分页：start rows

l  排序：sort

l  Group 权重中文分词 ...

 

1.4  亿级数据搜索速度

l  本节测试是基于1.2节建立的索引上的。

l精确搜索

数据量(亿条)	字段数	字段类型	时间(ms)
1	1	long	1
1	1	double	80-1400
1	1	string	7-800
1	1	date	2-400
1	2(OR)	long	2
1	2(OR)	double	200-2400
1	2(OR)	string	500-1000
1	2(OR)	date	5-500

l 模糊搜索

数据量(亿条)	字段数	字段类型	时间(ms)
1	1	long	2000-10000
1	1	double	1000-17000
1	1	string	20-16000
1	1	date	/
1	2(OR)	long	3000-25000
1	2(OR)	double	7000-45000
1	2(OR)	string	3000-48000
1	2(OR)	date	/

l 范围搜索

数据量(亿条)	字段数	字段类型	时间(ms)
1	1	long	6-46000
1	1	double	80-11000
1	1	string	7-3000
1	1	date	1000-2000
1	2(OR)	long	100-13000
1	2(OR)	double	100-60000
1	2(OR)	string	3000-13000
1	2(OR)	date	7000-10000

l 结论：

范围越大，结果数据越多，搜索花费时间越长。

第一次搜索较慢，后来时间花费较少。

来自为知笔记(Wiz)