Solr，Lucene 優化有哪些相關經驗可分享？
大家有沒有Solr，Lucene優化的相關經驗，可以分享一下，特別是在JDK64的環境，索引文件超過30G的情況。
倒是沒有太多的經驗， 不過最近著手做這方面的東西， 希望能討論討論：
你的索引文件30G！這可是個非常大的數目了。1. 從schema入手：1&> 你的數據是都需要store的么， 比如一些欄位只需要提供結果搜索而不作為結果返回， 那麼需要將store設置為false從而減少數據量。2&> 你的所有欄位都需要highlight么， 如果不需要highlight則可以將term vector關掉。
3&> 確認你在schema沒保存太多無用的信息（即不用來搜索也不用來返回）。4&> 你的分詞演算法是否合理， 如果你使用的是ngram的分詞方法， 可以通過設置最大和最小分詞長度來限制分詞數據。5&> 你的業務上是否有明顯的條目信息， 比如你索引的東西是一本書， 很多其他的信息在mysql或者其他地方有副本， 這樣的話， 你大可以只store id信息， 其他欄位都不store。6&> 你的業務能不能拆分， 比如之前書影音一起做搜索， 你可以考慮將他們分開。2. 從segment角度
1&> lucence使用segment來保存索引數據， 可以在Solr中通過mergeFactor來指定需要的臨時文件數目， 如果mergeFactor過大， 則index的時間會縮短， 但磁碟佔用和搜索時間會變的很長， 可以考慮適當調整mergeFactor， 或者在slave上做定期的optimize操作， optimize會將segment合併到一起， 當然， 這個過程比較耗資源， 所以可以考慮optimize的時候指定要merge到的數據。2&> 同樣， 在master ， slave環境中， 最好不要在master上做optimize， 因為在master上做optimize會導致slave每次複製整個index的數據， 這當然不是你想要的， 所以要採取措施不要讓master和slave的配置一樣， 這樣很不划算。3. 從shard上
更一般的情況是， 如果這些都不是你想要的， 可以考慮shard， Solr支持很靈活的Shard， 你可以在build index的時候給出規則讓不同的數據發送到不同的伺服器， 比如同過hash等。 這樣你的大數據就可以分布在多個機器中， 提高處理速度， 當然， 如果你有性能較好的機器， 同樣可以考慮在單一機器上做shard， 利用多核的處理性能。但是要謹慎Solr的一些特性在Shard環境中的支持情況。4. JDK
1&> JDK 的版本， 建議使用最新的版本， 但是7貌似有bug， 看有沒有7.1， 32 vs 64 對java沒影響， 都是byte code ，不區分。2&> 可以通過制定Xmx Xms 參數調整heap 的大小， 如果你經常出現heap over flow的話。3&> 啟用多線程gc， 這是你在處理大數據時避免溢出的好方法， 一般一個core一個gc線程。5. 設置適當的cache， 根據cache命中率的不同來選擇fastlru or lru。
這裡網上有個叫做chenlb的人以前在1.4中做了一個patch， 可以使用memcache做solr的cache， 不過現在的3.5版本不兼容， 作者也沒有對其更新， 如果你在分散式環境下， 可以考慮自己做一下這個， 弄好了可以分享給筆者。6. 根據使用的不同， 優化方式也非常的多， 不再贅述。
感謝lucence， solr的作者和開源共享著們！可以瀏覽一下我們專欄的文章，正好有關於Solr和lucene的。希望可以給你一些啟發。
作者：ElaineQ
鏈接：Lucene 或者 solr 有什麼不一樣？ 分別何時使用？ - ElaineQ 的回答
來源：知乎著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。頁的爬蟲。但是由於solr的開源性質，你可以在solr上添加一些模塊來擴展功能。
Searching engine architecture
amp;
https://pic4.zhimg.com/49abb8c4f66a66a2db7c36340e59a623_b.png&" dw="1322" dh="778" w="1322" data-original="&https://pic4.zhimg.com/49abb8c4f66a66a2db7c36340e59a623_r.png" data-editable="true" data-title="zhimg.com 的頁面">https://pic4.zhimg.com/49abb8c4f66a66a2db7c36340e59a623_r.png&"amp;>這是一個極為簡化的搜索引擎結構圖。以index--data store為軸，左邊的部分為offline 索引的部分 ，右邊是online retrieval，ranking的部分
如果你有一個文檔，那麼通過 text acquisition 把這些文檔爬過來，存儲在index里，存儲的過程叫indexing，indexing做的是倒排表的工作：把這個文檔按照詞拆開（而是按照「詞」。詞的定義在英語等大多數語言中就是空格分割的單詞，而在中日韓泰等語言中則需要「句讀」，也就是「分詞」來確定。），把每個詞進行正則 化之後，把詞作為關鍵詞 ，做一個倒的排表。這就類似於字典後面的索引。通俗的理解就是拿詞在表裡匹配。
除了把文檔拆開，還要把文檔原樣存儲下來，用於文檔重構。
用戶通過user interface進來，以谷歌為例：搜索框type關鍵詞。進入query understanding模塊進行對關鍵詞的理解 ， 這一部分做得非常豐富 ：同義詞匹配，進行stemming（單複數，時態，如果只剩詞幹 可以match的更好）。
接下來分為兩步： 第一步, 把經過標註和理解的關鍵詞進入index倒排表去,找到需要的所有文檔。 第二步, 對文檔進行ranking，然後把ranking之後的結果呈現出來。 amp;
https://pic2.zhimg.com/e724a2c61f9783e6c47850b81c05f6b5_b.png&" dw="1318" dh="778" w="1318" data-original="&https://pic2.zhimg.com/e724a2c61f9783e6c47850b81c05f6b5_r.png" data-editable="true" data-title="zhimg.com 的頁面">https://pic2.zhimg.com/e724a2c61f9783e6c47850b81c05f6b5_r.png&"amp;>以上是google和solr在搜索引擎架構上的區別。上文提到，solr沒有爬蟲的功能，所以沒有text acqusition。
https://pic2.zhimg.com/ec1886b7ed0cd25d7b55a7bf2939f6cd_b.png&" dw="1324" dh="498" w="1324" data-original="&https://pic2.zhimg.com/ec1886b7ed0cd25d7b55a7bf2939f6cd_r.png" data-editable="true" data-title="zhimg.com 的頁面">https://pic2.zhimg.com/ec1886b7ed0cd25d7b55a7bf2939f6cd_r.png&"amp;>很多人對google的搜索感到很神奇，我們可以把google搜索的黑盒子簡單的拆成兩步
Step one ：retrieval round ： binary retrieval ，用關鍵字到google的所有文檔列表去找 ，分出想要的和不想要的文檔 （是否 match），把文檔集合一分為二。
Step two： scoring round ： 計算document的價值，然後按評值呈現出來。因為scoring是一件比較昂貴的事情，在一個比較小的子集會比較好。
amp;
https://pic3.zhimg.com/62e92fbd86e3c3e0f7f96124d28998e2_b.png&" dw="1338" dh="778" w="1338" data-original="&https://pic3.zhimg.com/62e92fbd86e3c3e0f7f96124d28998e2_r.png" data-editable="true" data-title="zhimg.com 的頁面">https://pic3.zhimg.com/62e92fbd86e3c3e0f7f96124d28998e2_r.png&"amp;>
如果你能讀懂這兩個文檔，以人類的理解是 A 更符合我們的user intern。但是對於 計算機來說 B match 的更好，因為在B中 red .sofa.picture這三個詞都匹配到了。所以 我們要設計演算法，來提高計算機的搜索能力。
amp;
https://pic4.zhimg.com/65c0ca51fbc9c1b0143de0214dbfa647_b.png&" dw="1118" dh="760" w="1118" data-original="&https://pic4.zhimg.com/65c0ca51fbc9c1b0143de0214dbfa647_r.png" data-editable="true" data-title="zhimg.com 的頁面">https://pic4.zhimg.com/65c0ca51fbc9c1b0143de0214dbfa647_r.png&"amp;>
在這個query中，我們可以人為的理解sofa是topic，red是description ，picture是intern 。所以topic一定要選對，其次是description。並且 intent幾乎是沒有用的。stopwords, generic words, specific words: 三種詞重要性依次遞增。
amp;
https://pic3.zhimg.com/de64a20705bee0266e9328edff6a8ae6_b.png&" dw="1320" dh="844" w="1320" data-original="&https://pic3.zhimg.com/de64a20705bee0266e9328edff6a8ae6_r.png" data-editable="true" data-title="zhimg.com 的頁面">https://pic3.zhimg.com/de64a20705bee0266e9328edff6a8ae6_r.png&"amp;>
在 Document A 中，red和reddish其實是一個意思，sofa和couch是一個詞的兩種不同表達方式。
我們還可以發現，在Document A 中red和sofa比較近，而Document B中的距離相對較遠遠。對於我們的query來說，關鍵詞越近越好 。這裡就可以在scoring上進行一定的獎勵。amp;
https://pic4.zhimg.com/45bb23c3f2a9382c3a85ecca6cd9497b_b.png&" dw="1306" dh="796" w="1306" data-original="&https://pic4.zhimg.com/45bb23c3f2a9382c3a85ecca6cd9497b_r.png" data-editable="true" data-title="zhimg.com 的頁面">https://pic4.zhimg.com/45bb23c3f2a9382c3a85ecca6cd9497b_r.png&"amp;>
重要的事情我一般不說，說的話就說三遍。。。。。其實我還可能說十遍。。。。。
我們在文章中可以發現，如果作者很想強調一件事情，他會不停地說，說的次數very多的時候，可能會very重要，但是說的次數very very多的時候，可能沒有very very那麼重要了。十遍比三遍說了三點三倍，但是重要性沒有三點三倍。
在這件事我們也有數學方法上的衡量。對於搜索引擎關鍵詞命中的次數越多越好，但是命中的次數特別多，函數就會趨於飽和。
模型：邊際效應曲線。一開始增長的比較快，但是隨著關鍵詞命中的數量增長，曲線增長的就比較緩慢了
小編：這件事情其實叫keyword stuffing： 在網頁中大量堆砌關鍵詞，希望提高關鍵詞密度，提高網頁針對關鍵詞的相關度。在seo層面是有效的，但是搜索引擎會發現你的惡意填充關鍵詞。。。。甚至影響排名。。。。。所以下次我不會堆那麼多了。。。。
amp;
https://pic1.zhimg.com/3aaaacc35bc45a83fee7abc38428fb9c_b.png&" dw="1332" dh="748" w="1332" data-original="&https://pic1.zhimg.com/3aaaacc35bc45a83fee7abc38428fb9c_r.png" data-editable="true" data-title="zhimg.com 的頁面">https://pic1.zhimg.com/3aaaacc35bc45a83fee7abc38428fb9c_r.png&"amp;>
還有可能你很難抓取關鍵詞：mis-spelled words,foregn words , different corpus.
amp;
https://pic2.zhimg.com/4040ccfa9d69403c06a7b5a224a361b1_b.png&" dw="1322" dh="698" w="1322" data-original="&https://pic2.zhimg.com/4040ccfa9d69403c06a7b5a224a361b1_r.png" data-editable="true" data-title="zhimg.com 的頁面">https://pic2.zhimg.com/4040ccfa9d69403c06a7b5a224a361b1_r.png&"amp;>
經過我們的觀察Document B 能直接回答我們的問題。但是從數學以及我們上述的角度觀察應該是第一個好。 在 A中 ，walmart說了很多遍 ，加分。關鍵詞離得也比較近，加分。那怎樣設計scoring來讓Document B的評值更高呢？
所以引入一些新的東西 ： term balance ， 在document中的每個關鍵詞相對於query出現次數差不多最好。
amp;
https://pic2.zhimg.com/7f4cc77b651264223a0b021a5b4f7c21_b.png&" dw="1118" dh="788" w="1118" data-original="&https://pic2.zhimg.com/7f4cc77b651264223a0b021a5b4f7c21_r.png" data-editable="true" data-title="zhimg.com 的頁面">https://pic2.zhimg.com/7f4cc77b651264223a0b021a5b4f7c21_r.png&"amp;>
1 並不是每個詞都很重要 詞和詞是有差別的
2 詞有不同的說法3 詞做一定的加分4 TF/IDF 評估詞的重要性5 不要特別傾向於topic而忽略了平衡性進階
1 ：spelling ：correct輸入的錯詞，這項工作不是用一個字典可以解決， 每個國家每年都有都會產生大量的新詞 。所以我們在不斷的訓練過程 把新的語料吸收進來。 就需要增加新的訓練集，淘汰舊的訓練集。2 ：我們要搜索的內容，最好的搜索結果不一定在文字上呈現。 可能是一本書， 也可能是一個youtube視頻。我們可以讓搜索引擎垂直的理解了在語料庫里最好的內容 。並且水平的交叉進來。3 ：數據量非常大的時候 ，到谷歌那個層次，就需要做多層的ranking來更好的理解query本文整理作者：張花生，查看完整講座視頻：http://www.bittiger.io/classes更多內容，請訪問：BitTiger.io， 掃描下面二維碼，關注微信公眾賬號「論碼農的自我修養」amp;
https://pic1.zhimg.com/e262b962a09ee6afd6a32fc9bc02f754_b.jpg&" dw="258" dh="258" w="258"amp;>
補充一點, Lucene 4.0 加入了 Doc Values 替換原本的Field cache. 可能開始的時候並沒有原來的Field cache 快，但是是更加scalable 的辦法。
數據規模一大，關鍵問題是GC這是官網的資料：SolrPerformanceFactors
具體要看你要優化什麼，看題主好像對solr不是特別熟悉，可以找個大牛指點下。
招個大牛省的自己搞了
你的所有欄位都需要highlight么， 如果不需要highlight則可以將term vector關掉。 這裡面的道理是什麼？能講講么？
推薦閱讀：