lucene 2.4.1 重建index测试记录

lucene 2.4.1 重建index测试记录

机器配置：

uname -a :

Linux eshequn-SV06-A11 2.6.21.5-smp #1 SMP Sun Jan 27 23:51:02 CST 2008 i686 Intel(R) Xeon(TM) CPU 3.06GHz GenuineIntel GNU/Linux

cpuinfo:

processor        : 2
model name    : Intel(R) Xeon(TM) CPU 3.06GHz

meminfo:

MemTotal:      6234308 kB

disk info:

/dev/sda1 on / type reiserfs (rw,noatime)

lucene 配置

writer = new IndexWriter(indexDir, paodingAnalyzer, true, IndexWriter.MaxFieldLength.UNLIMITED);
writer.setMaxBufferedDocs(10000);
writer.setUseCompoundFile(true);

// 说明：使用 Paoding Analysis (http://code.google.com/p/paoding/ http://www.bt285.cn   )

数据：

共 33833375 条记录，3647 个 xml 文件，xml 文件每个约4M，Total 大小：14G

最终索引文件大小：4G（说明：只有 id 字段为 store，其他字段都为 no store）

cfx 文件：629 M

cfs 文件：3.4 Ｇ

耗费时间：共花费时间 7985秒 平均每个文件 2.2秒 （其中 optimize 花费约 35 分钟 / 2100多秒）

从 log 里面计算每次选取 n 个文件（当前是10个）后写入索引所花的时间（单位为秒）以及当前的总时间：
（log  文件的第一列为 hh:mm:ss 格式的时间戳，START 为每次选取文件后特意打印的 log info）
grep START /home/data/search2/logs/search2-Index2.log |awk -F’,’ ‘{print $1}’ | awk -F’:’ ‘BEGIN{now=0;last=0;total=0}{now=$1*3600+$2*60+$3; print $0, NR, now-last; if(last > 0) total+=now-last; last=now;}END{print “total:” total ” ave: ” total/NR}’

结论：

在普通的服务器级别的配置的机器上，lucene 2.4.1 建立索引的速度，效率以及最终索引的大小，都足以支持 “亿” 级别的应用。但当记录达到 “千万” 级别以后，就需要做一些优化了：

1. 分离索引和存储。索引里只存储 id ，其他的字段只索引不存储。优点：保持索引的大小为一个可接受的范围；缺点：搜索时需要额外的请求来获取其它必须的字段（lucene ＋ db［mysql or bdb or memcache or memcachedb http://www.5a520.cn ］方案）
2. 分离写索引与读索引。优点：消除读写索引时可能因为锁干扰问题导致的索引不一致，同时保证搜索服务的可用性，和可扩展性；缺点：需要额外的读索引更新逻辑（reopen）
3. 大小库：为了保证及时更新的同时，减少索引频繁同步（由写索引同步到读索引）带来的 io 压力，可以把索引库拆分为大库（历史库），小库（最近更新库），定期合并小库的记录到大库中，降低历史库的同步频率，在不影响搜索结果的同时减少同步的 io 消耗。大部分的搜索结果都满足时间的局部性原则，即搜索结果中，最近更新的记录排前面的可能性较大。所以，可以配置这样的策略：如果小库中的搜索结果条数 已经满足要求，那么略过大库，直接返回结果给客户端，以达到加速搜索的目的。
4. 多份读索引：（未经过实践检验，正计划测试）当索引库比较大的时候，每次 reopen 都会造成短时间内的搜索请求被堵塞。可以配置成多份读索引，错开时间 reopen ，保证任何时刻都有一个可用的索引在。
5. 分词服务化：（只是一个想法，未经验证）分词的优劣对索引大小，search结果优劣影响非常大，但 lucene 中如果想更新或更换某个索引的 analyzer ，一般都需要重建索引。为了平滑升级分词算法，词典等，可以考虑将分词模块从 lucene 中分离出来，独立成 web service 服务。