本帖最后由 nettman 于 2014-2-28 22:46 編輯 可以帶著(zhù)下面問(wèn)題來(lái)閱讀：
1.搜索為什么使用solr？
2.一個(gè)索引越來(lái)越大，solr是如何應對的？
3.Solr是什么，一句話(huà)描述？
4.solr比Lucene有什么優(yōu)勢？
一、Lucene與solr有什么不一樣首先Solr是基于Lucene做的，Lucene是一套信息檢索工具包，但并不包含搜索引擎系統，它包含了索引結構、讀寫(xiě)索引工具、相關(guān)性工具、排序等功能，因此在使用Lucene時(shí)你仍需要關(guān)注搜索引擎系統，例如數據獲取、解析、分詞等方面的東西。
而Solr的目標是打造一款企業(yè)級的搜索引擎系統，因此它更接近于我們認識到的搜索引擎系統，它是一個(gè)搜索引擎服務(wù)，通過(guò)各種API可以讓你的應用使用搜索服務(wù)，而不需要將搜索邏輯耦合在應用中。而且Solr可以根據配置文件定義數據解析的方式，更像是一個(gè)搜索框架，它也支持主從、熱換庫等操作。還添加了飄紅、facet等搜索引擎常見(jiàn)功能的支持。
因而，Lucene使用上更加靈活，但是你需要自己處理搜素引擎系統架構，以及其他附加附加功能的實(shí)現。而Solr幫你做了更多，但是是一個(gè)處于高層的框架，Lucene很多新特性不能及時(shí)向上透傳，所以有時(shí)候可能發(fā)現需要一個(gè)功能，Lucene是支持的，但是Solr上已經(jīng)看不到相關(guān)接口。
Lucene更像是一個(gè)SDK。 有完整的API族以及對應的實(shí)現。你可以利用這些在自己的應用里實(shí)現高級查詢(xún)（基于倒排索引技術(shù)的），Lucene對單機或者桌面應用很實(shí)用很方便。但是Lucene，需要開(kāi)發(fā)者自己維護索引文件，在多機環(huán)境中備份同步索引文件很是麻煩。于是，就有了Solr。
而Solr是一個(gè)有HTTP接口的基于Lucene的查詢(xún)服務(wù)器，封裝了很多Lucene細節。
solr ,更多是和nutch 的結合使用
-----------------------------------------------------------------------------------------------------------------------------------------------
二、solr 的結構分析solr在lucene外邊做了一層厚厚的封裝，主要是為了簡(jiǎn)化二次開(kāi)發(fā)，提供了一些成熟的解決方案。
solr和solrCore
solr可以對多個(gè)core進(jìn)行綜合管理，并接受請求選擇特定的一個(gè)或者多個(gè)core執行相關(guān)任務(wù)。下面來(lái)回答什么是solr的core。
core從文件結構的角度來(lái)看的話(huà)，主要包括一份索引（也可能還包括拼寫(xiě)檢查的索引）、一堆配置文件。最主要的配置文件是：solrconfig.xml和schema.xml。solrconfig.xml從整體上對core進(jìn)行了配置，例如索引的存放路徑、字段的最大長(cháng)度（maxFiedlLength）、寫(xiě)鎖的超時(shí)時(shí)間（writeLockTimeout）、鎖類(lèi)型（lockType）、是否壓縮索引（useCompoundFile）、內存索引緩沖區大?。╮amBufferSizeMB）、合并因子（mergeFactor）、刪除策略、自動(dòng)提交策略、緩存設置等，它好比是一份組裝機器人的說(shuō)明書(shū)，里面詳細描述了各個(gè)部件（handler）的參數。schema.xml主要是對索引的配置，例如分詞器、字段名稱(chēng)+索引方法+存儲方式+分詞方式、唯一標識字段等，它好比是機器人學(xué)習的學(xué)習方法，機器人主動(dòng)或被動(dòng)接受特定數據，按照配置轉化成索引，然后通過(guò)其部件（handler）展示出來(lái)，例如：search、moreLikeThis、spellCheck、factedSearcher等。
core從功能方面來(lái)說(shuō)的話(huà)，主要是通過(guò)各種handler進(jìn)行工作，這個(gè)在上文中也提及過(guò)。solr的功能之多讓我想到瑞士軍刀，看圖：
常見(jiàn)的有：morelikeThis、search、 spellCheck、dataImport等。
然而不同的部件有復雜簡(jiǎn)易之分，我們常見(jiàn)的searchHandler就比較復雜，他包括多個(gè)零件（component）。
多個(gè)component進(jìn)行組合就可以完成特定的工作。（以下代碼摘自：SearchHandler.java）
- for( SearchComponent c : components ) {
- rb.setTimer( subt.sub( c.getName() ) );
- c.process(rb);
- rb.getTimer().stop();
- }
以上文字主要簡(jiǎn)單白話(huà)了solr的core是個(gè)什么東西！那么solr怎么控制這些core進(jìn)行工作呢？
這個(gè)是檢索的目的是：檢索core1下的所有內容，并返回前10條。
solr通過(guò)request獲取requestPath，解析出對應的core名稱(chēng)（這里coreName=core1），然后獲取core實(shí)例（找到相應的機器人）。
然后解析出select指令，明確告訴core是進(jìn)行檢索任務(wù)，任務(wù)的具體參數通過(guò)solrRequestParser進(jìn)行解析。solrRequestParser可以看出是將url轉換成core識別指令的“翻譯器”。下面core就可以調用相應的handler執行任務(wù)了。
從外往里看，solr可以看成是：
solr Manager -> solr core -> handler -> component
簡(jiǎn)單說(shuō)說(shuō)solr的分布式（version：solr3.5）
當一個(gè)索引越來(lái)越大，一個(gè)服務(wù)器放不下了，怎么辦？
當一個(gè)大索引的單次請求慢得想死，怎么辦？
選擇分布式吧！他能將索引進(jìn)行切分放到不同的服務(wù)器上（shards），還可以將處理的計算壓力進(jìn)行分攤。他會(huì )將各個(gè)shard上的結果進(jìn)行合并，并“完美”的呈現給您！
然而、但是......solr的分布式并不完美。最主要的就是idf的計算問(wèn)題。這個(gè)問(wèn)題會(huì )在單個(gè)shard進(jìn)行打分運算過(guò)程中就發(fā)生了，如果每個(gè)shard在計算過(guò)程中實(shí)時(shí)去其他shards去獲取df和文檔總數，請求的消耗是不能忍受的。要解決這個(gè)問(wèn)題就得在每個(gè)shard中實(shí)時(shí)保存每個(gè)單詞的df和文檔總數。
簡(jiǎn)單說(shuō)說(shuō)solr的服務(wù)發(fā)布方式和客戶(hù)端solr
solr部署在服務(wù)器上，提供各種服務(wù)。服務(wù)發(fā)布的方式主要是基于http協(xié)議的，傳輸數據格式為xml、json，不同開(kāi)發(fā)語(yǔ)言都可以通過(guò)socket編程進(jìn)行訪(fǎng)問(wèn)。官方的java客戶(hù)端就是solrJ，他利用HttpClient進(jìn)行客戶(hù)端開(kāi)發(fā)。
我曾經(jīng)毫無(wú)理由的懷疑過(guò)這種方式——如果我要用標準的webService，然后又不想改動(dòng)太多源碼，是不是還得通過(guò)slorJ做個(gè)中間橋梁？是不是無(wú)緣無(wú)故的多了一次http請求？雖然有embedded！感覺(jué)就是solr的這層服務(wù)接口被http侵入得有點(diǎn)深。深入的研究后續跟進(jìn)= =。
為什么solr沒(méi)有multiSearcher？
lucene3.5中的multiSearcher已經(jīng)過(guò)時(shí)了，取而代之的是multiReader。
If you are using MultiSearcher over IndexSearchers, please use MultiReader instead; this class does not properly handle certain kinds of queries.
從lucene早起版本開(kāi)始，或者說(shuō)是受數據庫思想的影響，會(huì )將數據按照某一性質(zhì)進(jìn)行劃分，放到不同的索引里面。理由是便于管理、防止單一索引過(guò)大。如果需要同時(shí)檢索多個(gè)索引，自然就用到了multiSearcher。到了solr發(fā)現一個(gè)core中只能一份索引，于是糾結solr為什么沒(méi)有multiSearcher？難道solr不擔心單一索引過(guò)大嗎？難道同時(shí)檢索多個(gè)索引就得使用它并不完善的distributedSearch嗎？當時(shí)這個(gè)思想一直影響了我對solr的好感。
現在“改革開(kāi)發(fā)”的思想就是：在業(yè)務(wù)需求下，不支持對多個(gè)索引同時(shí)進(jìn)行檢索。當單個(gè)索引的檢索壓力出現效率問(wèn)題后，再考慮分布式檢索，將數據分發(fā)到不同的shards上。如果不是單次檢索的運算量瓶頸，而是并發(fā)量帶來(lái)的壓力，考慮使用負載均衡。這里很類(lèi)似于mongodb，并發(fā)壓力大作replSet，單庫太大做sharding。
