Lucene优化(索引库存放位置选择) | 学习笔记

简介: 快速学习Lucene优化(索引库存放位置选择)。

开发者学堂课程【Lucene知识精讲与实战(下)Lucene优化(索引库存放位置选择)】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/701/detail/12355


Lucene优化(索引库存放位置选择)

 

内容介绍:

一、选择合适的位置存放索引库

二、搜索api的选择

 

一、选择合适的位置存放索引库

1、lucene优化中讲索引库的位置,存放在哪通过存放的位置提高查询以及创建索引的速度,列举索引库存放位置的对象有三个。

写操作

读操作

特点

SimpleFSDirectory

java.io.RandomAccessFile

java.io.RandomAccessFile

简单实现,并发能力差

NIOFSDirectory

java.nio.FileChannel

FSDirectory.FSIndexOutput

并发能力强, windows平台下有重大bug

MMapDirectory

内存映射

FSDirectory.FSIndexOutput

读取操作基于内存

创建索引库时,制定索引库的位置,使用的是 FSDirectory 对象,FS file systems 文件系统,存到文件系统中就是存到硬盘中,着重讲 MMapDirectoryFSDirectory 不管是创建索引和文档文件,还是从指定的目录中查询出文档文件和索引文件的内容,都是通过操作硬盘,把硬盘中的拿过来,或者写入硬盘中,  MMapDirectory 写的时候是内存映射,读的时候,里面是有缓存的,而对于FSDirectory 里面只是通过硬盘操作,没有内存参与,而 MMapDirectory 有内存参与,写的时候是往硬盘里面写,第一次查询时是从硬盘中查,把查询出的数据,加载到内存中,第二次查就直接从内存中查,查询速度要比直接从硬盘中查要快的多。

2、没有优化情况下,小100万条数据,创建索引需要7725ms,如果换成  MMapDirectory 把优化注解掉,清除索引库,重新创建索引,执行。

1.1.png

关掉,原因是之前创建索引时用的是 standaranalyzer,而这时换成 ikanalyzer ,对于查询速率是不准确的,重现换成 standaranalyze,清除索引库,   standaranalyzerikanalyzer 中文分词器,分词的速度不一样,所以要换成跟以前代码一模一样,只有存放索引库用的对象不一样,才能对比出是否优化。

1.2.png

写入用了7425ms,快了一点。

3、第一次查询从硬盘中查,第二次从内存中查,所以在查询时不能用小例子,需要加入到项目中完成测试,加时间。起始时间。

long starttime= System. current TimeMillis();

4、在查询结束时有结束时间。

long endTime = System. currentTimeMillis();

打印时间

System. out .println("=====消耗时间为======" + (endTime - startTime) + "ms");

由于存的时候用是 MMapDirectory ,所以取的时候也用 MMapDirectory ,启动进行测试。打开浏览器搜索手机,花费324ms

1.3.png

再查询花费18ms。由此可见第一次是从硬盘中读取出来,把查询出的数据放到内存中,第二次点查询直接从内存中查出数据,速度非常快,把设置出来的数据放到里面。

*使用MNapDirectory消耗的查询时间

*====消耗时间为========324ms

*====消耗时间为========18ms

5、关闭项目看原来花费多少时间,再换成 FSDirectory 将索引库清除。

1.4.png

重新创建索引,重新启动项目,再查询,第一次查询花费324ms,第二次花费21ms,比用 MNapDirectory 花的时间长,因为是小100万条数据,数据很小,如果数据大一些,差距会更大,存放索引库的位置,用的对象不同,查询效率和创建索引的效率都不一样,建议使用 MNapDirectory ,用它代替传统 FSDirectory 文件系统的目录,加快查询效率。

 

二、搜索api的选择

1、尽量使用 TermQuery 代替 QueryParser TermQuery 能提供简单的查询,只能是通过域名查具体的某一个域值,QueryParser 里面非常强大,既有默认查询域的支持,又可以对查询的关键字,查询结果指定 andall 交集并集。如果没有过多的业务建议使用 TermQuery 进行查询,如果业务比较复杂,有好几个查询条件,求交集并集等,只能使用 QueryParser

2、尽量避免大范围的日期查询,大量的日期范围的查询会导致搜索效率变慢。

相关文章
|
7月前
|
关系型数据库 MySQL 数据库
MySQL索引优化:深入理解索引合并
MySQL索引优化:深入理解索引合并
|
8月前
|
存储 关系型数据库 MySQL
MySQL索引简介(包含索引优化,索引失效,最左前缀简洁版)
MySQL索引简介(包含索引优化,索引失效,最左前缀简洁版)
116 0
|
关系型数据库 MySQL 索引
新增数据时,MySQL索引树的自调整过程
刚开始你一个表建好后,就一个数据页,就是聚簇索引的一部分,而且还是空的。若你插入数据,就是直接往这数据页里插入,也没必要给他弄索引页
120 0
|
SQL 搜索推荐 关系型数据库
B+树索引使用(8)排序使用及其注意事项(二十)
B+树索引使用(8)排序使用及其注意事项(二十)
|
存储 SQL 缓存
B+树索引使用(9)分组、回表、覆盖索引(二十一)
B+树索引使用(9)分组、回表、覆盖索引(二十一)
|
SQL 关系型数据库 数据库
MySQL优化系列(二)--查找优化(1)(非索引设计)
MySQL优化系列(二)--查找优化(1)(非索引设计) 接下来这篇是查询优化,用户80%的操作基本都在查询,我们有什么理由不去优化他呢??所以这篇博客将会讲解大量的查询优化(索引以及库表结构优化等高级用法后面文章再讲),先讲单表查优化,再讲多表查优化。
1828 0

热门文章

最新文章

下一篇
开通oss服务