lucene3.5与mysql 查询性能的对比
由于最近做毕设,需要做一个商品查询模块,用到了lucene来做商品索引的查询,原因为:
1.marks(商品标签)字段含有多个标签,当针对某个标签查询时,或许只能用like 查询,这样的查询慢!
2.没用过lucene,想用来测试下性能
可能结果早就显而易见,但是这次测试我要的是数据,不仅仅是结果,所以别说什么你们知道答案类似的话~
言归正传,我的设计是这样的:
而,性能对比,对比的就是搜索条件,是在lucene快,还是直接去mysql快!
我的lucene模块提供了两种索引方式,
一种是创建索引在文件中,需要查询时在索引文件中去查询
二是在内存中创建索引,需要时直接再内存中查询
由于第二种方式明显快于第一种(设计第一种的原因是,索引仅仅在内存是不够的,需要持久化,不能每次都重新拉数据再创建索引),所以仅仅是放上测试数据,仅作对比!
说明:
1.MYSQL只有主键索引,marks字段建有索引,但是通过
explain select * from t_baobei t where t.baoBeiMarks like '%手' ;
explain select * from t_baobei t where t.baoBeiMarks like '%手%' ;
explain select * from t_baobei t where t.baoBeiMarks like '手%' ;
三种情况确认,该SQL语句没有用到索引
2.lucene分词器用的是
StandardAnalyzer()
测试1: (1W条数据)
创建索引在文件中:
index's num is 10000
create use : 1953 ms
search use :
547 ms
创建索引在内存中:
index's num is 10000
create use : 1046 ms
search use : 94
ms
MYSQL中:
SQL 语句为
SELECT * from t_baobei t WHERE t.baoBeiMarks like '%手机%'
search use : 16ms --40ms
测试2: (3W条数据)
创建索引在文件中:
第一次
index's num is 30000
create use : 2641 ms
search use : 609ms
第二次
index's num is 30000
create use : 3063 ms
search use : 563ms
第三次
index's num is 30000
create use : 3704 ms
search use : 547ms
第四次:删除已有索引,索引大小3M
index's num is 30000
create use : 2500 ms
search use : 531ms
可以看出:
1.创建索引的耗时随记录数的增加而增加,3W条数据的平均耗时为3S以上,数据量是原来的3倍,耗时自是1.5倍
2.从1W到3W,搜索耗时增加不大
创建索引在内存中:
index's num is 30000
create use : 1687 ms
search use : ~94 ms(搜索'手');
search use : ~110 ms(搜索'手机');
可以看出:
1.和1W数据在内存中创建和搜索比,数据量是原来的3倍,创建耗时是原来1.5倍,搜索耗时比本没有差别
2.和在文件中创建和搜索索引比,同样的数据量(3W),创建耗时减少一半,搜索耗时,减少一个数量级!!
3.和MYSQL 相比四种like方式来说,基本没有竞争优势,除最耗时的第一条SQL外,其余mysql均只有lucene的20%
MYSQL中:
* (30000条数据)
[SQL] SELECT * from t_baobei t WHERE t.baoBeiMarks like '%手%'
时间: 140ms
[SQL] SELECT * from t_baobei t WHERE t.baoBeiMarks like '手%'
时间: 30ms
[SQL] SELECT * from t_baobei t WHERE t.baoBeiMarks like '%手机%'
时间: 16ms
--
40ms
[SQL] SELECT * from t_baobei t WHERE t.baoBeiMarks like '手机%'
时间: 16ms
--
40ms
PS: 发现一个有趣的现象,不同的like方式的写法,搜索时间差距这么大.字符越少,%越多,粒度就越细.耗时越严重