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

1.   Solr到底是什麼？

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

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

2）  Solr和站點優化中經常提到的搜索引擎SEO優化沒有不論什麼關係

好了。現在若是咱們準備爲潛在的購房客戶設計一個不動產搜索的網絡應用。該應用的核心用例場景是經過網頁瀏覽器來搜索全美國範圍內的房子。圖1.1描寫敘述了這個虛擬應用的界面截圖。

不用太在乎UI界面的簡陋，這僅僅是一個便於咱們討論的可視化模型。重點是經過這個樣例，咱們來看看Solr究竟可以提供哪些類型的搜索體驗。

         讓咱們先高速瀏覽一下圖1.1描繪了哪些Solr的關鍵特性。

咱們從左上角開始。沿順時針方向看。首先。Solr提供了強大的功能來支持keyword搜索框。正如咱們在1.1.2中討論的那樣，一個表現出色的keyword搜索功能，需要背後強大的複雜架構的支持。

好在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兩個階段，將大規模的數據處理操做分配到商用機server集羣上去，實現分佈式執行。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應用server上。圖1.3展現了Solrserver的主要軟件模塊。

圖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              同一server上創建多份索引

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

         每一個核心都有一個獨立的索引和配置，在一個Solr實例中可以存在多個Solr 核心。這樣你僅僅需要一個Solrserver就可以管理多個核心， 可以方便的實現server資源共享，以及及監控維護服務的共享。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的性能不談，做爲一個server來講，由於CPU和I/O的限制，同一時刻能夠響應的用戶數和請求數都是有限制的。

         Solr實現可伸縮性的第一張牌是靈活的cache管理功能。該功能可以避免server反覆進行耗費資源的操做。詳細來講就是Solr預先設置了一些cache來節省開銷很是大的反覆計算。比方Solr會緩存查詢過濾器的計算結果。

咱們會在第四章學習Solr的緩存管理功能。

         緩存的做用是有限的。爲了處理不少其它的文檔和得到更高的查詢吞吐能力，你需要能夠經過擴展server來橫向擴展系統的性能。

現在咱們來研究一下Solr擴展時最多見的兩個方面。

第一個是查詢的吞吐能力擴展，也就是你的引擎每秒鐘能夠處理的最大查詢數是多少。

儘管Lucene能夠很是快的處理每一個查詢請求。單臺服務能夠同一時候併發處理的請求出仍是會限制整體的查詢吞吐能力。假設需要獲得更高的查詢吞吐能力，你需要添加查詢server和索引的拷貝數量。以便讓不少其它的server來同一時候處理不少其它的請求。

這意味着假設你的索引拷貝到了三臺server上。那麼你每秒鐘大約能夠處理原來三倍的請求數量，因爲每臺server現在的負荷是總的查詢量的三分之中的一個。在實際應用中很是少能夠得到如此完美的現行擴展能力，因此使用三臺server可能大約能達到原來2.5倍左右的性能。

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

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

現代計算機技術的一個趨勢就是構建可以在虛擬化的商用硬件上進行橫向擴展的軟件架構。

簡單來講。就是可以經過加入普通的商用機server就可以處理不少其它的流量。相似於Amazon EC2這種雲計算服務提供商經過使用虛擬化的商用硬件來知足這種趨勢的需求。儘管Solr可以再虛擬化硬件上執行。但是需要注意的是Solr對於I/O和內存很是敏感。

所以。假設在你的企業中搜索性能被放到了最高優先級來考慮，那你應該考慮在配備有高性能磁盤（比方SSD固態硬盤）的高端硬件上去部署Solr。部署Solr時硬件方面需要考慮的問題將會在第13章中進行討論。

可伸縮性很是重要，但是出錯後的本身主動恢復能力在現代系統中也很是重要。

在下一節中。咱們來討論一下Solr是怎樣處理軟件和硬件中的錯誤的。

1. 1.1.7              容錯性

除了可伸縮性，咱們還需要考慮假設當server中的一個或多個出了問題時應該怎麼處理。

尤爲是你準備把Solr部署到虛擬化的商用硬件上時更要考慮這個問題。

最低的要求是你至少要打算去處理這些錯誤。

即使是使用高端的硬件配上最棒的架構，錯誤仍是會發生的。

         咱們假定你的系統中一共同擁有4個分片的狀況。假設2號分片所在的server斷電了，那麼此時Solr就不能繼續正常的創建文檔索引了。也不能響應查詢服務了。因此這個時候可以說，你的搜索引擎就算「掛掉了」。要避免這樣的狀況。你可以給每一個分片作備份。回到咱們的這個樣例中，當2號分片掛掉時，Solr會把所有指向2號分片的索引創建請求和查詢請求重定向到它的備份哪兒。備份這個時候並無掛掉。還能正常工做， 因此整個搜索服務還在。出錯所產生後索引服務和查詢服務仍然可以工做，只是可能不會像以前那麼快了。因爲少了一臺server來處理請求。咱們會在第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功能的亮點：

·中心化的配置

·分佈式的索引。避免單點失敗（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應用server上進行部署。

對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服務。並且很是快就可以創建文檔的索引。現在搭在雲端的一個server可以在亞秒級（譯者注：即不到一秒的時間以內）就處理完上百萬的文檔請求。