Lucene/Solr Optimize相关总结

Optimize就是优化的意思。说到Optimize,其实问题回归到两个本质问题：updata-in-place/update-out-of-place、restart。

1WhenOptimize
索引update、deleted、add、update、deleted、add反反复复，致使索引“千仓百孔”、“指针琳琳散散”、“无用数据或者辅助数据增多”，最后影响相同的查询逻辑，越到后面检索性能逐渐糟糕。

2HowOptimize
总体optimize、局部optimize、混合optimize

总体optimize，就是对已经存在的索引，总体optimize下，本质就是基于原来索引进行索引重建。这个过程减小了文本IO、文本分析等开销。据经验对于一个个文本文件从磁盘建索引：建完后优化大约=1:0.6.也即基于索引构建索引二次构建时间开销大概是原来从文本构建的0.6.
这个数据规模5000w。超过5000w的可能优化比必定比原始重建省时，反而时间更长。Lucene/solr
直接由现成的接口indexWriter.optimize()，调用下就能够了。
在最新的3.4
之后，不建议使用optimize，由于这个太耗时了。因此，在接下来的优化中，会逐步优化增量机制，平衡性能和索引规模下时间开销的。

句部optimize，就是对数据先分区（多个子应用），分区下再分组（多个hash分布），二级分组。这样能够对分区内优化、分组内优化、二级组内优化。这样经过下降规模来实现性能和时间平衡。Lucene2.9.一、solr1.4以及之后版本，支持mergePolicy插件化，这样继承默认的policy，而后IndexWriter中set新的policy，就能够针对segment或多目录索引进行局部optimize。

混合optimize，就是总体和局部都执行。这种状况下，总体的频率下降，局部的频率较高。从而实现阶段性的性能最佳。例如一个月一次总体optimize，天天局部optimize，这样能够保证在性能快要出现下滑时，及时restart到最佳性能点。

3whatoptimize
索引optimize本质就是索引重建。如何最大程度大块大块利用以前的索引，将大大改进optimize性能。对应lucene默认的optimize来讲，文本读取IO、文本分析时间将免去或者这部分开销大大下降。optimize另一个本质就是restart。optimize就是业务逻辑的回归，有点相似垃圾回收后，内存有空间连续块。optimize以后，指针、存储变得更加紧蹙、高效。在lucene中mergePolicy决定对那些segment合并，或者知足什么属于的segment合并。而合并算法的本质是基于堆排序从新renew
索引。

Lucene/solr默认调参没法知足需求时，开始扩展mergePolicy，此时仍然没法知足需求，须要扣memory了。
抠memory:(1)
对象复用。对大批量、单一流向的操做来讲，重用对象将大大下降堆内存消耗，减小ygc。lucene/solr3.4以及之后版本，已经重用document、field对象，批量操做性能更好。

(2)重用待优化索引的大块对象或者大块数据，从而下降重复计算开销。这块的优化涉及lucene合并算法。
重度复用的话，须要定作一些数据结构，例如，postlist的块独立化。这方面能够参考“wangsou”，详情不变透露！
(3)调整基础cache大小，作到与ospagecache同步或者改变os
pagecache策略。这个问题属于定制index下的os，除了google、baidu、sousou、sogou等大牛已经执行了，其余公司因为业务特性，都不多去优化os这一层。

4notice
(1)第一次文本建索引属于IO、CPU密集性应用，Optimize上IO密度下降、CPU密度提高。Optimize过程当中IO次数尽管少了，memory消耗增多，可是关联的文件数据大小更大。须要平衡大文件颠簸Memory和DISK开销。

(2)Mutithread多路归并，须要较好的硬件支持。(3)尽可能不要动用optimize，从业务上着手优化性能