神马文学网rimen[天外孤客--jerry的blog]: 关于Lucence中的索引优化
来源：百度文库 编辑：神马文学网 时间：2024/04/30 00:19:13
关于Lucence中的索引优化
车东在他的文章中提到，通过提供IndexWriter的merge因子属性可以提供索引的速度．从原理入手，进行lucence代码的分析，然后通过测试数据进行实际应用中的优化．
先看下面的代码：
private final void maybeMergeSegments() throws IOException {
long targetMergeDocs = minMergeDocs;
while (targetMergeDocs <= maxMergeDocs) {
// find segments smaller than current target size
int minSegment = segmentInfos.size();
int mergeDocs = 0;
while (--minSegment >= 0) {
SegmentInfo si = segmentInfos.info(minSegment);
if (si.docCount >= targetMergeDocs)
break;
mergeDocs += si.docCount;
}
if (mergeDocs >= targetMergeDocs) // found a merge to do
mergeSegments(minSegment + 1);
else
break;
targetMergeDocs *= mergeFactor; // increase target size
}
}
一看就知道，当segmentInfos中的merge的文档数小于targetMergeDocs是，系统不会进行merge,而targetMergeDocs由minMergeDocs和mergeFactor决定．SegmentInfo 如果是单个索引的话，si.docCount为1,如果此时minMergeDocs为１，也就是targetMergeDocs为１，系统会进行merge,这样在效率上回大大降低．minMergeDocs＞１的话，决定merge的大小还是minMergeDocs，targetMergeDocs *= mergeFactor无效，可以说mergeFactor只对批量索引有效，si.docCount＞１的情况．
如果是批量索引，当si.docCount＞minMergeDocs时，minMergeDocs和targetMergeDocs 决定了merge的数量．
在我的优化过程中，由于采用的是单一索引，所以我调整mergeFactor带来的性能上的差异不大，可以看成是系统带来的误差．而我改变minMergeDocs获得的性能可以从下面的数据看到：
以10000条记录为测试案例
minMergeDocs 对于运行的时间ms
default (10) times=32707
20 times=21191
30 times=18476
40 times=16334
50 times=16744
100 times=13138
200 times=10125
400 times=10234
800 times=10015
1600 times=11256
3200 out of memory
从上面的数据来看，在100~200之间性能和存储比较优．当minMergeDocs 大到一定的程度，由于在内存调度上的问题，系统可能有更大量的访问IO.建议在定制lucence时，对与单一的索引可以把minMergeDocs 设成100左右以提供性能．而车东给出的说法并不完全．
车东在他的文章中提到，通过提供IndexWriter的merge因子属性可以提供索引的速度．从原理入手，进行lucence代码的分析，然后通过测试数据进行实际应用中的优化．
先看下面的代码：
private final void maybeMergeSegments() throws IOException {
long targetMergeDocs = minMergeDocs;
while (targetMergeDocs <= maxMergeDocs) {
// find segments smaller than current target size
int minSegment = segmentInfos.size();
int mergeDocs = 0;
while (--minSegment >= 0) {
SegmentInfo si = segmentInfos.info(minSegment);
if (si.docCount >= targetMergeDocs)
break;
mergeDocs += si.docCount;
}
if (mergeDocs >= targetMergeDocs) // found a merge to do
mergeSegments(minSegment + 1);
else
break;
targetMergeDocs *= mergeFactor; // increase target size
}
}
一看就知道，当segmentInfos中的merge的文档数小于targetMergeDocs是，系统不会进行merge,而targetMergeDocs由minMergeDocs和mergeFactor决定．SegmentInfo 如果是单个索引的话，si.docCount为1,如果此时minMergeDocs为１，也就是targetMergeDocs为１，系统会进行merge,这样在效率上回大大降低．minMergeDocs＞１的话，决定merge的大小还是minMergeDocs，targetMergeDocs *= mergeFactor无效，可以说mergeFactor只对批量索引有效，si.docCount＞１的情况．
如果是批量索引，当si.docCount＞minMergeDocs时，minMergeDocs和targetMergeDocs 决定了merge的数量．
在我的优化过程中，由于采用的是单一索引，所以我调整mergeFactor带来的性能上的差异不大，可以看成是系统带来的误差．而我改变minMergeDocs获得的性能可以从下面的数据看到：
以10000条记录为测试案例
minMergeDocs 对于运行的时间ms
default (10) times=32707
20 times=21191
30 times=18476
40 times=16334
50 times=16744
100 times=13138
200 times=10125
400 times=10234
800 times=10015
1600 times=11256
3200 out of memory
从上面的数据来看，在100~200之间性能和存储比较优．当minMergeDocs 大到一定的程度，由于在内存调度上的问题，系统可能有更大量的访问IO.建议在定制lucence时，对与单一的索引可以把minMergeDocs 设成100左右以提供性能．而车东给出的说法并不完全．
rimen[天外孤客--jerry的blog]: 关于Lucence中的索引优化
Jerry‘s blog 网络财富神话 jerry‘s blog
JavaScript模拟的物理实验！效果极酷！！！ - 一路小跑 | Jerry‘s Blog
[转]MySQL索引优化
数据库索引和海量数据查询的优化
2.Blog的搜索引擎优化
Lucence的结构 - neuron - 计世博客
Lucence的结构 - neuron - 计世博客
SQL优化之索引问题
SQL Server 索引优化应用
Yahoo! Search Blog: Jerry‘s Take On What‘s Ne...
内存管理 - 我的文章 - Jerry
【原创】关于MySQL分页的优化 - 性能优化
关于与单纯的关键词优化不同
适合做网站优化的blog程序推荐
适合做网站优化的blog程序推荐
1关于普通话水平测试中的“说话” - 戈壁 - 新浪BLOG
关于教育技术学领域中的若干关键技术 系统视角，最优化决策 系统视角，最优化决策 临兵斗者皆...
小宝关于概念图－Cmaptools的文章索引 | 长云的博客
显示数据库中的表结构(新增了索引及表的描述信息)
显示数据库中的表结构(新增了索引及表的描述信息)
sql优化之:深入浅出理解索引(系列二)
我们索引这么数据做什么用？ - 关于RSS搜索引擎发展的思考
折纸资料教程索引 - 生活中的点点滴滴