关于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)