Solr In Action 中文版 第一章 (二)

1. 1.1              Solr究竟是什麼？

在本節中，咱們經過從頭設計一個搜索應用來介紹Solr的關鍵組件。這個過程將有助於你理解Solr的功能，以及設計這些功能的初衷。不過在咱們開始介紹Solr的功能特性以前，仍是要先澄清一下Solr並不具備的一些性質：

1）  Solr並非一個像Google或是Bing那樣的web搜索引擎

2）  Solr和網站優化中常常提到的搜索引擎SEO優化沒有任何關係

好了，如今假設咱們準備爲潛在的購房客戶設計一個不動產搜索的網絡應用。該應用的核心用例場景是經過網頁瀏覽器來搜索全美國範圍內的房子。圖1.1描述了這個虛擬應用的界面截圖。不用太在乎UI界面的簡陋，這只是一個便於咱們討論的可視化模型。重點是經過這個例子，咱們來看看Solr到底能夠提供哪些類型的搜索體驗。

         讓咱們先快速瀏覽一下圖1.1描繪了哪些Solr的關鍵特性。咱們從左上角開始，沿順時針方向看。首先，Solr提供了強大的功能來支持關鍵字搜索框。正如咱們在1.1.2中討論的那樣，一個表現出色的關鍵字搜索功能，須要背後強大的複雜架構的支持。好在Solr所提供的這個複雜架構能夠迅速的安裝使用。具體來講，Solr提供了拼寫檢查功能、用戶輸入的自動補全建議功能、同義詞近義詞處理功能、短語查詢功能、以及用於處理相似」buying a house「和」purchase a home「這樣的語言變異的文本分析功能。

         此外Solr也提供了強大的地理位置查詢功能。在圖1.1中，符合查詢條件的房屋列表在地圖上按照與指定座標點中心的經緯度距離的遠近顯示出來。依靠Solr的地理位置支持，你能夠根據地理位置的距離來進行查詢，甚至能夠依據地理位置的遠近對文檔結果進行排序。對於地理位置查詢來講，快速地返回搜索結果，以及容許用戶經過在地圖上縮放或移動地圖上的位置來進行新的查詢，這些功能都很重要。

         一旦用戶發起了一個查詢，其查詢結果就能夠依靠Solr的分類檢索功能來按照結果文檔集的不一樣特性進行分類顯示，這樣更便於用戶瀏覽搜索返回的結果。分類檢索是一種將結果集按特性分類顯示的方法，能夠幫助用戶進一步的細化查詢已得到更加符合本身需求的信息。在圖1.1中，查詢結果按照房屋特徵，房型和目錄類型進行了分類顯示。

         如今咱們對於房地產查詢應用應該支持哪些功能有了一個基本的瞭解，接下來咱們來看看如何利用Solr來實現這些功能特性。首先咱們須要弄清楚Solr是怎麼在索引中的房屋列表和用戶的查詢之間進行匹配的，這一原理也是全部搜索應用的基礎。

1. 1.1.1              信息檢索引擎

Solr是在Apache 下大名鼎鼎的Java開源信息檢索庫Lucene的基礎之上開發出來的。在第三章中會詳細討論什麼是信息檢索。如今咱們先看看一篇關於現代搜索引擎概念的權威學術論文是如何定義信息檢索的，從中咱們能夠了解到一些關鍵的概念：

 

信息檢索（IR）是指從海量的數據集合（一般存儲在計算機系統中）中，根據某種非結構化的本質屬性（一般是文本內容）查找出知足信息需求的材料（一般是文檔） 的過程。                        ---摘自信息檢索簡介，曼寧出版社2008年出版

 

在咱們的房地產搜索應用中，用戶的主要信息需求是根據地段、房型、房屋功能特性、還有價格這些因素來查找要購買的房子。咱們的索引包含了全美全部的房源，絕對算的上是「海量「數據了。 簡而言之，Solr利用Lucene提供的核心架構，對文檔創建索引，處理查詢請求，實現文檔的搜索功能。

         Lucene底層用JAVA實現倒排索引的創建和管理。倒排索引即倒排表，是用於匹配文本查詢的特殊數據結構。圖1.2展現了咱們的房地產搜索應用中所用的到的Lucene 倒排索引的簡要示意圖。

         在第三章中你將詳細地學習到倒排索引是如何工做的。可是如今看懂圖1.2中的內容就足夠了。這裏展示的是一條新的文檔記錄（圖中的第44號記錄）加入到索引文件中的過程，以及文檔是如何經過倒排索引進行查詢匹配的過程。

         你也許在想，這不是利用關係型數據庫中的SQL語句也能作到嗎？對於這個簡單的例子來講是這樣的。可是Lucene索引查詢和數據庫查詢的一個關鍵區別是：在Lucene中，查詢結果是按照與查詢的匹配程度排序的，而數據庫查詢的結果則只能根據數據表中的某一列屬性進行排序。換句話說，依據相關性對結果進行排序是信息檢索的一個關鍵特性，也是區別於其餘查詢的重要特徵。

-創建全網數據的倒排索引

你也許會感受到驚訝，由於像Google那樣的搜索引擎也是利用倒排索引來查詢網頁的。事實上，創建全網數據的倒排索引的需求，直接致使了MapReduce技術的產生。

MApReduce是一個編程模型，經過Map和reduce兩個階段，將大規模的數據處理操做分配到商用機服務器集羣上去，實現分佈式運行。Google利用MapReduce技術來創建其巨大的倒排索引，用以支撐網絡查詢的需求。在使用MapReduce技術時，先在Map階段生成一系列的數據段並在全部數據段出現的地方標上該數據段惟一的文檔ID。在Reduce階段，全部數據段會作排序，擁有相同文檔ID的數據段會被髮送到同一個reducer進行處理，這樣reducer會加和全部擁有同一文檔ID的數據段，爲之創建倒排索引。

Apache的Hadoop項目就提供了一個開源的Mapreduce實現，而且Apache Nutch開源項目就是用Hadoop來爲全網數據的查詢創建Lucene倒排索引。關於Haddop和Nutch的討論超出了本書的範圍，不過咱們建議讀者不妨去研究一下這些開源項目，會對你創建大規模的搜索索引有幫助的。

         如今咱們知道了Lucene爲搜索提供了核心的架構，那麼讓咱們看看Solr在Lucene之上又附加了哪些價值。咱們從使用Solr靈活的schema.xml配置文件來管理索引創建的方式開始。

1. 1.1.2              靈活的Schema管理

雖然Lucene提供了創建文檔索引和執行查詢的核心架構， 但它並無提供一個方便的接口來設置索引應該如何創建。要使用Lucene，你須要寫一些JAVA代碼來定義值域，還要定義如何分析這些值域。而Solr則提供了簡單的聲明方式來定義索引的結構，你也能夠按照需求來指定如何分析索引中的值域。這一切均可以經過一個名叫schema.xml的XML配置文件來完成。Solr在其底層實現中將schema.xml中的配置翻譯成Lucene的index。這種方式節省了你編程的時間，也使得你的索引結構更加可讀。另一方面，Solr創建的索引與編程實現的Lucene索引是百分之一百兼容的。

         此外Solr在覈心的Lucene索引功能之上還添加了其餘一些不錯的功能。具體來講，Solr提供了Copy Fields和Dynamic Fields兩種新的值域類型。Copy Fields提供了一種方法，能夠將一個或多個值域中的原始文本內容賦值到另外一個新的field值域中。Dynamic Fields則容許你無須在schema.xml裏顯式的聲明，就能夠將同一值域類型賦予多個不一樣的值域。這在爲擁有多個值域的文檔創建模型時很是有用。咱們將在第五章和第六章中深刻介紹schema.xml文件。

         在咱們的房地產搜索應用中，你可能會驚訝於咱們沒對Solr的示例schema.xml作任何修改就直接使用了。這其實剛好展現了Solr的schema配置是多麼的靈活，應爲Solr的示例schem是爲產品搜索設計的，可是咱們的房地產搜索應用拿過來同樣能夠直接使用。

         到目前爲止，咱們知道了Lucene提供了強大的搜索庫，用以支持文檔索引的創建，執行查詢，以及對結果進行排序。還有，利用schema.xml，你能夠靈活的定義索引結構，只須要修改XML配置便可，不須要針對LuceneAPI進行編程。 接下來你須要可以經過網絡來獲取這些服務。因此在下一節，咱們就來學習Solr做爲Java web應用是如何運行的，以及她是如何經過XML，JSON,HTTP等標準技術來與其餘系統集成在一塊兒的。

1. 1.1.3              Java web應用

Solr做爲一個Java web應用，既能夠運行在任意一個現代JAVA Servlet引擎之上，好比Jetty或是Tomcat，也能夠運行在JBoss或是Oracle AS之類的完整的J2EE應用服務器上。圖1.3展現了Solr服務器的主要軟件模塊。

圖1.3可能在第一眼看上去時顯得內容有點多。咱們能夠花點時間先過一遍，先熟悉熟悉名詞和術語。若是有看不懂的術語或是概念也不用擔憂，等你讀完本書的時候，圖1.3中的全部概念和術語你都會有很深的理解。

         正如咱們在本章開頭介紹中所提到的那樣， Solr的設計者們指出Solr很是適合集成到現有的系統中，做爲現有系統的一個有力補充。事實上，你很難找出一個Solr沒法集成進去的系統。正如咱們將在第二章裏看到的那樣，你在下載Solr以後只須要花上幾分鐘，就能夠啓動一個示例的Solr系統了。

         爲了達到易於集成的目標，Solr的核心服務須要可以被不一樣的應用和編程語言訪問。Solr提供簡單的類REST服務，支持XML，JSON，HTTP等標準。順便說一句，咱們並不使用RESTFul一詞來描述Solr基於HTTP的 API，由於它 並不嚴格遵照全部的REST(Representatonal state transfer)原則。例如，在Solr中會用到HTTP POST來刪除文檔，而不是用HTTP DELETE。

         類REST的接口對於基本功能來講已經足夠好用了，可是開發者們常常會但願可以用本身熟悉的編程語言來編寫一些調用網絡服務和處理返回的模版化工具。好消息是針對許多流行的編程語言，Solr都提供了相應的庫，包括Python， JAVA, .NET, 還有Ruby等等。

1. 1.1.4              同一服務器上創建多份索引

現代軟件應用架構的一個顯著特色就是面對快速變化的需求的靈活性。Solr在這方面有個頗有用的特性，就是你沒必要只經過一份單一的索引來完成Solr中全部的任務。Solr支持在單一的Solr 引擎上運行多個Solr 核心。在圖1.3中， 咱們描述了多個solr核心在同一個Java web應用環境中做爲不一樣的層同時運行的場景。

         每個核心都有一個獨立的索引和配置，在一個Solr實例中能夠存在多個Solr 核心。這樣你只須要一個Solr服務器就能夠管理多個核心， 能夠方便的實現服務器資源共享，以及及監控維護服務的共享。Solr有專門的API用於建立和管理多個Core。

         Solr多核心支持功能的一個應用是數據分區，好比用一個core來負責最近更新的文檔，而用另外的core來處理以前生成的文檔，這個功能被稱爲按時間順序分片。

         在咱們的房地產搜索應用中，咱們也可使用多個core來分別處理不一樣的類型的房屋資源，每一類用一個單獨的索引文件來管理。好比說針對農村用地的房地產信息來講，買一塊農業用地的流程和買一套商品房的流程是不一樣的，咱們徹底能夠用一個單獨的索引來管理農業用地的相關信息，將其保存在一個單獨的core裏。

 

1. 1.1.5              可擴展性（經過插件擴展功能）

圖1.3展現了Solr種最主要的三個子系統：文檔管理，查詢處理，和文本分析。固然，這些子系統是對Solr中複雜的子系統所作的宏觀抽象，咱們會在稍後的章節中一一研究這些子系統。這其中的每個都是由一系列功能模塊的流水線串成的，你能夠在流水線中串入新的功能模塊。這意味着若是你想給solr加入新的功能的話，根本不須要重寫整個查詢處理引擎，只須要在合適的位置串入本身的新功能模塊便可。這樣一來Solr的核心功能模塊擴展和定製起來都很方便，能夠徹底按照你的特定應用需求進行定製。

1. 1.1.6              可伸縮性

Lucene是一個查詢速度很是快的搜索庫，而Solr徹底發揮出了Lucene的強勁性能。

可是拋開Lucene的性能不談，做爲一個服務器來講，因爲CPU和I/O的限制，同一時刻可以響應的用戶數和請求數都是有限制的。

         Solr實現可伸縮性的第一張牌是靈活的cache管理功能。該功能能夠避免服務器重複進行耗費資源的操做。具體來講就是Solr預先設置了一些cache來節省開銷很大的重複計算，好比Solr會緩存查詢過濾器的計算結果。咱們會在第四章學習Solr的緩存管理功能。

         緩存的做用是有限的，爲了處理更多的文檔和得到更高的查詢吞吐能力，你須要可以經過擴展服務器來橫向擴展系統的性能。如今咱們來研究一下Solr擴展時最多見的兩個方面。第一個是查詢的吞吐能力擴展，也就是你的引擎每秒鐘能夠處理的最大查詢數是多少。雖然Lucene能夠很是快的處理每個查詢請求，單臺服務可以同時併發處理的請求出仍是會限制總體的查詢吞吐能力。若是須要獲得更高的查詢吞吐能力，你須要增長查詢服務器和索引的拷貝數量，以便讓更多的服務器來同時處理更多的請求。這意味着若是你的索引複製到了三臺服務器上，那麼你每秒鐘大約能夠處理原來三倍的請求數量，由於每臺服務器如今的負荷是總的查詢量的三分之一。在實際應用中不多可以得到如此完美的現行擴展能力，因此使用三臺服務器可能大約能達到原來2.5倍左右的性能。

         另外一個擴展維度是被索引的文檔數。若是你正在處理海量的文檔， 那麼當單個Solr實例中索引的文件數量多到必定程度的時候，查詢性能的瓶頸也會出現。解決的方案是能夠把索引文件切分紅一個個被稱爲「分片」的小塊，而後把查詢請求分佈到這些分片上進行操做。

使用虛擬化的商用硬件進行擴展

現代計算機技術的一個趨勢就是構建能夠在虛擬化的商用硬件上進行橫向擴展的軟件架構。簡單來講，就是能夠經過添加普通的商用機服務器就能夠處理更多的流量。相似於Amazon EC2這樣的雲計算服務提供商經過使用虛擬化的商用硬件來知足這種趨勢的需求。雖然Solr能夠再虛擬化硬件上運行，可是須要注意的是Solr對於I/O和內存很敏感。所以，若是在你的企業中搜索性能被放到了最高優先級來考慮，那你應該考慮在配備有高性能磁盤（好比SSD固態硬盤）的高端硬件上去部署Solr。部署Solr時硬件方面須要考慮的問題將會在第13章中進行討論。

可伸縮性很重要，可是出錯後的自動恢復能力在現代系統中也很重要。在下一節中，咱們來討論一下Solr是如何處理軟件和硬件中的錯誤的。

 轉載請註明原文出處http://my.oschina.net/fengnote

1. 1.1.7              容錯性

除了可伸縮性，咱們還須要考慮若是當server中的一個或多個出了問題時應該怎麼處理。尤爲是你準備把Solr部署到虛擬化的商用硬件上時更要考慮這個問題。最低的要求是你至少要打算去處理這些錯誤。即使是使用高端的硬件配上最優秀的架構，錯誤仍是會發生的。

         咱們假定你的系統中一共有4個分片的狀況。若是2號分片所在的服務器斷電了，那麼此時Solr就不能繼續正常的創建文檔索引了，也不能響應查詢服務了。因此這個時候能夠說，你的搜索引擎就算「掛掉了」。要避免這種狀況，你能夠給每個分片作備份。回到咱們的這個例子中，當2號分片掛掉時，Solr會把全部指向2號分片的索引創建請求和查詢請求重定向到它的備份哪兒，備份這個時候並無掛掉，還能正常工做， 因此整個搜索服務還在。出錯所產生後索引服務和查詢服務仍然能夠工做，不過可能不會像以前那麼快了，由於少了一臺服務器來處理請求。咱們會在第16章中更詳細的討論各類故障狀況。

         到此爲止，你已經看到了Solr具備一個設計良好地現代軟件架構，能夠很好地作橫向擴展以及處理容錯。雖然這些在你決定使用solr以後都是必需要考慮的重要因素，可是你可能仍是沒有很堅決Solr究竟是不是你的正確選擇。在下一節中，咱們會站在公司不一樣角色的角度來看看Solr到底可以給本身帶來什麼好處，包括軟件架構師，系統管理員，和公司的CEO。

1. 1.2              爲何選用Solr？

在本節中，咱們但願能夠提供一些關鍵信息來幫助於你判斷Solr是不是貴公司技術方案的正確選擇。咱們先從Solr吸引軟件架構師的方面提及。

1. 2.1              軟件架構師眼中的Solr

在評估一項新技術時，軟件架構師必需要考慮一系列的因素，其中就包括系統的穩定性，可伸縮性，還有容錯性。Solr在這三方面的得分都很不錯。

         說到穩定性，Solr是一個由活躍的開源社區和經驗豐富的代碼提交者共同維護的一項成熟技術。Solr和Lucene的新用戶們一般會驚訝於項目的發佈方式，可能他們之前都是等待某個項目的官方Release版，沒據說過這種從分支上直接pull下來的方式。無論你的公司是否接受這種方式，咱們並非建議你這麼作，咱們想代表的是，Lucene和Solr項目中自動測試模塊的測試深度和寬度是值得信任的。簡單來講，若是你從分支上拿到了一個nightly build，若是全部的自動測試都能經過，那你就能夠放心的確定全部的核心功能都是ok的了。

         咱們在1.2.6節中已經接觸到了Solr實現可伸縮性擴展的方法，在1.2.7節中也討論了容錯性的問題。做爲一個架構師，你可能最好奇的是Solr的可伸縮性功能和容錯性功能的侷限到底在哪裏。首先，你須要知道在Solr4中，分片功能和複製備份功能都被重寫了，在魯棒性和易於管理方面都有很大提升。新的擴展方式被稱爲SolrCloud。其底層實現上，SolrCloud使用了Apache ZooKeeper來管理Solr集羣上的配置同步，並監控集羣的運行狀態。這裏列出了一些Solr全新的SolrCloud功能的亮點：

轉載請註明原文出處http://my.oschina.net/fengnote

·中心化的配置

·分佈式的索引，避免單點失敗（SPoF）

·自動容錯，自動產生新的主分片

·任意節點都可觸發覆蓋整個集羣全部分片的分佈式全查詢，且已經集成了自動容錯和負載均衡

可是這並非說Solr的可伸縮性就沒有提升的空間了。SolrCloud在兩方面還有待提升。首先，不是全部功能都能工做在分佈式模式下。好比 joins鏈接功能。其次，一旦索引創建，索引的分片數目就不能再動態調整，要想改變分片數的話只能從新對全部文檔創建索引。咱們在第16章會詳細討論SolrCloud的方方面面，可是咱們但願確保軟件架構師們可以意識到Solr的可伸縮性過去幾年中已經走過了很長的路，並且從此還將繼續不斷地改進下去。

1. 2.2              系統管理員眼中的Solr

做爲一名系統管理員，在考慮開始使用像Solr這樣的一種新技術時，最優先考慮的是新技術是否可以很好地和已有系統進行配合。對於Solr來講對這個問題能夠很輕鬆的回答YES。Solr 徹底是基於JAVA開發的，能夠在任意一個裝有J2SE 6.x/7.x JVM虛擬機的操做系統上運行。並且Solr還自帶了Oracle提供的開源Java Servlet引擎Jetty，拿來就能用。另外一方面，Solr是一個標準的Java Web應用，能夠很方便的在JBoss或是Oracle AS之類的Java web應用服務器上進行部署。

對Solr的全部操做均可以經過HTTP請求來完成， 而且Solr在設計時就考慮到了同Squid或是Varnish這樣的HTTP反向代理協同工做。Solr同時也支持JMX，因此你能夠把Solr掛載到你喜歡的監控程序（好比Nagios）之下進行監控。

最後，Solr提供了一個不錯的管理控制檯， 能夠用於檢查配置，查看統計信息，發起測試查詢，以及監控SolrCloud的健康狀況等等。圖1.4展現了Solr4 管理控制檯的一個截屏，咱們會在第二章中詳細的學習管理控制檯的使用。

1. 2.2.1        公司CEO眼中的Solr
   儘管CEO之類的人物是不太可能看這本書的，咱們仍是要寫幾點關鍵的，以便於萬一CEO在大廳裏叫住你聊聊的時候你能夠拿這幾點去忽悠他。首先，管理層的人喜歡聽到他們今天對技術作出的一筆投資將會在從此很長一段時間內都產生效益。具體到Solr，你能夠強調一下許多公司至今還在靠着Solr 1.4運行公司的產品，這但是2009年發佈的老版本，這說明Solr是有着成功的商用案例的，而且一直持續在改進。

此外，CEO們喜歡可控可預測的技術。正如你在接下來的章節裏所要看到的那樣，Solr很好用，你能夠在幾分鐘以內就搭起一個簡單的Solr服務。另外一個疑問是若是萬一負責Solr的那個員工跳槽或是跑路了，咱們公司的業務會受到影響嗎？不會所以整個服務當掉把？Solr的技術確實比較複雜，可是其開源社區很是的活躍，這意味着你只要上去求助基本上都能及時獲得幫助。並且，你是直接能夠看到源碼的呀，有的時候你發現一個地方寫的有問題那你能夠直接本身fix掉就好了。另外也有許多商業化的服務商能夠幫你規劃，實現和維護你的Solr系統，其中不少服務商還提供Solr相關的培訓課程。

接下來這一點可能CFO更關心，就是使用Solr的投資花費問題。投資使用Solr其實花不了多少錢。咱們不用知道你的運營環境的規模大小就能夠很自信的說，你能夠在幾分鐘以內就搭起一個簡單的Solr服務，而且很快就能夠創建文檔的索引。如今搭在雲端的一個服務器能夠在亞秒級（譯者注：即不到一秒的時間以內）就處理完上百萬的文檔請求。