关于Lucene实时更新的尝试（续一）
先明确一下各种格式文件的概念
|
Name |
Extension |
Brief Description |
|
segments.gen, segments_N |
Stores information about segments | |
|
.cfs |
An optional "virtual" file consisting of all the other index files for systems that frequently run out of file handles. |
Compound Files
Starting with Lucene 1.4 the compound file format became default. This is simply a container for all files described in the next section (except for the .del file).
Compound (.cfs) --> FileCount, <DataOffset, FileName> FileCount , FileData FileCount
FileCount --> VInt
DataOffset --> Long
FileName --> String
FileData --> raw file data
The raw file data is the data from the individual files named above.
Starting with Lucene 2.3, doc store files (stored field values and term vectors) can be shared in a single set of files for more than one segment. When compound file is enabled, these shared files will be added into a single compound file (same format as above) but with the extension .cfx.
索引在创建时会有很多临时文件，如fdt,fdx,fdm等（具体参见《Apache Lucene - Index File Formats 》http://lucene.apache.org/java/2_3_2/fileformats.html ），上述文件共同组成索引片段Segment，IndexWriter工作时，会合并多个Segment文件到一个文件中，这个文件就是.cfs文件。合并Segments的好处是减少索引文件的数量，也就减少了检索过程中需要打开的文件的数量（据说有的系统会限制打开文件的数量，“据说而已，没有亲见”，但是想象中打开文件太多也不是好事，毕竟占用的句柄在哪摆着呢）。
从上述描述还可以看出，从2.3版本开始，存储field values和term vectors的文档存储文件被存储为一个单独的复合文件，以被多个segment共享，这个文件格式不变，但是扩展名变成了.cfx。
可以得到一个结论就是：索引片段越趋于松散，检索的效率将越低。
实时更新的前提是维持检索本身的效率，而影响检索的效率的因素又包括cfs文件的数量，同时仅仅更新索引却不Optimize却势必要导致新的零散的cfs文件的不断出现，这样得就要明确一个参数，那就是新索引出现的频率是多少。假设1天1w条新数据要补充进，那么三个月就是90w条，如果每1000个文档生成一个cfs文件，那么三个月后就将累积900个索引碎片。
应该以多大的频率来Optimize索引？目前手头没有合适的样例数据，晚上回去测试一下，得到一个可视化的数据，先来佐证一下索引片段过多会对效率有多大的损耗再说吧。
to be continue...
