最近在做一個項目時，客戶要求實現(xiàn)站內(nèi)全文檢索功能，因而接觸到Solr這款開源的企業(yè)級全文搜索 引擎蜓氨。官網(wǎng)：http://lucene.apache.org/solr/

簡單介紹下Solr聋袋。Solr是Apache基金會下一款開源全文搜索引擎產(chǎn)品。它基于Luence封裝而來穴吹。

一下文字摘自一位牛人對《Solr in acion》第一章的翻譯(原文：http://my.oschina.net/fengnote/blog/288569)：

伴隨著社交媒體幽勒、云計算、移動互聯(lián)網(wǎng)和大數(shù)據(jù)等技術(shù)的高速發(fā)展港令，我們正迎來一個令人激動的計算時代啥容。軟件架構(gòu)師們開始面對的主要挑戰(zhàn)之一，便是如何處理全球巨大的用戶基數(shù)所產(chǎn)生及使用的海量數(shù)據(jù)顷霹。此外咪惠，用戶們開始期待在線軟件應(yīng)用永遠(yuǎn)都是穩(wěn)定可用的，并且能夠一直保持響應(yīng)淋淀，這對應(yīng)用就提出了更高的可擴(kuò)展性和穩(wěn)定性需求遥昧。為了滿足這些需求，一些專用的非關(guān)系型數(shù)據(jù)存儲及處理技術(shù)朵纷，統(tǒng)稱為NoSQL（Not Only SQL）技術(shù)炭臭，開始獲得越來越多的青睞。這些系統(tǒng)并不強(qiáng)制要求將所有的數(shù)據(jù)都存儲在曾經(jīng)成為事實上標(biāo)準(zhǔn)的關(guān)系型數(shù)據(jù)模型當(dāng)中袍辞，而是共用了一個通用的設(shè)計模式鞋仍，在數(shù)據(jù)存儲處理引擎和特定的數(shù)據(jù)類型之間進(jìn)行匹配。換句話說搅吁，NoSQL技術(shù)為處理特定數(shù)據(jù)類型的特定類別問題做了性能優(yōu)化威创。由于對可擴(kuò)展性的需求和性能的需求不斷增加，導(dǎo)致各種NoSQL技術(shù)和傳統(tǒng)關(guān)系型數(shù)據(jù)庫開始混合使用谎懦，這種跨界架構(gòu)變得越來越流行肚豺。過去那種一種數(shù)據(jù)處理方案就能吃遍天下的時代已經(jīng)一去不復(fù)返了。

本書主要討論一種特殊的NoSQL技術(shù)党瓮，即Apache Solr详炬。和她的其他非關(guān)系型兄弟們一樣，Solr也為一類特定問題的處理做了優(yōu)化寞奸。具體來說，Solr 是一個可擴(kuò)展的在跳，可快速部署的枪萄，對搜索海量文本中心的數(shù)據(jù)和對返回結(jié)果做相關(guān)性排序方面做了優(yōu)化的企業(yè)級搜索引擎。

這句話讀上去有點拗口猫妙，不過沒關(guān)系瓷翻，我們把這個定義中的亮點分解出來看：

• 可擴(kuò)展性：Solr可以把建立索引和查詢處理的運(yùn)算分布到一個集群內(nèi)的多臺服務(wù)器上。

• 快速部署：Solr是開源軟件，安裝和配置都很方便齐帚，可以根據(jù)安裝包內(nèi)的Sample配置直接上手妒牙。

• 優(yōu)化的搜索功能：Solr搜索夠快。對于復(fù)雜的搜索查詢对妄，Solr可以做到亞秒級的處理湘今，通常幾十毫秒就能處理完一次復(fù)雜查詢

• 海量文本：Solr是針對百萬級以上的海量文本處理而設(shè)計的，可以很好地處理海量數(shù)據(jù)剪菱。

• 文本中心的數(shù)據(jù)：Solr為搜索包含自然語言的文本內(nèi)容做了優(yōu)化摩瞎，比如電子郵件，網(wǎng)頁孝常，簡歷旗们，PDF文檔，或是推特构灸、微博上渴、博客這些社交內(nèi)容等等，都適合用Solr來處理喜颁。

結(jié)果是按相關(guān)性排序的：Solr的搜索返回結(jié)果是按照結(jié)果文檔與用戶查詢之間的相關(guān)程度度做排序的驰贷，保證最相關(guān)的結(jié)果會優(yōu)先返回。

在本書中洛巢，你將學(xué)到如何使用Solr來設(shè)計實現(xiàn)一個可擴(kuò)展的搜索方案括袒。我們的學(xué)習(xí)旅程從了解Solr支持的數(shù)據(jù)類型和典型用例開始。這樣你能更好的理解在整個現(xiàn)代軟件應(yīng)用架構(gòu)全景圖中Solr所處的位置稿茉，以及Solr到底是設(shè)計來處理哪些問題的锹锰。

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

我們猜測你已經(jīng)有了些想法要準(zhǔn)備使用搜索引擎了漓库，否則你也不會翻開這本書恃慧。因此，我們就不浪費(fèi)時間來揣度你到底是為什么開始考慮用Solr的了渺蒿，我們直接來討論點干貨痢士，看看關(guān)于你的數(shù)據(jù)和用例方面， 有哪些問題是你在決定是否使用搜索引擎之前所必須要回答的茂装。這最終會歸結(jié)為如何深刻理解你的數(shù)據(jù)和你的用戶怠蹂，以選用一個合適的技術(shù)來同時滿足二者的需求。我們先從討論一下哪些數(shù)據(jù)屬性是搜索引擎適合處理的少态。

1.1.1 管理文本中心的數(shù)據(jù)

合理選用同數(shù)據(jù)匹配的存儲及處理引擎城侧，是現(xiàn)代軟件應(yīng)用架構(gòu)的標(biāo)志性要求之一。如果你是一個優(yōu)秀的程序員彼妻，那么你應(yīng)該知道要根據(jù)在算法中使用數(shù)據(jù)的方式來選取最合適的數(shù)據(jù)結(jié)構(gòu)嫌佑。比如豆茫，如果你需要實現(xiàn)快速隨機(jī)查找，你就不會使用鏈表結(jié)構(gòu)來存儲數(shù)據(jù)屋摇。同樣的道理也適用于搜索引擎的選取揩魂。這里列出了適合用類似Solr這樣的搜索引擎來處理的數(shù)據(jù)的4種主要特點：

• 文本中心的數(shù)據(jù)

• 讀取遠(yuǎn)多于寫入的數(shù)據(jù)

• 面向文檔的數(shù)據(jù)

• 靈活的Schema

也許在這兒應(yīng)該加上第五個數(shù)據(jù)特性，即：海量數(shù)的據(jù)量炮温，也就是”大數(shù)據(jù)“火脉，但是我們主要關(guān)注的是Solr區(qū)別于其他NoSQL技術(shù)的主要特性，而可以處理海量的數(shù)據(jù)并不是它們的主要區(qū)別之一茅特。

雖然這里列出了類似Solr這樣的搜索引擎可以有效處理的數(shù)據(jù)類型的4個主要特點忘分，但是這只是一個粗略的準(zhǔn)則，并不是一個嚴(yán)格的標(biāo)準(zhǔn)白修。我們來深入的討論一下這些數(shù)據(jù)特性妒峦，看看為什么它們對于搜索來說這么重要。我們現(xiàn)在只關(guān)注概念兵睛，具體的實現(xiàn)細(xì)節(jié)在稍后的章節(jié)討論肯骇。

文本中心的數(shù)據(jù)

你肯定見過有人用“非結(jié)構(gòu)化數(shù)據(jù)“這個術(shù)語來描述搜索引擎處理的數(shù)據(jù)。我們認(rèn)為“非結(jié)構(gòu)化”這個詞有些模糊不清祖很，因為任何一個基于人類語言產(chǎn)生的文檔都是隱含有一定的結(jié)構(gòu)的笛丙。要理解“非結(jié)構(gòu)化”這個術(shù)語你可以認(rèn)為這是從計算機(jī)的角度來看的。在計算機(jī)眼中假颇，文本文檔就是一個字符流胚鸯。這個字符流必須通過特定的語言規(guī)則解析出語義結(jié)構(gòu)，才能被檢索到笨鸡。而這正是搜索引擎的工作所在姜钳。

我們認(rèn)為“文本中心的數(shù)據(jù)”這個詞更適合用來描述Solr處理的數(shù)據(jù)類型。因為搜索引擎的設(shè)計初衷就是用來提取文本數(shù)據(jù)的隱含結(jié)構(gòu)形耗，并生成相關(guān)索引以提高查詢檢索的效率哥桥。“文本中心的數(shù)據(jù)”這個詞隱含表明了文檔中的文本信息包含用戶感興趣的查詢內(nèi)容激涤。當(dāng)然拟糕，搜索引擎也支持非文本數(shù)據(jù)，比如數(shù)字類型的數(shù)據(jù)倦踢，但是其主要強(qiáng)項送滞，還是在于處理基于自然語言的文本數(shù)據(jù)。

前面說的都是“文本”硼一，其實“中心”這個部分也很重要累澡，因為如果你的用戶對于文本部分的內(nèi)容不感興趣，那么搜索引擎可能就不是處理你的問題的最佳選擇般贼。舉個例子，對于一個給員工用來創(chuàng)建差旅支出報告的應(yīng)用，每份報告都包括一些結(jié)構(gòu)化的數(shù)據(jù)哼蛆，比如日期蕊梧，費(fèi)用類型，匯率腮介，數(shù)量等等肥矢，另外每項費(fèi)用后面可能會包含一些備注信息，用于描述該項費(fèi)用的大致情況叠洗。這樣一個應(yīng)用就是一個包含文本信息甘改，但并不是“文本中心的數(shù)據(jù)”的一個例子，因為會計部門在使用這些員工的支出費(fèi)用報告來生成月度支出報告時灭抑，并不會通過查找備注里的文本信息來做十艾，文本在這里并不是其關(guān)心的主要內(nèi)容。簡單來說腾节，就是不是所有包含文本信息的數(shù)據(jù)都適合搜索引擎來處理忘嫉。

所以現(xiàn)在先花幾分鐘好好想想你的數(shù)據(jù)是否是“文本中心的數(shù)據(jù)”“赶伲考慮的重點主要就是數(shù)據(jù)中的文本信息用戶是不是會拿來做檢索庆冕。如果答案是YES，那么搜索引擎很可能是一個好的方案選擇劈榨。我們在第5章和第6章會討論如何利用Solr的文本分析來提取文本數(shù)據(jù)的結(jié)構(gòu)的細(xì)節(jié)访递。

讀取遠(yuǎn)多于寫入的數(shù)據(jù):

另外一個搜索引擎可以高效處理的數(shù)據(jù)特性是“讀取遠(yuǎn)多于寫入的數(shù)據(jù)”。首先同辣，需要聲明的是Solr是允許你更新索引中的現(xiàn)有文檔內(nèi)容的拷姿。你可以把“讀取遠(yuǎn)多于寫入”解讀為對于文檔的讀取操作頻率要遠(yuǎn)遠(yuǎn)高于創(chuàng)建文檔和更新文檔的頻率。但是別狹隘的理解為你就完全不能寫入數(shù)據(jù)了邑闺，或是你會被限制在一個特定頻率之下更新數(shù)據(jù)跌前。事實上Solr4的一個關(guān)鍵特性就是“近乎實時的查詢”，這個功能可以允許你每秒鐘為數(shù)千的文檔建立索引并且?guī)缀趿⒖叹湍懿樵兊竭@些新加入的文檔陡舅。

“讀取遠(yuǎn)多于寫入的數(shù)據(jù)”背后的關(guān)鍵點是你的數(shù)據(jù)在寫入Solr后抵乓，在其生命周期內(nèi)應(yīng)該是要被重復(fù)讀取很多次的。你可以理解為搜索引擎并不是主要用來存儲數(shù)據(jù)的靶衍，而是主要用于查詢存儲的數(shù)據(jù)的（查詢請求是一種讀取操作）灾炭。所以如果你需要很頻繁的更新數(shù)據(jù)，那么搜索引擎可能不太適合你的需求颅眶，其他的NoSQL技術(shù)蜈出，比如Cassandra，可能更適合你的快速隨機(jī)寫入的需求涛酗。

面向文檔的數(shù)據(jù)

到目前為止铡原，我們一直使用更通用的“數(shù)據(jù)”這一術(shù)語偷厦，但是實際中搜索引擎處理的都是文檔數(shù)據(jù)。在搜索引擎中燕刻，一個文檔是由值域(field)組成的獨(dú)立集合只泼，每一個值域都只保存數(shù)據(jù)值，不能再嵌套包含其他值域卵洗。換句話說请唱，在Solr這樣的搜索引擎中，文檔都是扁平結(jié)構(gòu)的过蹂，文檔之間不存在相互依賴關(guān)系十绑。Solr中“扁平”的概念是比較寬松的，一個值域可以保存多個數(shù)據(jù)值酷勺，但是值域不能再嵌套包含子值域本橙。也就是說你可以在一個值域里存儲多個數(shù)據(jù)值，但是你不能往值域里頭嵌套別的值域鸥印。

Solr中這種扁平化的勋功、面向文檔的方式可以很好的處理已經(jīng)文檔化的數(shù)據(jù)，比如網(wǎng)頁库说，博客狂鞋，pdf文檔等等跌帐。那么如果要用solr來處理關(guān)系型數(shù)據(jù)庫中已經(jīng)結(jié)構(gòu)化好的數(shù)據(jù)應(yīng)該怎么辦呢侧纯？這種情況下你需要先把關(guān)系型數(shù)據(jù)庫中跨表存儲的數(shù)據(jù)取出來，去結(jié)構(gòu)化独泞，然后放到扁平化的自包含文檔結(jié)構(gòu)里啰挪。我們會在第三章學(xué)習(xí)怎么處理這樣的問題信不。

你還需要考慮你的文檔數(shù)據(jù)中的哪些值域需要存儲在Solr中，哪些值域需要存儲在其他系統(tǒng)中（比如數(shù)據(jù)庫中）亡呵。簡單來說抽活，搜索引擎只存儲需要被檢索到的數(shù)據(jù)，以及用于顯示檢索結(jié)果的數(shù)據(jù)锰什。舉個例子下硕，如果你有一個在線視頻的搜索索引，你應(yīng)該不會希望把視頻文件本身存儲在Solr中汁胆，合理的方案應(yīng)該是把大的視頻文件都放在內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）中梭姓。通常你只需要在搜索引擎中存儲滿足搜索需求的最少數(shù)據(jù)即可。剛才這個在線視頻的例子清楚的說明了不要把Solr當(dāng)成通用數(shù)據(jù)存儲技術(shù)嫩码，Solr的工作是找到用戶感興趣的視頻文件誉尖，而不是存儲視頻文件本身。

靈活的Schema

最后一個搜索引擎數(shù)據(jù)的主要特性是有靈活的schema铸题。這意味著查詢索引中的文檔不需要擁有統(tǒng)一的結(jié)構(gòu)铡恕。在關(guān)系型數(shù)據(jù)庫中琢感，表中的每一行數(shù)據(jù)都必須擁有相同的結(jié)構(gòu)。而在Solr中没咙，文檔們可以有不同的值域猩谊。當(dāng)然同一個索引中的文檔們至少應(yīng)該擁有一部分大家都有的值域以便于檢索千劈，但是并不要求所有文檔中的值域結(jié)構(gòu)完全一樣祭刚。

舉個例子，假如要做一個用于查找出租和出售房源的搜索應(yīng)用墙牌。顯然每條房源文檔都會有地段涡驮，房間數(shù)，衛(wèi)生間數(shù)等一些共有的值域喜滨，但是根據(jù)類型是出租還是出售的不同捉捅，不同的房源文檔會有不同的值域。一條出售的房源會有售價值域虽风，財產(chǎn)稅值域棒口，而一條出租的房源文檔則會有月租金和寵物政策等等不同的值域。

總結(jié)一下辜膝，Solr這樣的搜索引擎是專門優(yōu)化用于處理文本中心的无牵，讀取遠(yuǎn)多于寫入的，面向文檔的厂抖，擁有靈活Schema的數(shù)據(jù)用的茎毁。Solr并不是一種通用數(shù)據(jù)存儲處理技術(shù)，這也是區(qū)別于其他NoSQL技術(shù)的主要因素忱辅。

有眾多不同的數(shù)據(jù)存儲和處理方案可供選擇的好處是你不再需要費(fèi)勁腦汁地尋找一種可以滿足所有需求的通用技術(shù)方案七蜘。搜索引擎在某些特定任務(wù)上表現(xiàn)出色，但是在其他一些方面性能很差墙懂。這意味著在大多數(shù)情況下橡卤，你可以用Solr來作為關(guān)系型數(shù)據(jù)庫和其他NoSQL技術(shù)的有力補(bǔ)充，而并不是要取代后者损搬。

既然我們已經(jīng)談到了Solr所針對優(yōu)化處理的數(shù)據(jù)類型碧库，那我們就接著來討論一下像solr這樣的搜索引擎主要是設(shè)計來解決哪些實際用例的。理解這些用例可以幫助你理解搜索引擎技術(shù)是如何區(qū)別于其他數(shù)據(jù)處理技術(shù)的场躯。

1.1.2 常見的搜索引擎用例

在這一節(jié)中谈为，我們來看看Solr這樣的搜索引擎都能干些什么。正如我們在1.1.1節(jié)中所提到的那樣踢关，這些討論只是一種指南性質(zhì)的建議伞鲫，不要把它們當(dāng)成嚴(yán)格的使用規(guī)則來看。在我們開始之前签舞，你需要意識到想做出一個優(yōu)秀的搜索服務(wù)秕脓，其門檻是很高的∑獍辏現(xiàn)在的用戶都習(xí)慣于使用像Google和Bing這樣又快又高效的網(wǎng)絡(luò)搜索引擎，而很多受歡迎的網(wǎng)站也有自己強(qiáng)大的搜索方案來幫助用戶快速的獲取想要的信息吠架， 所以用戶對搜索服務(wù)并不陌生并且會非常的挑剔芙贫。當(dāng)你在評估像Solr這樣的搜索引擎時，或是在設(shè)計你自己的搜索方案時傍药，一定要有根弦兒磺平，要把用戶體驗放在高優(yōu)先級上來考慮。

基本的關(guān)鍵字查詢

很明顯拐辽，作為一個搜索引擎來說拣挪， 首先必須要能夠支持基本的關(guān)鍵詞查詢。這也是搜索引擎的主要功能之一俱诸。不過關(guān)鍵詞查詢功能還是值得在這里強(qiáng)調(diào)一下的菠劝，因為這是用戶使用搜索引擎最典型的方式。很少有用戶想要會一上來就填寫一個很完整的復(fù)雜搜索表單來進(jìn)行搜索的睁搭「险铮考慮到關(guān)鍵詞搜索功能將會是用戶和你的搜索引擎之間最常見的交互方式，這個基本功能必須能夠提供給用戶以非常好的用戶體驗才行园骆。

一般來說舔痪，用戶希望只輸入幾個簡單的關(guān)鍵詞就能獲取到很好的搜索結(jié)果。這也許聽上去像是一個簡單的匹配任務(wù)：把查詢字串和文檔進(jìn)行匹配即可遇伞。不過請考慮一下要實現(xiàn)良好的用戶體驗所必須解決的幾個問題：

· 相關(guān)結(jié)果必須迅速返回辙喂，大多數(shù)情況下要求一秒鐘之內(nèi)就能夠返回

· 用戶的查詢字串出現(xiàn)拼寫錯誤時能夠自動糾錯

· 用戶輸入時通過自動補(bǔ)全建議來減少用戶的輸入負(fù)擔(dān)，這在移動應(yīng)用中很常見

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

· 對包含查詢字串的語言變異的文檔進(jìn)行匹配（譯者注：語言變異是語義學(xué)術(shù)語鸠珠，即用詞不完全一樣的近似表達(dá)）

· 短語處理巍耗，用戶是希望匹配短語中所有的單詞，還是只要匹配短語中的部分單詞就行

· 對一些通用介詞的處理渐排，比如“a,” “an”, “of”, “the”等等

· 如果最靠前的查詢結(jié)果用戶不滿意炬太， 如何給用戶返回更多的查詢結(jié)果

就像你看到的那樣，不使用特定的處理方法的話驯耻，這樣一堆問題會使得看上去如此簡單的功能實現(xiàn)起來變得很困難亲族。然而利用像Solr這樣的搜索引擎，這些功能就能立等可取可缚，實現(xiàn)起來變得很簡單霎迫。當(dāng)你給用戶提供了一個強(qiáng)大的關(guān)鍵詞搜索工具之后，接下來你就需要考慮如何去展示查詢的結(jié)果帘靡，這就引出了下一個用例知给，按照結(jié)果同查詢請求之間的相關(guān)性順序，對搜索返回的查詢結(jié)果進(jìn)行排序。

排序的檢索結(jié)果

搜索引擎為查詢返回“最靠前“的結(jié)果涩赢。在SQL查詢關(guān)系型數(shù)據(jù)庫的時候戈次，某一行數(shù)據(jù)記錄要么匹配查詢被返回，要么不匹配查詢被忽略筒扒，查詢結(jié)果也是按照數(shù)據(jù)記錄的某一列屬性來排序的怯邪。而對于搜索引擎來說，返回的結(jié)果文檔是按照得分做降序排列的花墩，該得分表示文檔和查詢的匹配程度悬秉。匹配程度得分依據(jù)一系列的因子來計算，不過一般說來得分越高观游，表明結(jié)果文檔同查詢之間的相關(guān)度越高搂捧。

有好幾個因素決定了將結(jié)果文檔按照相關(guān)度排序的方式很重要。首先懂缕，現(xiàn)代搜索引擎一般都存儲著海量的文檔，都是上百萬甚至數(shù)十億記的王凑。如果不對查詢結(jié)果進(jìn)行相關(guān)度排序搪柑，那用戶就會被海量的返回結(jié)果所淹沒，無法清晰有效的瀏覽搜索的結(jié)果索烹。其次工碾，用戶使用其他搜索引擎的經(jīng)驗使得用戶已經(jīng)習(xí)慣于使用少數(shù)的幾個關(guān)鍵詞就能獲得不錯的查詢結(jié)果，也使得用戶普遍比較缺乏耐心百姓。他們會期待搜索引擎按照他們想要的意思來工作渊额，而不管其所輸入的信息是否完全正確。比如對于移動應(yīng)用的后臺搜索服務(wù)來說垒拢，用戶會期待在輸入了簡短的幾個可能還包含有拼寫錯誤的查詢詞之后旬迹，搜索服務(wù)就能夠返回正確的搜索結(jié)果。

如果要人工干預(yù)排序的結(jié)果求类，你可以給特定的文檔奔垦、值域、或者查詢字串增加權(quán)重尸疆，或著直接提高某個文檔的相關(guān)度分值椿猎。比如你如果希望把新加入的文檔推送到最靠前的位置，就可以通過按照創(chuàng)建時間來提高文檔排序的方式實現(xiàn)寿弱。我們在第三章中會學(xué)習(xí)關(guān)于文檔排序的知識犯眠。

除了關(guān)鍵詞查詢之外

利用像Solr這樣的搜索引擎，用戶可以輸入少數(shù)幾個關(guān)鍵詞就能獲取到一些搜索結(jié)果症革。然而對于很多用戶來說這僅僅是一個查詢交互的第一步筐咧。他們需要在查詢結(jié)果中能夠繼續(xù)地瀏覽。驅(qū)動一個信息發(fā)現(xiàn)的交互會話過程也是搜素引擎的一個主要應(yīng)用場景地沮。通常用戶在搜索前并不是很精確的知道想要查詢的信息什么樣的嗜浮，他們事先也不知道你的系統(tǒng)中到底存儲了哪些信息羡亩。一個好的搜索引擎可以幫助用戶不斷地細(xì)化信息需求，一步步到達(dá)最需要的信息危融。

這里的核心思想是在返回用戶最初的查詢所對應(yīng)的文檔結(jié)果的同時畏铆，提供給用戶一個工具，使其能夠不斷地改進(jìn)查詢以獲得更需要的信息吉殃。換句話說辞居，在返回匹配的文檔之外，你應(yīng)該返回一個工具讓用戶知道下一步該怎么辦蛋勺。舉個例子瓦灶，你可以對查詢結(jié)果按照屬性進(jìn)行分類，便于用戶根據(jù)需求做進(jìn)一步的瀏覽抱完。這種功能稱之為分類檢索（Faceted-Search）贼陶，這也是Solr的功能亮點之一。我們會在1.2節(jié)中看到一個關(guān)于房地產(chǎn)的分類檢索實例巧娱，在第八章中會詳細(xì)介紹分類檢索功能的細(xì)節(jié)碉怔。

搜索引擎不適合做的事…

最后，我們來討論一下不適合應(yīng)用搜索引擎的一些用例場景禁添。首先撮胧，搜索引擎一般的設(shè)計是，為每個查詢返回一個小的文檔集老翘，通常包含10個到100個的結(jié)果文檔芹啥。更多的結(jié)果文檔可以通過Solr自帶的結(jié)果分頁功能來獲取。對于一個查詢結(jié)果有好幾百萬個文檔的情況铺峭，如果你要求所有的匹配文檔都要能夠一次返回墓怀，那么你會等待很長的時間。查詢本身會執(zhí)行的很快逛薇，但是從索引結(jié)構(gòu)中重建上百萬的文檔絕對是一件很耗時間的事情捺疼。因為Solr這樣的搜索引擎在硬盤上存儲值域的方式只適用于快速生成少量的文檔結(jié)果，如果需要一次生成大量的查詢結(jié)果永罚，在這種存儲方式之下生成大量文檔結(jié)果就會耗費(fèi)大量的時間啤呼。

另一個不適合應(yīng)用搜索引擎的使用場景是需要讀取索引文件的大部分子集的才能完成的深度分析任務(wù)場景。即使你通過結(jié)果分頁技術(shù)避免了剛剛說的那個問題呢袱，如果一次分析需要讀取索引文件中的大量數(shù)據(jù)官扣，你也會遇到很大的性能問題，因為索引文件的底層數(shù)據(jù)結(jié)構(gòu)就不是為一次大量讀取來設(shè)計的羞福。

我們前面有提到過一點惕蹄，但是在這里還是要再次強(qiáng)調(diào)一下，那就是搜索引擎技術(shù)并不適合用于在文檔的相互關(guān)系之間進(jìn)行查詢。Solr確實是可以支持基于父子關(guān)系的查詢卖陵，但是并不支持在復(fù)雜的關(guān)系型數(shù)據(jù)結(jié)構(gòu)之間查詢遭顶。在第三章，你會學(xué)習(xí)到如何將關(guān)系型數(shù)據(jù)結(jié)構(gòu)適配到適合solr處理的扁平型文檔結(jié)構(gòu)中進(jìn)行查詢泪蔫。

最后棒旗，絕大多數(shù)搜索引擎都沒有直接的文檔級安全支持，至少Solr是沒有撩荣。如果你需要嚴(yán)格管理文檔的權(quán)限铣揉，那你只能在搜索引擎之外來想辦法。

到這里我們已經(jīng)了解了適合搜索引擎處理的用例場景和數(shù)據(jù)類型餐曹，下一步該是時候討論Solr到底能做些什么逛拱，以及這些功能是如何實現(xiàn)的了。在下一節(jié)中台猴，你將學(xué)習(xí)到Solr到底有哪些主要功能朽合，以及她是如何實現(xiàn)外部系統(tǒng)集成、可擴(kuò)展性卿吐、以及高可用性等軟件設(shè)計原則的旁舰。