Solr In Action 中文版 第一章(四、五),solraction
1.1 功能概覽1. 4
最後,讓我們再按照下面的分類,快速的過一下Solr的主要功能:
·使用者體驗
·資料建模
·Solr 4的新功能
在本書中,為你的使用者提供良好的搜尋體驗會一直貫穿全書的主題。所以我們就從使用者體驗開始,看看Solr是如何讓你的使用者感覺到爽的。
1.4.1 使用者體驗類功能
Solr提供了一系列的重要功能來協助你搭建一個易用的,符合使用者直覺的,功能強大的搜尋引擎。不過你需要注意的是Solr僅僅是提供了類REST風格的HTTP API介面,她並不提供搜尋介面相關的UI組件和架構。你需要捲起袖子來寫一個你自己的搜尋介面UI,可以充分的利用以下列出的使用者體驗類功能:
·分頁和排序功能
·分類檢索功能
·自動補全功能
·拼字檢查功能
·高亮命中結果功能
·地理位置查詢功能
分頁和排序功能
Solr 不會返回所有符合查詢條件的結果。Solr在分頁請求查詢結果方面做了最佳化,每次只有最靠前的N個文檔會被在請求第一頁結果時返回。如果使用者在第一頁結果中沒有找到想要的資訊,那麼可以通過很簡單的API調用和請求參數獲得後續頁碼的內容。分頁功能對於兩類關鍵的輸出有協助:1)結果返回的更快了,因為每次查詢都只需要返回整個搜尋結果中的一個很小的集合; 2)可以協助你追蹤到底有多少請求是針對更多頁碼內容的。這個指標可以反映出你的相關性得分的計算是否有問題。你會在第7章中詳細的瞭解到分頁和排序相關的內容。
分類檢索功能:
分類檢索功能將搜尋結果按照特性分類放到一個個小組中,這就為為使用者提供了一個不斷最佳化搜尋索引鍵和瀏覽搜尋結果的工具。在我們的房地產搜尋例子中(圖1.1), 我們看到了使用者通過基本的查詢關鍵字搜尋到的結果被組織到了三個分類中:房屋特徵,房型, 和清單類型。分類檢索功能是Solr很受歡迎的強大功能之一,我們在第8章中會詳細討論分類檢索。
自動補全功能
大多數使用者都會期待你的搜尋應用在輸入的資訊不完整的情況下仍然能夠正確的返回結果。自動補全功能會根據系統索引檔案中的文檔內容在使用者輸入關鍵詞的時候做出相應的自動填補建議。Solr的自動補全功能使得使用者只需要輸入少數幾個字元就能得到一個根據這些輸入字元推薦出來的查詢詞列表。這能大大降低使用者輸入錯誤查詢詞的幾率,尤其是現在很多使用者都會在行動裝置上用小鍵盤輸入搜尋內容。
自動補全功能給使用者提供了可選的查詢詞樣本。回到我們的房地產搜尋應用例子上,當使用者輸入”hig“時,Solr的自動補全功能會返回:highlands neighborhood 或者 highlandsranch 這樣的可用查詢詞。我們會在第十章中詳細的介紹自動補全功能。
拼字檢查
在這個行動裝置的時代和人人都很忙的時代,拼字檢查功能顯得尤為重要。使用者在輸入帶有拼字錯誤的查詢詞時,仍然會期待搜尋引擎能夠優雅的自動處理掉這些小錯誤,返回給使用者正確的查詢結果。Solr的拼字檢查支援兩種基本的模式:
自動錯誤修正模式:Solr可以在使用者出現拼字錯誤的時候自動根據該詞語在索引中是否存在而做出相應的錯誤修正處理
”您要找的是不是…“功能: Solr也可以根據使用者的輸入,為使用者建議一個更佳的輸入方案,比如當使用者輸入”hilands“時,solr會建議使用者”您要找的是不是highlands?“
拼字檢查功能在Solr 4中做了很大改進,我們會在第10章中做詳細的討論。
高亮命中結果功能
在搜尋文本量比較大的文檔時,你可以通過Solr的高亮命中結果功能對命中的內容進行高亮顯示。這在常值內容很長的文檔中很實用,使用者可以藉此功能很方便的在長長的常值內容中一眼找到命中的搜尋內容部分。我們會在第9章中詳細討論高亮命中功能。
地理位置搜尋功能
地理位置搜尋是Solr 4 中的一個很棒的功能,Solr4 自建了對經度值和緯度值的索引支援, 可以對文檔按照地理位置的遠近做出排序。Solr 可以根據到地理位置上某一點(某一具體的經度和緯度上的一點)的距離,尋找出相應的文檔記錄並對結果排序。在我們的房地產應用例子中,匹配出來的房源結果可以在互動地圖上根據使用者的縮放和中心店的移動做地理位置查詢,按照與中心點的距離遠近對查詢結果排序。
Solr 4中另一個激動人心的功能是你甚至可以通過在地圖上畫出各種幾何圖形,比如多邊形,根據不同形狀之間的交集來做地理位置查詢。這在你想要在尋找房源的時候能夠指定具體的街區地理範圍時會很有用。我們會在第14章中討論Solr的地理位置查詢功能。
1.4.2 資料建模類功能
正如我們在第1.1節中討論的那樣,Solr對特定類型的資料處理做了最佳化。在本節中,我們列出了你在為搜尋建立資料模型時可能會用到的一系列關鍵功能,包括:
· 值域的合并和分組功能
· 靈活的查詢支援功能
· 串連功能
· 歸集功能
· 從PDF和word等格式的文檔中匯入富媒體資料的功能
· 從關係型資料庫中匯入資料的功能
· 多種語言的支援
· 值域的合并和分組功能
雖然Solr要求處理的文檔盡量的扁平化、非規格化,但還是允許你將多個文檔按照大家共有的某種屬性進行歸組管理。值域分組,也被稱為值域的合并,允許你在返回結果時除了可以返回一個個的文檔之外還可以返回一個特定的文檔分組。
關於值域分組功能的一個經典的例子就是郵件清單,我們可以把所有符合查詢條件的同一主題的郵件都附在以最早引發會話的那封郵件開頭的一個郵件清單裡返回給使用者。你將會在第11章中學到更多的關於值域分組的內容。
· 強大而靈活的查詢支援功能
Solr提供了一系列強大的查詢功能,包括:
· 支援與(and), 或(or),非(not)的條件邏輯
· 支援萬用字元匹配
· 支援日期和數位範圍查詢
· 支援模糊的短語查詢
· 支援模糊字串匹配
· 支援Regex匹配
· 支援功能查詢
如果你對其中的一些名詞不熟悉沒有關係,我們會在第7章中深入討論。
· 串連功能
在SQL中你可以使用JOIN來建立一個連結關係,將兩張或多張表之間的資料通過一個稱之為Foregn Key的共有屬性串連起來。但是在Solr中,join操作更像是SQL中的子查詢,只是你並不會通過連結文檔之間的資料而建立新的文檔。例如,通過Solr的join功能,你可以返回父文檔符合查詢條件的子文檔。Solr串連功能在你需要拿到某條推特或是微博的所有評論時很有用,所有評論都是原文的子文檔。我們會在第14章中詳細討論該功能。
· 文檔歸集
文檔歸集功能允許可以根據每個文檔的描述將相似的文檔歸為一組。
這有助於避免在返回查詢結果時返回很多內容很近似的文檔結果。例如,如果你的搜尋引擎是一個新聞應用,通過多個RSS連結來推送文章,那麼你很可能會同時收到很多關於同一條新聞的報道。把這些內容差不多的報道都返回給使用者顯然不是一個好主意,此時你可以使用文檔歸集功能把這些類似的報導分成一組,選取一篇有代表性的報道返回給使用者就妥了。歸集技術會在第17章做詳細討論。
· 從PDF和word等格式的文檔中匯入富媒體資料的功能
在某些場合下,你可能需要處理一些已有的通用格式文檔,比如PDF和微軟word文檔之類的,你需要這些文檔也能被檢索。用Solr的話要實現這一點很簡單,因為Solr直接整合了ApacheTika項目,該項目幾乎支援所有的流行文檔格式。匯入富媒體文檔的相關問題在第12章中會詳細討論。
· 從關係型資料庫中匯入資料的功能
如果你想要搜尋的資料是儲存在傳統的關係型資料庫當中的,那你可以配置Solr來通過SQL查詢語句建立文檔。我們在第12章中會具體討論如何使用Solr的資料匯入介面(DIH)
· 多種語言的支援
Solr和Lucene對多語言環境的支援已經發展了很長一段時間了。Solr內建了一個語言自動檢測系統,對多種不同的語言環境都提供特定語言的文本分析方案支援。我們在第6章會瞭解到相關的詳細內容。
1.4.3 Solr 4的新功能
在我們結束本章之前,讓我們來看看Solr 4為我們帶來了哪些新的功能。總體來說第4版對於ApacheSolr社區來說是一個重大的裡程碑,一下子解決掉了Solr使用者多年來在使用中發現的各種痛點和不方便的地方。我們選了幾個功能亮點列在這裡,不過需要指出的是Solr4的各種新功能會貫穿本書的各個章節。
· 幾乎即時的搜尋查詢
· 支援開放式並行存取機制的原子更新
· 即時擷取功能
· 交易記錄的持久層寫入
· 使用Zookeeper輕鬆的進行分區操作和複製操作
• 近乎即時的搜尋查詢
Solr的近乎即時(NRT)查詢功能支援應用在索引建立之後幾秒鐘就可以查詢到新加入的文本。所以利用NRT功能,Solr完全可以應付內容更新會很快的情境,比如頭條新聞或是社交網路之類的應用。我們在第13章會詳細討論NRT。
· 支援開放式並行存取機制的原子更新
原子更新功能允許用戶端應用可以對現有文檔的值域做添加、更新、刪除或是增加等操作而並不用重新發送整個文檔給Solr。例如,如果1.2節中我們的房地產搜尋樣本裡房屋的價格發生了變化,那麼我們可以簡單地發送一個原子更新到Solr更新該條房屋記錄的價格即可,不用重新發送整條房屋記錄的資訊。
你可能疑惑如果兩個不同的用戶端使用者試圖同時更新同一條文檔記錄時會怎麼樣。在這種情況下,Solr會使用開放式並行存取機制來避免會產生衝突的更新。簡言之,Solr會用一個特定的叫做_Version_的值域來加強文檔更新過程中的安全性。當兩個不同使用者試圖同時更新同一文檔時,最後提交更新的使用者會得到到期版本的資料,所以其更新要求會失敗。原子更新和開放式並行存取機制的細節會在第12章中詳細討論。
· 即時擷取功能
在本章的開頭,我們說明了Solr也屬於NoSQL技術的一種。Solr的即時擷取功能絕對符合典型的NoSQL方式,它可以讓你通過文檔的唯一標識獲得最新版本的文檔內容,完全不需要考慮新版本的文檔內容是否提交到了索引當中。這一點和實用Key-value儲存方式的Cassandra很像,都是使用一個原始的key來擷取key對應的最新資料。
而在Solr 4版本之前,常值內容必須先要提交到Lucene索引檔案中之後才能夠被訪問到。而利用Solr4的即時擷取功能,通過唯一標識擷取文檔內容的過程已經安全的同建立Lucene索引的過程分離開了。這在索引已經建立之後對文檔內容進行更新的時候很有用,不用再重新提交文檔內容建立新的索引了。我們在第5章會看到重新提交內容的開銷很大,會影響到查詢的效能。
·持久層寫入
當一個文檔被發送到Solr進行索引的建立時,其內容會被寫入到一個交易記錄中,以避免因為server故障而產生資料的丟失。Solr的交易記錄處於從用戶端應用發送文檔過來,到把文檔內容提交到Lucene索引檔案之間的一個中間狀態。它也參與即時擷取功能的實現,因為不管文檔是否已經提交到了Lucene索引檔案中,其內容都可以通過唯一標識提取出來。
交易記錄使得Solr可以將更新內容的持久化和更新內容的可見度分離開來。這意味著文檔可能會存在於持久化儲存中但是在搜尋結果中並不可見。你自己的應用可以靈活控制何時將新的文檔內容提交到索引中從而使得新文檔內容在搜尋時可以被檢索到。而你並不用擔心如果伺服器在你提交索引之前掛掉的話新文檔內容會丟失的問題。我們會在第5章討論持久層的寫入問題和提交策略問題。
· 使用Zookeeper輕鬆的進行分區操作和複製操作
如果你以前沒用過Solr,那你可能不會理解用之前老版本的Solr進行橫向擴充是多麼麻煩的一件事情。而有了SolrCloud之後,橫向擴充變得很簡單而且自動化了。因為solr使用了ApacheZookeeper來同步配置和管理主分區及分區的複本備份。在Apache的官方網站上是這樣描述Zookeeper的:”這是一個用於維護配置資訊,命名,提供分布式同步和分組服務的中心服務“。
在Solr中,Zookeeper負責指定主分區和分區的複本備份,並且負責監控伺服器是否可以正常的響應查詢請求。SolrCloud已經綁定了Zookeeper服務,所以你不需要再做額外的配置就可以啟動SolrCloud。我們會在第16章中詳細討論SolrCloud相關的內容。
1.5 總結
我們希望現在你已經對Solr典型用例和支援的資料類型有了一個直觀的認識。正如你在1.1節中所學到的,Solr對4類資料的處理做了最佳化,包括以常值內容為中心的資料,讀取遠勝於寫入的資料,面向文檔的資料,以及schema比較靈活的資料。我們也學習到了類似Solr這樣的搜尋引擎並不是通用的資料存放區和處理方案, 而是用來處理關鍵詞搜尋,對結果進行排序,以及協助使用者在結果中瀏覽和發現更符合要求的資訊用的。通過一個虛擬房地產搜尋應用,我們瞭解到了Solr是如何在Lucene的基礎上建立索引的,是如何通過基於HTTP, XML和JSON等方式的網路服務來組態管理索引建立規則的。Solr4可以通過分區功能和複製擴充兩種機制來滿足海量資料的高並發查詢需求。Solr4不會有單點失敗的問題。
我們也分別站在公司不同角色的角度分別討論了選擇Solr可以帶來的一些關鍵的好處。我們看到了Solr是如何解決軟體架構師,系統管理員甚至是公司CEO所可能提出的疑問的。最後,我們粗略的過了一遍Solr的主要功能,並提供了一個閱讀指南,讓你可以迅速的找到感興趣的內容所在的章節。
我們希望看到這裡你會很興奮的想要繼續學習Solr的旅程,那麼現在是時候去下載一個最新的Solr,在你自己的本地機器上運行一下了。在接下來的第二章,我們就一起來做這件事。
struts2 in action 中文版
ChinaJavaWorld裡看到的,下了一看,覺得翻譯的很不錯!這裡把下的地址貼出來,需要的話可以下了看看 www.chinajavaworld.net/non-cgi/usr/48/48_2480.rar
哪可以下到Spring in Action(第二版)中文版?啦
好像現在還沒有人掃描出來。既然你知道這本書好,說明你的格調還不低,何必執著於中文呢?我現在英文版差不多看完了,覺得讀起來還是比較順手的。反觀中文版,我看了幾頁csdn上的免費試讀,當我看到他把JPA譯成“java存留API”,我就覺得譯者不夠專業,沒有繼續往下看了。
總之,還是建議你看英文的(就這本書而言)。如果你覺得自己是在英文不行,那你就找國內那些作者寫的速成書吧~~自己掂量掂量