lucene/solr的缺點

lucene/solr的缺點 solrlucenehadoop&HTTP://www.aliyun.com/zixun/aggregation/37954.html">nbsp; 1) HTTP 請求做了cache，8630.html">有時候會出現新資料不可見，cache滯後的問題。 —cache優化下也不是問題


2) admin 後臺頁面，支援中文、複雜查詢語法上，欠友好。 —自己稍加擴展也不是問題


3) swap core的時候，單結點多core，並且core對應的索引比較大的時候，切換過程出現記憶體2倍化現象，甚至超時現象。 —如果分前後排切換這些都不是問題了。


4) index build和index search往往在一起，導致全量過程，磁片峰值3倍化。 一份原來的、一份新建的、一份優化的時候。 —-當然，build和search分離是可以解決這個問題的，也是常規做法。


5) build 和search在一起，也使得build和search的一些參數設置不能區別對待，尤其是build和search合體的時候，預留磁片、記憶體等加速build，反而影響search。 —-當然可以 build search分離搞定


6) 分散式查詢，如果有merge，性能有些問題。 —-當然可以將資料分區，避免merge 7) 得分因數是可以調整的，但是得分因數的增加、得分公式的擴展，無法直接從solr配置插入。 —-但是，可以擴展lucene的代碼或者參數spanquery，重新一個query，插入solr，這樣工作量稍大.另外，社區提供了bm25、pagerank等排序batch，對lucene有所以瞭解後，就可以直接引用了。


8) solr分散式索引全量、增量控制細微性，尚不夠友好。 指定結點、任何時刻全量，指定條件下增量都不夠順利。 儘管solr提供了自訂擴展實現方法。 這些也不是很大問題。


9) solr build和search和在一起，資料和業務其實綁定在一起了，沒有徹底隔離。 使得在上100個core的時候，資料來源管理維護變得非常消耗資源。 直接引入hadoop或者其他nosql存儲時目前最流行的用來隔離資料和業務耦合性了。 開源的分散式lucene方案非常多.


10) ABTest 共用相同索引目錄，而不同排序或者不同分詞 solr不能直接支援 11) ABTest 獨立索引目錄，不同排序或者不同分詞，solr也不能直接支援


12) 一個core對應多個子目錄，查詢既可以查指定子目錄也可以全部子目錄查，以及更新某個子目錄索引或者全部子目錄索引，solr也不能直接支援，而這些在大資料量的時候是需要支援這些功能的。


13)solr或者lucene目前不支援快速的「局部」更新。 這裡是指對document的某個欄位的快速更新，目前是需要傳入完整的document，然後add進去。 如果document的不變欄位來源多個源的話，IO、計算資源有些浪費，如果更新量不大還好。 —當然可以對更新的單獨開闢記憶體來處理，而更大的那個基本索引不去動他。


14)solr不支援協力廠商條件過濾。 例如從倒排中過濾處理一批doc，而這些doc需要與外部源進行doc域值過濾。 問題主要是協力廠商資訊動態性太強，不利於直接寫索引中去。


15）solr 在支援中文分詞的時候，有很多協力廠商包可以引入，但需要擴展queryparse有時候，總體看有優勢也有劣勢。 優勢是引入方便，劣勢是詞庫、演算法體系和lucene的不完全相容，擴展、完善不是那麼容易。


16)在排序上，對與去重或者對應基於時間動態性上，還沒有現成的支援。 去重是指排序的前幾條結果，可能某個域值完全相同了，或者某幾個域值完全相同，導致看起來，靠前的結果帶有一些關聯欄位的「聚集性」，對有些應用來說，並不是最好的。


在時間因素上動態性，也沒有直接支援，也只能靠間接的按時間排序來實現。 這個問題其實不是lucene、solr要關注的吧，應該是應用的特殊性導致的吧。


17) solr、lucene輸出的日誌，尚沒有一個通用的分析工具，包括高頻詞、查詢query聚合性等。 只能自行去解析。


18) 在支援推薦上，還不能將log資訊直接關聯起來，推薦也基本上靠離線計算好，導入倒排索引，查詢再關聯起來。


19) 當記憶體30個G 以上，單節點索引資料量比較大的時候，jvm環境下FGC和記憶體管理顯得非常辣手。 調優需要仔細的測試


20) lucene很少面向介面，solr很多面向介面，外掛程式化、可擴展使得solr很靈活


21)對於垂直型的平臺化搜索，支援N個不同應用、不同schema、不同資料來源、不同更新頻率、不同查詢邏輯、不同訪問請求量、不同性能指標要求、不同機器配置、垂直擴容、水準擴容，solr顯得不夠勝任， 儘管solrcloud中已經有非常多的寶貴設計經驗。


22)流控和數控，solr也不能直接支援。 訪問請求不支援定時和定量控制，索引垂直擴容（增加索引副本，支撐更多訪問請求）、索引水準擴容（增加索引分區數，支撐更多資料量，平衡性能和空間壓力）


23) solr自容錯還不夠強大。 例如schema變更導致的不合理檢測以及配置錯誤的回滾、solrconfig的一些參數不能動態獲取，必須事先配置好。 oom之後不能自動reload！ 請求量大的時候也不能拋棄一些請求。


24) 基於位操作的高級應用還不夠靈活，例如boolean 存儲和facet、byte[]存儲和facet、group等，支撐仍然不夠友好。


25) query parse基本沒有預測功能，不能調整query順序和自動收縮條件。 當然一般情況下是不需要這麼複雜的優化。


26）一些比較變態的查詢需求不是特別高效。 例如查詢某個域不空。 當然可以將空域採取預設值代替，查詢預設值再過濾。


27)對於唯一值域，沒有優化，導致唯一值域的term資料膨脹。 最常見的就是更新時間、上傳時間等，占了非常大的term比例。


28)multivalue 欄位，實質是建立多個相同功能變數名稱的欄位，並不是一個域。 對於域值很多內容的話，只好和在一起保存。 同時，long int short float double 等陣列不能直接作為一個類型保存，全部得轉為字元存儲。 空間和效率有些低。


29)有些詞出現的頻率特別高，導致該詞的倒排連非常長，solr、lucene也沒有干涉。 任務交給應用自己斟酌，實際上solr單節點對於命中超過100w的，並多欄位排序的時候，cache失效時性能非常糟糕的。


30)solr\lucene 對千萬級別應用非常擅長，億級別應用需要慎重對待。