目前全量索引17G,不到1300万document花费大约25分钟的时间(Lucene 4.0)，吞吐量远远低于lucene nightly build宣称的170G/h的量。换用StandardAnalyzer,有34%的提高，比较下使用的KAnalyzer,mmseg4j1.9.2-snapshot,standardanalyzer,性能分别在1.7M/s,10M/s,20M/s这样量级。所以认为如果分词性能有明显提高,索引速度应该会有加快。

分析了下目前使用的KAnalyzer,它同时执行正向最大匹配和反向最大匹配，取概率最大那个(1-gram累计词频),如果有歧义/交集的三元组，用概率算第三种分词方式，如果最高，当然选用第三种分词方式。

感觉起来效率不太高，因为有三次匹配,我会尝试如下动作:

1)分别测试只使用最大正向和最大反向的性能,有个直观感觉，再建索引看看性能;

2)mmseg同样是启发式的,但只做一次匹配，孰优孰劣,还要看准确率，召回率,必须通过的测试是否都通过,这一套标准需要建立起来

3)算法是一方面,词典质量更重要,算法方面性能，准确率,召回率各个方面做个tradeoff就可以。

4)对于"南京西路",想保留"南京|西|路",感觉建个额外字典,某些词必须拆掉就可以了。

5)里面的概率全部改用ln(freq),累计频率全部使用加法,提高效率,少用string,看看能否用bytesref,按句子分，不要按整块文本分。diffrate = Max / (Min + 1)看起来有点费解...

6)最大匹配里面放进去的匹配规则要揪出来,要看看mmseg4j的实现。

最后想说理论上viterbi算法分词准确率最优,只是性能太差了..

另外补充个,geo目前按多级(15级)索引，可能是导致索引慢的原因。还有从csv文本到ReusableDocument的反序列化过程也可能拖慢索引速度。