最早lucene2.4以及以前，追溯到2008年前后，lucene剛剛引起大家的關注，到后來Nutch
、solr的出現，lucene變得更加熱。Nutch、Solr的發展，極大推動了lucene的升級。
對於一些接觸過搜索，使用過lucene、solr的人來說，一般都會感覺lucene、solr很牛逼。我個人也認為solr、lucene確實非常NB，他涵蓋了信息檢索的幾乎全部基礎知識和非常高性能的實現方式。從solr的結構，擴展、維護整體看，發現有非常多的“工程亮點”，熟讀solr定會增加對java的理解、運用技能。
但是，其實lucene solr有其自身的一些局限性，而這些局限性在大數據量的時候顯得更為明顯。
早些時候 Cedric Champeau 的評論
http://www.jroller.com/melix/entry/why_lucene_isn_t_that 和對應的中文版
http://www.jroller.com/melix/entry/why_lucene_isn_t_that
這個評論是在當時情況下給出的，截止2012.6.13日，有些問題已經在solr、nutch或者其他基於solr、hadoop、hbase、cassandra等系統上得到完善和運用。
下面結合實踐經驗，匯總一些solr\lucene
在使用過程中的一些“短板”，之所以說是短板，因為只在有些情況下，才成為問題，有些情況下並不是問題。最后列舉一些lucene、solr中對信息檢索基礎知識的支持和實現。
solr\lucene 最大優勢：
低成本、快速上手、開源社區發達，有問題基本上有現成的解決方法。
但是，也正因為如此，熟悉了solr、lucene並不能說一定可以應對任何搜索需求。因為實際場景中，有許多千奇百怪的需求、問題，往往需要面對的是用最小的改動、最方便的形式滿足需求，而不是，是否滿足以及多久滿足的問題，要的是簡單、可靠、可控、快速接入、快速處理故障。
最后匯聚成為“檢索質量”，而這個標准是很難形成和取得相應口碑的。經驗成為了搜索中的重要財富，而solr、lucene原理、源碼只是一種最為基礎和最為不可缺失的工具。理解了這些，是可以復制一個solr、lucene的，但是無法復制solr、lucene已經形成的開源經驗、應用經驗、討論氛圍等。
solr\lucene 短板
短板越多，反應solr、lucene已經支持的場景非常多，提供服務的功能非常強大。所謂的短板，完全可以成為solr、lucene在生成環境中的應用特殊性所在、亮點所在。
(1) http 請求做了cache，有時候會出現新數據不可見，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 在支持中文分詞的時候，有很多第三方包可以引入，但需要擴展query
parse有時候，總體看有優勢也有劣勢。優勢是引入方便，劣勢是詞庫、算法體系和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 對於千萬級別應用非常擅長，億級別應用需要慎重對待。
lucene在信息檢索基礎理論的闡釋：
(1) dictionary 和 postling 分離
(2) dictionary 壓縮：基於詞典、跳躍、前綴壓縮、二分查找
(3) postling 壓縮：差值壓縮、可變字節壓縮、p4del、simle9、simple16、跳躍表
(4) tf\idf 默認實現、pagerank、 bm25等第三方實現支持
(5) 索引分段 segment、全量索引、增量索引、update-out-of-place、合並策略
(6) 查詢多目錄、查詢分布式
(7) filter 過濾，bitmap的使用
(8) 各種cache的配置和使用以及監控
(9) 各種插件化支持、擴展靈活
(10) query 的and 與 or以及組合
(11) Top 、翻頁、高亮、統計、分組的支持
(12) 模糊查詢、區間查詢、坡度查詢統統支持
(13) 默認排序、自定義自段值排序、聯合排序、動態排序、靜態排序、queryboot、indexboot 一並支持