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，從業務上着手優化性能