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