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

 

 

第一章           Solr 簡介

本章速覽：

·搜索引擎處理的數據特性

·常見搜索引擎用例

·Solr核心模塊介紹

·選擇Solr的理由

·功能概述

 

伴隨着社交媒體、雲計算、移動互聯網和大數據等技術的高速發展，咱們正迎來一個使人激動的計算時代。軟件架構師們開始面對的主要挑戰之一，即是如何處理全球巨大的用戶基數所產生及使用的海量數據。此外，用戶們開始期待在線軟件應用永遠都是穩定可用的，而且可以一直保持響應，這對應用就提出了更高的可擴展性和穩定性需求。爲了知足這些需求，一些專用的非關係型數據存儲及處理技術，統稱爲NoSQL（Not Only SQL）技術，開始得到愈來愈多的青睞。這些系統並不強制要求將全部的數據都存儲在曾經成爲事實上標準的關係型數據模型當中，而是共用了一個通用的設計模式，在數據存儲處理引擎和特定的數據類型之間進行匹配。換句話說，NoSQL技術爲處理特定數據類型的特定類別問題作了性能優化。因爲對可擴展性的需求和性能的需求不斷增長，致使各類NoSQL技術和傳統關係型數據庫開始混合使用，這種跨界架構變得愈來愈流行。過去那種一種數據處理方案就能吃遍天下的時代已經一去不復返了。

        

         本書主要討論一種特殊的NoSQL技術，即Apache Solr。和她的其餘非關係型兄弟們同樣，Solr也爲一類特定問題的處理作了優化。具體來講，Solr 是一個可擴展的，可快速部署的，對搜索海量文本中心的數據和對返回結果作相關性排序方面作了優化的企業級搜索引擎。

 

這句話讀上去有點拗口，不過不要緊，咱們把這個定義中的亮點分解出來看：

 

·可擴展性：Solr能夠把創建索引和查詢處理的運算分佈到一個集羣內的多臺服務器上。

·快速部署：Solr是開源軟件，安裝和配置都很方便，能夠根據安裝包內的Sample配置直接上手。

·優化的搜索功能：Solr搜索夠快。對於複雜的搜索查詢，Solr能夠作到亞秒級的處理，一般幾十毫秒就能處理完一次複雜查詢

·海量文本：Solr是針對百萬級以上的海量文本處理而設計的，能夠很好地處理海量數據。

·文本中心的數據：Solr爲搜索包含天然語言的文本內容作了優化，好比電子郵件，網頁，簡歷，PDF文檔，或是推特、微博、博客這些社交內容等等，都適合用Solr來處理。

·結果是按相關性排序的：Solr的搜索返回結果是按照結果文檔與用戶查詢之間的相關程度度作排序的，保證最相關的結果會優先返回。

 

在本書中，你將學到如何使用Solr來設計實現一個可擴展的搜索方案。咱們的學習旅程從瞭解Solr支持的數據類型和典型用例開始。這樣你能更好的理解在整個現代軟件應用架構全景圖中Solr所處的位置，以及Solr究竟是設計來處理哪些問題的。

 

 

1.1我到底須要一個搜索引擎嗎？

咱們猜想你已經有了些想法要準備使用搜索引擎了，不然你也不會翻開這本書。所以，咱們就不浪費時間來揣度你究竟是爲何開始考慮用Solr的了，咱們直接來討論點乾貨，看看關於你的數據和用例方面， 有哪些問題是你在決定是否使用搜索引擎以前所必需要回答的。這最終會歸結爲如何深入理解你的數據和你的用戶，以選用一個合適的技術來同時知足兩者的需求。咱們先從討論一下哪些數據屬性是搜索引擎適合處理的。

1. 1.1.1              管理文本中心的數據

合理選用同數據匹配的存儲及處理引擎，是現代軟件應用架構的標誌性要求之一。若是你是一個優秀的程序員，那麼你應該知道要根據在算法中使用數據的方式來選取最合適的數據結構。好比，若是你須要實現快速隨機查找，你就不會使用鏈表結構來存儲數據。一樣的道理也適用於搜索引擎的選取。這裏列出了適合用相似Solr這樣的搜索引擎來處理的數據的4種主要特色：

1. 文本中心的數據

2. 讀取遠多於寫入的數據

3. 面向文檔的數據

4. 靈活的Schema

也許在這兒應該加上第五個數據特性，即：海量數的據量，也就是」大數據「，可是咱們主要關注的是Solr區別於其餘NoSQL技術的主要特性，而能夠處理海量的數據並非它們的主要區別之一。

雖然這裏列出了相似Solr這樣的搜索引擎能夠有效處理的數據類型的4個主要特色，可是這只是一個粗略的準則，並非一個嚴格的標準。咱們來深刻的討論一下這些數據特性，看看爲何它們對於搜索來講這麼重要。咱們如今只關注概念，具體的實現細節在稍後的章節討論。

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

文本中心的數據

你確定見過有人用「非結構化數據「這個術語來描述搜索引擎處理的數據。咱們認爲「非結構化」這個詞有些模糊不清，由於任何一個基於人類語言產生的文檔都是隱含有必定的結構的。要理解「非結構化」這個術語你能夠認爲這是從計算機的角度來看的。在計算機眼中，文本文檔就是一個字符流。這個字符流必須經過特定的語言規則解析出語義結構，才能被檢索到。而這正是搜索引擎的工做所在。

咱們認爲「文本中心的數據」這個詞更適合用來描述Solr處理的數據類型。由於搜索引擎的設計初衷就是用來提取文本數據的隱含結構，並生成相關索引以提升查詢檢索的效率。「文本中心的數據」這個詞隱含代表了文檔中的文本信息包含用戶感興趣的查詢內容。固然，搜索引擎也支持非文本數據，好比數字類型的數據，可是其主要強項，仍是在於處理基於天然語言的文本數據。

前面說的都是「文本」，其實「中心」這個部分也很重要，由於若是你的用戶對於文本部分的內容不感興趣，那麼搜索引擎可能就不是處理你的問題的最佳選擇。舉個例子，對於一個給員工用來建立差旅支出報告的應用，每份報告都包括一些結構化的數據，好比日期，費用類型，匯率，數量等等，另外每項費用後面可能會包含一些備註信息，用於描述該項費用的大體狀況。這樣一個應用就是一個包含文本信息，但並非「文本中心的數據」的一個例子，由於會計部門在使用這些員工的支出費用報告來生成月度支出報告時，並不會經過查找備註裏的文本信息來作，文本在這裏並非其關心的主要內容。簡單來講，就是否是全部包含文本信息的數據都適合搜索引擎來處理。

因此如今先花幾分鐘好好想一想你的數據是不是「文本中心的數據」。考慮的重點主要就是數據中的文本信息用戶是否是會拿來作檢索。若是答案是YES，那麼搜索引擎極可能是一個好的方案選擇。咱們在第5章和第6章會討論如何利用Solr的文本分析來提取文本數據的結構的細節。

 

讀取遠多於寫入的數據:

另一個搜索引擎能夠高效處理的數據特性是「讀取遠多於寫入的數據」。首先，須要聲明的是Solr是容許你更新索引中的現有文檔內容的。你能夠把「讀取遠多於寫入」解讀爲對於文檔的讀取操做頻率要遠遠高於建立文檔和更新文檔的頻率。可是別狹隘的理解爲你就徹底不能寫入數據了，或是你會被限制在一個特定頻率之下更新數據。事實上Solr4的一個關鍵特性就是「近乎實時的查詢」，這個功能能夠容許你每秒鐘爲數千的文檔創建索引而且幾乎馬上就能查詢到這些新加入的文檔。

「讀取遠多於寫入的數據」背後的關鍵點是你的數據在寫入Solr後，在其生命週期內應該是要被重複讀取不少次的。你能夠理解爲搜索引擎並非主要用來存儲數據的，而是主要用於查詢存儲的數據的（查詢請求是一種讀取操做）。因此若是你須要很頻繁的更新數據，那麼搜索引擎可能不太適合你的需求，其餘的NoSQL技術，好比Cassandra，可能更適合你的快速隨機寫入的需求。

 

面向文檔的數據

到目前爲止，咱們一直使用更通用的「數據」這一術語，可是實際中搜索引擎處理的都是文檔數據。在搜索引擎中，一個文檔是由值域(field)組成的獨立集合，每個值域都只保存數據值，不能再嵌套包含其餘值域。換句話說，在Solr這樣的搜索引擎中，文檔都是扁平結構的，文檔之間不存在相互依賴關係。Solr中「扁平」的概念是比較寬鬆的，一個值域能夠保存多個數據值，可是值域不能再嵌套包含子值域。也就是說你能夠在一個值域裏存儲多個數據值，可是你不能往值域裏頭嵌套別的值域。

Solr中這種扁平化的、面向文檔的方式能夠很好的處理已經文檔化的數據，好比網頁，博客，pdf文檔等等。那麼若是要用solr來處理關係型數據庫中已經結構化好的數據應該怎麼辦呢？這種狀況下你須要先把關係型數據庫中跨表存儲的數據取出來，去結構化，而後放到扁平化的自包含文檔結構裏。咱們會在第三章學習怎麼處理這樣的問題。

你還須要考慮你的文檔數據中的哪些值域須要存儲在Solr中，哪些值域須要存儲在其餘系統中（好比數據庫中）。簡單來講，搜索引擎只存儲須要被檢索到的數據，以及用於顯示檢索結果的數據。舉個例子，若是你有一個在線視頻的搜索索引，你應該不會但願把視頻文件自己存儲在Solr中，合理的方案應該是把大的視頻文件都放在內容分發網絡（CDN）中。一般你只須要在搜索引擎中存儲知足搜索需求的最少數據便可。剛纔這個在線視頻的例子清楚的說明了不要把Solr當成通用數據存儲技術，Solr的工做是找到用戶感興趣的視頻文件，而不是存儲視頻文件自己。

 

靈活的Schema

最後一個搜索引擎數據的主要特性是有靈活的schema。這意味着查詢索引中的文檔不須要擁有統一的結構。在關係型數據庫中，表中的每一行數據都必須擁有相同的結構。而在Solr中，文檔們能夠有不一樣的值域。固然同一個索引中的文檔們至少應該擁有一部分你們都有的值域以便於檢索，可是並不要求全部文檔中的值域結構徹底同樣。

舉個例子，假如要作一個用於查找出租和出售房源的搜索應用。顯然每條房源文檔都會有地段，房間數，衛生間數等一些共有的值域，可是根據類型是出租仍是出售的不一樣，不一樣的房源文檔會有不一樣的值域。一條出售的房源會有售價值域，財產稅值域，而一條出租的房源文檔則會有月租金和寵物政策等等不一樣的值域。

總結一下，Solr這樣的搜索引擎是專門優化用於處理文本中心的，讀取遠多於寫入的，面向文檔的，擁有靈活Schema的數據用的。Solr並非一種通用數據存儲處理技術，這也是區別於其餘NoSQL技術的主要因素。

有衆多不一樣的數據存儲和處理方案可供選擇的好處是你再也不須要費勁腦汁地尋找一種能夠知足全部需求的通用技術方案。搜索引擎在某些特定任務上表現出色，可是在其餘一些方面性能不好。這意味着在大多數狀況下，你能夠用Solr來做爲關係型數據庫和其餘NoSQL技術的有力補充，而並非要取代後者。

既然咱們已經談到了Solr所針對優化處理的數據類型，那咱們就接着來討論一下像solr這樣的搜索引擎主要是設計來解決哪些實際用例的。理解這些用例能夠幫助你理解搜索引擎技術是如何區別於其餘數據處理技術的。

 

1. 1.1.2              常見的搜索引擎用例

在這一節中，咱們來看看Solr這樣的搜索引擎都能幹些什麼。正如咱們在1.1.1節中所提到的那樣，這些討論只是一種指南性質的建議，不要把它們當成嚴格的使用規則來看。在咱們開始以前，你須要意識到想作出一個優秀的搜索服務，其門檻是很高的。如今的用戶都習慣於使用像Google和Bing這樣又快又高效的網絡搜索引擎，而不少受歡迎的網站也有本身強大的搜索方案來幫助用戶快速的獲取想要的信息， 因此用戶對搜索服務並不陌生而且會很是的挑剔。當你在評估像Solr這樣的搜索引擎時，或是在設計你本身的搜索方案時，必定要有根弦兒，要把用戶體驗放在高優先級上來考慮。

 

 

基本的關鍵字查詢

很明顯，做爲一個搜索引擎來講， 首先必需要可以支持基本的關鍵詞查詢。這也是搜索引擎的主要功能之一。不過關鍵詞查詢功能仍是值得在這裏強調一下的，由於這是用戶使用搜索引擎最典型的方式。不多有用戶想要會一上來就填寫一個很完整的複雜搜索表單來進行搜索的。考慮到關鍵詞搜索功能將會是用戶和你的搜索引擎之間最多見的交互方式，這個基本功能必須可以提供給用戶以很是好的用戶體驗才行。

         通常來講，用戶但願只輸入幾個簡單的關鍵詞就能獲取到很好的搜索結果。這也許聽上去像是一個簡單的匹配任務：把查詢字串和文檔進行匹配便可。不過請考慮一下要實現良好的用戶體驗所必須解決的幾個問題：

·          相關結果必須迅速返回，大多數狀況下要求一秒鐘以內就可以返回

·          用戶的查詢字串出現拼寫錯誤時可以自動糾錯

·          用戶輸入時經過自動補全建議來減小用戶的輸入負擔，這在移動應用中很常見

·          處理查詢字串中的同義詞近義詞

·          對包含查詢字串的語言變異的文檔進行匹配（譯者注：語言變異是語義學術語，即用詞不徹底同樣的近似表達）

·          短語處理，用戶是但願匹配短語中全部的單詞，仍是隻要匹配短語中的部分單詞就行

·          對一些通用介詞的處理，好比「a,」 「an」, 「of」, 「the」等等

·          若是最靠前的查詢結果用戶不滿意， 如何給用戶返回更多的查詢結果

就像你看到的那樣，不使用特定的處理方法的話，這樣一堆問題會使得看上去如此簡單的功能實現起來變得很困難。然而利用像Solr這樣的搜索引擎，這些功能就能立等可取，實現起來變得很簡單。當你給用戶提供了一個強大的關鍵詞搜索工具以後，接下來你就須要考慮如何去展現查詢的結果，這就引出了下一個用例，按照結果同查詢請求之間的相關性順序，對搜索返回的查詢結果進行排序。

 

排序的檢索結果

搜索引擎爲查詢返回「最靠前「的結果。在SQL查詢關係型數據庫的時候，某一行數據記錄要麼匹配查詢被返回，要麼不匹配查詢被忽略，查詢結果也是按照數據記錄的某一列屬性來排序的。而對於搜索引擎來講，返回的結果文檔是按照得分作降序排列的，該得分表示文檔和查詢的匹配程度。匹配程度得分依據一系列的因子來計算，不過通常說來得分越高，代表結果文檔同查詢之間的相關度越高。

         有好幾個因素決定了將結果文檔按照相關度排序的方式很重要。首先，現代搜索引擎通常都存儲着海量的文檔，都是上百萬甚至數十億記的。若是不對查詢結果進行相關度排序，那用戶就會被海量的返回結果所淹沒，沒法清晰有效的瀏覽搜索的結果。其次，用戶使用其餘搜索引擎的經驗使得用戶已經習慣於使用少數的幾個關鍵詞就能得到不錯的查詢結果，也使得用戶廣泛比較缺少耐心。他們會期待搜索引擎按照他們想要的意思來工做，而無論其所輸入的信息是否徹底正確。好比對於移動應用的後臺搜索服務來講，用戶會期待在輸入了簡短的幾個可能還包含有拼寫錯誤的查詢詞以後，搜索服務就可以返回正確的搜索結果。

         若是要人工干預排序的結果，你能夠給特定的文檔、值域、或者查詢字串增長權重，或着直接提升某個文檔的相關度分值。好比你若是但願把新加入的文檔推送到最靠前的位置，就能夠經過按照建立時間來提升文檔排序的方式實現。咱們在第三章中會學習關於文檔排序的知識。

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

除了關鍵詞查詢以外

利用像Solr這樣的搜索引擎，用戶能夠輸入少數幾個關鍵詞就能獲取到一些搜索結果。然而對於不少用戶來講這僅僅是一個查詢交互的第一步。他們須要在查詢結果中可以繼續地瀏覽。驅動一個信息發現的交互會話過程也是搜素引擎的一個主要應用場景。一般用戶在搜索前並非很精確的知道想要查詢的信息什麼樣的，他們事先也不知道你的系統中到底存儲了哪些信息。一個好的搜索引擎能夠幫助用戶不斷地細化信息需求，一步步到達最須要的信息。

這裏的核心思想是在返回用戶最初的查詢所對應的文檔結果的同時，提供給用戶一個工具，使其可以不斷地改進查詢以得到更須要的信息。換句話說，在返回匹配的文檔以外，你應該返回一個工具讓用戶知道下一步該怎麼辦。舉個例子，你能夠對查詢結果按照屬性進行分類，便於用戶根據需求作進一步的瀏覽。這種功能稱之爲分類檢索（Faceted-Search），這也是Solr的功能亮點之一。咱們會在1.2節中看到一個關於房地產的分類檢索實例，在第八章中會詳細介紹分類檢索功能的細節。

 

搜索引擎不適合作的事…

最後，咱們來討論一下不適合應用搜索引擎的一些用例場景。首先，搜索引擎通常的設計是，爲每一個查詢返回一個小的文檔集，一般包含10個到100個的結果文檔。更多的結果文檔能夠經過Solr自帶的結果分頁功能來獲取。對於一個查詢結果有好幾百萬個文檔的狀況，若是你要求全部的匹配文檔都要可以一次返回，那麼你會等待很長的時間。查詢自己會執行的很快，可是從索引結構中重建上百萬的文檔絕對是一件很耗時間的事情。由於Solr這樣的搜索引擎在硬盤上存儲值域的方式只適用於快速生成少許的文檔結果，若是須要一次生成大量的查詢結果，在這種存儲方式之下生成大量文檔結果就會耗費大量的時間。

另外一個不適合應用搜索引擎的使用場景是須要讀取索引文件的大部分子集的才能完成的深度分析任務場景。即便你經過結果分頁技術避免了剛剛說的那個問題，若是一次分析須要讀取索引文件中的大量數據，你也會遇到很大的性能問題，由於索引文件的底層數據結構就不是爲一次大量讀取來設計的。

咱們前面有提到過一點，可是在這裏仍是要再次強調一下，那就是搜索引擎技術並不適合用於在文檔的相互關係之間進行查詢。Solr確實是能夠支持基於父子關係的查詢，可是並不支持在複雜的關係型數據結構之間查詢。在第三章，你會學習到如何將關係型數據結構適配到適合solr處理的扁平型文檔結構中進行查詢。

最後，絕大多數搜索引擎都沒有直接的文檔級安全支持，至少Solr是沒有。若是你須要嚴格管理文檔的權限，那你只能在搜索引擎以外來想辦法。

到這裏咱們已經瞭解了適合搜索引擎處理的用例場景和數據類型，下一步該是時候討論Solr到底能作些什麼，以及這些功能是如何實現的了。在下一節中，你將學習到Solr到底有哪些主要功能，以及她是如何實現外部系統集成、可擴展性、以及高可用性等軟件設計原則的。