针对Lucene 建立索引过程与搜索过程耗费时间的矛盾一点思路
使用lucene,首先要做的就是建立索引文件,这是一个非常耗时的工作,特别是针对大数据量进行索引的时候更是如此.
Lucene 提供了几个优化参数
mergeFactor,maxMergeDocs,minMergeDocs,首先说的是mergeFactor, 默认值为10,控制索引段的合并频率和大小,即每当有10个Document对象添加到索引段时,lucene就会在磁盘建立一个新的段,当创建了10个这样的段之后就会将这10个段合并为一个段,以此类推下去,当这个段内的Document对象数量没有超过maxMergeDocs的值的时候,会一直按照这个规则合并下去,同时磁盘目录内的索引段数量控制在10个以内.
当制定了较小的mergeFactor时,也就意味着将进行大量的磁盘操作,但是带来的好处是生成较少个数的索引文件.于是矛盾就产生了
mergeFactor较小 则制作索引文件非常慢,但是搜索相对会快.
我们如何来解决这样的矛盾呢? 我提出如下的解决方案,并且已经在我们项目中使用了这样的方式.
我先说明下我们的需求.
我们是将数据库中的内容制作成索引文件并提供搜索,数据库中有上百万的数据,制作一次索引大概需要1个半小时时间(数据库和索引制作程序在一个机器上)
好了,不废话了,说我们的方式
lucene 提供了FsDirectory和RamDirectory两种方式,这里我们首先使用RamDirectory,也就是说我们在内存中创建索引文件,存储的Document个数根据你内存而定了,这样不管mergefactor 指定多少,索引段合并多少次,都是在内存中操作了,减少了IO操作, 当Document的个数比如大于5000时 将RamDirectory 中的内容合并到FsDirectory中,通过fsDirectory.addIndexes(Directory[] {RamDirectory});实现.
这样也就意味着每添加5000个Document 才进行了一次IO操作,而假如把mergeFactor设置为5000的话,带来的问题就是,假如你的数据量足够大,而使你产生更多的索引段.
以上就是我的方式,希望有更好的方式可以交流
Lucene 提供了几个优化参数
mergeFactor,maxMergeDocs,minMergeDocs,首先说的是mergeFactor, 默认值为10,控制索引段的合并频率和大小,即每当有10个Document对象添加到索引段时,lucene就会在磁盘建立一个新的段,当创建了10个这样的段之后就会将这10个段合并为一个段,以此类推下去,当这个段内的Document对象数量没有超过maxMergeDocs的值的时候,会一直按照这个规则合并下去,同时磁盘目录内的索引段数量控制在10个以内.
当制定了较小的mergeFactor时,也就意味着将进行大量的磁盘操作,但是带来的好处是生成较少个数的索引文件.于是矛盾就产生了
mergeFactor较小 则制作索引文件非常慢,但是搜索相对会快.
我们如何来解决这样的矛盾呢? 我提出如下的解决方案,并且已经在我们项目中使用了这样的方式.
我先说明下我们的需求.
我们是将数据库中的内容制作成索引文件并提供搜索,数据库中有上百万的数据,制作一次索引大概需要1个半小时时间(数据库和索引制作程序在一个机器上)
好了,不废话了,说我们的方式
lucene 提供了FsDirectory和RamDirectory两种方式,这里我们首先使用RamDirectory,也就是说我们在内存中创建索引文件,存储的Document个数根据你内存而定了,这样不管mergefactor 指定多少,索引段合并多少次,都是在内存中操作了,减少了IO操作, 当Document的个数比如大于5000时 将RamDirectory 中的内容合并到FsDirectory中,通过fsDirectory.addIndexes(Directory[] {RamDirectory});实现.
这样也就意味着每添加5000个Document 才进行了一次IO操作,而假如把mergeFactor设置为5000的话,带来的问题就是,假如你的数据量足够大,而使你产生更多的索引段.
以上就是我的方式,希望有更好的方式可以交流
