Solr分词性能测试――一元分词与IK分词的比较

目  录

1 测试目的... 3

2 测试方案... 3

2.1 测试环境... 3

2.2 参数配置... 3

2.2.1 schema.xml的调整... 3

2.2.2 solrconfig.xml的调整... 4

2.2.3 其他调整... 4

2.3 对比实验设计... 4

3 测试结果... 4

3.1 实验结果... 4

3.2 数据分析... 5

3.2 其他发现... 6

4 测试结论... 6

 

1 测试目的

    从功能上考虑一元分词的效果更能满足系统的应用，但原先使用中文分词的办法是更加常见的手段。所以这里做几组对比测试去从分词速度、索引文件大小、检索速度这三个方面去比较优劣，并分析出原因，最后给出一个分词方案选用的结论。另外还想在测试中去找出一个索引量增加趋势的评估公式。

    但考虑到检索速度这个需要有具体的检索条件，只能粗略的进行测试。

2 测试方案

2.1 测试环境

CPU: Intel(R) Core?2 DUO P8600 @ 2.40GHz

Memory: Dual DDR3 1066 3.25G

OS: Ubuntu 10.10 32bit

Disk：250GB 5400rpm

2.2 参数配置

2.2.1 schema.xml的调整

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

      <analyzer type="index">

        <!-- <tokenizer class="solr.StandardTokenizerFactory"/> -->

<tokenizer class="org.wltea.analyzer.solr.IKTokenizerFactory" mode="most-words" isMaxWordLength="false"/>

        <filter class="solr.StopFilterFactory"

                ignoreCase="true"

                words="stopwords.txt"

                enablePositionIncrements="true"

                />

        <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="1"/>

        <filter class="solr.LowerCaseFilterFactory"/>

        <filter class="solr.TrimFilterFactory"/>

        <filter class="solr.PorterStemFilterFactory"/>

      </analyzer>

</fieldType>

2.2.2 solrconfig.xml的调整

    <ramBufferSizeMB>128</ramBufferSizeMB>

    <mergeFactor>2</mergeFactor>

2.2.3 其他调整

    增加了750个停用词。

2.3 对比实验设计

    先从线上系统到回一批真实数据，主帖约19万条，回帖约260万条。然后配置solr的dataimport设置，使其可以从数据库中把相应的数据读取出来并建立索引。

    修改索引建立方式，分别用一元索引和IK分词对同样一组数据进行索引测试，比较其建立索引的时间，索引文件大小，检索时间这三个维度。

    另外从线上系统导回一个小批量的数据，简单评估一下索引文档数量与其索引时间和索引大小的关系。

 

    在实验过程中发现一元索引的检索速度很不理想，加了一组限制条件以后的检索时间测试。

    这里用的检索词如下：

『涉及到业务，这里暂不显示』

    检索限制条件为：postTime:[2011-04-25T23:59:59.999Z TO *]

3 测试结果

3.1 实验结果

分词算法	数据类型	数据量	索引时间	索引大小	检索时间	限制为一个月内的检索时间
一元分词	主贴	约5万条	0：30	64m
	回帖	约68万条	1：35	98m
	主贴	约19万条	2：03	224m	9236ms	968ms
	回帖	约260万条	6：27	340m	9868ms	1308ms
IK分词	主贴	约19万条	4：49	245m	2331ms
	回帖	约260万条	6：28	341m	9331ms

3.2 数据分析

    主贴与回帖的数据区别主要在数据量上，主贴属于长文本，回帖属于短文本。从以上实验结果中可以看出：

    对于长文本，一元分词索引性能是IK分词的200%，且索引文件大小还略低于IK分词的。但对于全量检索速度却远低于IK分词，然而加上一个月内的限制条件以后，检索速度大大加快了。

    对于短文本，一元分词与IK分词的索引性能、索引文件大小和检索速度都相当。

    初步分析索引性能问题是1）因为一元分词算法简单，所以索引效率更高；2）IK分词是使用最大分词配置的，所以可能的分词情况会比较多，所以索引文件和一元分词相当；3）检索速度上因为走IK分词，需要查询的内容会比较少，而用一元分词查询的内容就会比较多，所以速度上会有比较大的差异，但是回帖都很慢有些想不通，不知道和帖子多有没有关系。

    另外主贴和回帖量都增加的情况下，建立索引的时间同比增长是略有加大的，但索引文件大小在同比增长上略有下降。这个只有两组数据，没办法做详细对比画出趋势图，但这个索引建立时间应该还是在能接受的范围，暂不做详细测试了。

    目前线上系统的主贴表有100万数据，但索引文件却有4G多，这主要和存放了正文有关系，所以不能直接拿来参考。

3.2 其他发现

    l  在测试中发现，由于是采用数据库数据全部导入的方式，一次批量读取非常大量的数据，因此造成了内存溢出。由于测试数据总量还不是特别大，所以我这里只是把java程序的可用内存加大到2G就可以了。但实际线上情况肯定数据量要远远大于内存，因此需要使用多次增加建立索引才可以。

   2  根据整个系统资源的使用情况观察，发现建立索引大致分两个阶段，第一个阶段就是读取数据，这个时候一个IO密集型操作；第二个阶段是建立索引，这个时候是计算密集型操作，双核cpu消耗在100%以上。但有其他程序占用较多cpu的时候，建立索引的速度会有很明显的下降。

   3  索引查询是有缓存的，如果同一个查询条件多次查询，那么后面几次都会在ms级别显示结果，这个在配置文件里面都可以设置的。在测试中发现，缓存失效的条件是索引发生变化。

4 测试结论

    在本次实验中发现一元分词对长文本索引上的表现是明显高于IK分词，但对于检索速度上是处于劣势的，实际使用有很有必要加上时间范围限制以加快检索速度；短文本的索引和检索都有与其有相当的表现。另外一元分词的效果是我们期望的，所以在系统中完全可以使用一元分词。