如何使用15美元每月的機(jī)器實現(xiàn)百萬文檔檢索

【編者按】如何在廉價機(jī)器上運(yùn)行一個超過300萬份文檔的搜索？云計算時代，托管搜索服務(wù)很受歡迎，但實際上并不是經(jīng)濟(jì)的選擇，而且也不一定能有效解決問題，Solr是一個基于Lucene的高性能全文搜索服務(wù)器，采用Solr，我們完全可以避免對SaaS的依賴，通過對搜索產(chǎn)品進(jìn)行足夠深入地了解，再進(jìn)行一些實驗，從廉價硬件中獲得高性能是完全可能的，那怎樣才能實現(xiàn)這個過程？系統(tǒng)集成架構(gòu)師Richard Donovan為我們帶來了精彩分析。

以下為譯文：

Gwittr以twitter搜索為人所知，同時它還是一個統(tǒng)計信息的網(wǎng)站，除了提供有關(guān)推文及鏈接網(wǎng)頁的擴(kuò)展搜索，也進(jìn)行數(shù)據(jù)的統(tǒng)計分析。這篇文章重點(diǎn)介紹如何在廉價（< $15/月）機(jī)器上運(yùn)行一個中型、大型搜索（超過300萬份文檔）？

面臨哪些挑戰(zhàn)？

• 把這個問題丟給云計算既不便宜也不一定能得到解決；
• 避免為不必要存儲空間支付過高的費(fèi)用；
• 了解文檔字段定義并針對檢索需求做優(yōu)化；
• 精心設(shè)計查詢；
• 研究提交策略；

這些優(yōu)化對Solr有效，也同樣適用于任何基于Lucene的搜索引擎，比如Elastic Search。

把問題扔給云計算怎么樣？

在這個云計算和EaaS（Everything as a Service，一切皆服務(wù)）時代，對于那些產(chǎn)品需要搜索功能的公司，托管搜索服務(wù)很有吸引力。雖然一秒鐘只收幾美分的云服務(wù)聽起來很劃算，但是到實際應(yīng)用中，每個月很容易就會產(chǎn)生數(shù)百甚至數(shù)千美元的費(fèi)用。

避免這些費(fèi)用的方法就是在vanilla硬件或者虛擬機(jī)上運(yùn)行自己的Solr，這不僅可以幫助你節(jié)省大量的費(fèi)用，而且還會幫助你獲得有關(guān)搜索引擎的技能和知識，利用這些技能和知識，可以幫助你進(jìn)一步節(jié)省大量的開支，即使在你要轉(zhuǎn)用其他搜索平臺的時候，這些知識和技能也是必不可少的。

在Gwittr中，我們可以在非常便宜的虛擬機(jī)中運(yùn)行Solr實例，而且我們還可以在沒有太大延遲的前提下，對數(shù)據(jù)進(jìn)行相當(dāng)高級的統(tǒng)計。于此同時，我們需要遵循以下幾個原則。

搜索不等于存儲

像Solr這樣的搜索引擎不等于數(shù)據(jù)庫存儲，索引是很重要的，如果你忘了這一點(diǎn)，只將搜索索引看成內(nèi)存，那就會產(chǎn)生一些風(fēng)險：

• 數(shù)據(jù)丟失。盡管Solr確實采用了一些保持?jǐn)?shù)據(jù)完整性的技術(shù)，但保證數(shù)據(jù)持久性畢竟不是這些系統(tǒng)的長項。
• 由于Gwittr這樣的流媒體數(shù)據(jù)搜索，搜索專用的存儲將得到快速發(fā)展。如果你正在使用SaaS，那就意味著將數(shù)據(jù)存儲到Solr中或是內(nèi)存中是很有必要的。
• 敏捷性的損失。重建索引以支持新功能是不可避免的，如果不為此做好準(zhǔn)備，將失去敏捷性。

優(yōu)化#1  將搜索索引看作是可任意處理、易于重建的資源，因為當(dāng)你需要引入新的特性時，應(yīng)用程序需要經(jīng)常性、大規(guī)模重建索引。

確定架構(gòu)中的所有字段不通過默認(rèn)方式存儲，這對使用普通的功能已經(jīng)足夠了。一般你不需要在Solr中存儲文檔字段，除非你要使用突出顯示的功能，因為Solr在使用一些突出顯示功能時，需要用到文檔中的初始文本。你也會想要存儲更多的東西，比如文檔標(biāo)識符，因為在應(yīng)用程序代碼中，你可能會用到文檔標(biāo)識符將搜索結(jié)果鏈接回內(nèi)存。

Solr還提供一套擴(kuò)展的字段索引選項，幫助你進(jìn)一步簡化索引的過程。

瀏覽vs.搜索

雖然Solr、Lucene等一系列產(chǎn)品在市場上被稱為“搜索引擎”，但實際上，稱它們?yōu)閮?yōu)越的瀏覽引擎（具有面片化（faceting）功能的瀏覽引擎，這也是一個強(qiáng)有力的賣點(diǎn)）更恰當(dāng)，相比那些開源數(shù)據(jù)庫，它們有極好的文本搜索性能。如果你去了解一下用戶體驗是如何設(shè)計的（包括怎樣才能讓W(xué)eb爬蟲看到你的網(wǎng)站），除非你是Google，如果不是你很有可能會發(fā)現(xiàn)：大多數(shù)情況下，你的用戶在搜索關(guān)鍵字后還會單擊相關(guān)導(dǎo)航功能（面片（facet）以及類似文檔……），至少像Gwittr那樣，讓訪客可以看到所有的結(jié)果，在沒有輸入任何關(guān)鍵字的情況下對數(shù)據(jù)進(jìn)行挖掘。

優(yōu)化#2  在“瀏覽”相關(guān)查詢時，最好使用Solr的過濾器，而不是在“q”參數(shù)中堆砌。Solr過濾的文檔集被緩存，它們沒有進(jìn)行任何相關(guān)性得分的計算，所以，使用它們?yōu)g覽查詢將為你節(jié)省寶貴的I/O和CPU周期。

此外，搜索引擎不會在匹配集中顯示太多的結(jié)果頁，顯示的結(jié)果頁越多，需要的臨時內(nèi)存就越多，結(jié)果獲取的速度也就越慢。就算是Google，搜索的結(jié)果最多也不會超出1000頁。

優(yōu)化#3  在應(yīng)用程序中加入分頁限制。

優(yōu)化#4  只請求那些你需要用來顯示結(jié)果的字段，從而盡量減少I/O和帶寬。

Solr提交不等于RDBMS提交

在數(shù)據(jù)庫中，我們無時不刻不在使用事務(wù)和并發(fā)機(jī)制，在更新操作涉及到許多行或者許多表時，這是確保數(shù)據(jù)完整性的一個正確方法，在Solr中，“提交”有著迥然不同的語義。

你很有可能已經(jīng)知道，在Solr中沒有所謂的“更新”、“數(shù)據(jù)完整性外鍵”或者“多表”，實質(zhì)上，Solr/Lucene只是通過索引形式管理日益增長的文檔集合。每次添加、更新或刪除一個文檔集合，Solr就會向其數(shù)據(jù)目錄中添加一個新“段”（一堆文件），最后段的數(shù)量會越來越大。有一種機(jī)制可以應(yīng)對這種情況，這里就不再贅述。

在Solr中，通過一個Searcher對象可以處理所有的搜索查詢。Searcher建立在索引組成的段的集合上。提交在這里的作用很簡單：“讓Solr生成新的Searcher，包括新段，并以原子方式用它替換當(dāng)前Searcher。”

不要過分追求速度

優(yōu)化#5  避免不惜代價的并發(fā)提交，因為你不停地構(gòu)建新的Searcher，之后又把它扔了。事實上，同時構(gòu)建Searcher會導(dǎo)致在Solr的配置中產(chǎn)生一個顯式設(shè)置對數(shù)目施加嚴(yán)格上限，默認(rèn)值是2。所以如果你同時提交的話，很有可能會獲得異常堆棧，抱怨打開的Searcher太多。

優(yōu)化#6  監(jiān)視建立新Searcher的時間。優(yōu)化在Solr中新建/更新文檔的響應(yīng)時間（流行的說法是“實時”），總的來說就是盡量減少Solr生成一個新Searcher對象的時間。監(jiān)視Solr日志，查找“事件=newSearcher”，然后查找那些行QTime（查詢時間），為的是使時間盡可能合理的短（我們稍后將看到為什么“合理”在這里很重要），因為構(gòu)建新Seacher的速度越快，你可以構(gòu)建的Seacher就越多，插入、更新和刪除的響應(yīng)就越快。

在Solr中有兩個主要的提交策略。第一個策略就是讓Solr在固定的時間間隔完成提交，該方法被稱為自動提交，應(yīng)作為首選策略考慮，它可以幫助你擺脫對應(yīng)用程序的手工管理。事實上，如果你使用了自動提交，那讓應(yīng)用自己提交就成為一個非常糟糕的辦法，記住重疊Searcher的上限也適用于自動提交的Searcher，所以要讓自動提交比構(gòu)建Searcher的時間更長。自動按固定時間間隔提交存在問題――在索引沒有更新時，定期構(gòu)建新的Searcher只是在浪費(fèi)CPU，這也為我們指出提交的第二個策略：

優(yōu)化#7  讓應(yīng)用程序根據(jù)需要執(zhí)行提交。并發(fā)是一個糟糕的辦法，應(yīng)該實施全局的鎖機(jī)制。

給Searcher熱身

你可能會想“構(gòu)建只增加了一個段的新Searcher能有多慢？Solr很好地支持這一點(diǎn)而且肯定會非常快”。你說對了，它的速度確實非常快。

唯一的問題是新Searcher最初的幾個查詢將會非常慢，這并不好。在高容量搜索環(huán)境中，幾個緩慢的查詢可能成為產(chǎn)品的短板，最終影響到應(yīng)用程序?qū)印＿@些最初查詢緩慢背后的原因是新Searcher緩存中填充的東西是無用的。在Solr術(shù)語中，這被稱為“Cold Searcher”。Solr允許使用“Cold Searcher”，但幸運(yùn)的是這僅存在于其他Searcher也沒有被注冊的情況下。也就是說，它只發(fā)生Solr的實例剛開始時。在所有其他情況下，Solr會提供了一些給“Searcher”熱身的機(jī)制，確保在它們被用到服務(wù)請求時，查詢的速度不會太慢。

優(yōu)化#8  有兩組設(shè)置影響到新Searcher的熱身，應(yīng)該將兩者結(jié)合起來使用。

• 一組是設(shè)置Solr對熱身中的Searcher進(jìn)行查詢。針對這些查詢，可以建立幾個實時應(yīng)用程序的典型查詢樣本，使其在移除過濾器后能更通用一些，關(guān)鍵是要盡量包括將在應(yīng)用程序中使用的各個方面，還可以發(fā)出幾個關(guān)鍵字查詢，因為如果有足夠的空間，這種方法會在內(nèi)存中加載全文索引。
• 另一種給新Searcher熱身的方法是在緩存中建立autowarming。高速緩存autowarming是將舊緩存中的值預(yù)先填充到熱身中的Searcher緩存中。

對于熱身中的Searcher關(guān)鍵是要找到建立新Searcher與注冊Searcher在時間上的平衡（建立新Search可以很快――但很危險），找到這個平衡點(diǎn)需要進(jìn)行實驗，而這一切都取決于應(yīng)用程序?qū)拥男枰?/p>

結(jié)論

有了對搜索產(chǎn)品足夠深入地了解，再進(jìn)行一些實驗，從廉價的硬件中獲得高性能是完全可能的，我們完全可以避免對SaaS的依賴，從而節(jié)省大量的費(fèi)用。了解系統(tǒng)的內(nèi)部原理也能在你向SaaS平臺轉(zhuǎn)移時，幫助你作出正確的決定。SaaS是個避免擴(kuò)展和備份等頭痛事情的好辦法，但不要忽略了這些服務(wù)的背后的技術(shù)，不然即使你支付很高的費(fèi)用，也不一定能得到高性能。

原文鏈接：Guerilla Search with Solr - How to run a 3 millions documents search on a $15/Month machine. （翻譯/毛夢琪 責(zé)編/魏偉）

以“ 云計算大數(shù)據(jù) 推動智慧中國 ”為主題的 第六屆中國云計算大會 將于5月20-23日在北京國家會議中心隆重舉辦。產(chǎn)業(yè)觀察、技術(shù)培訓(xùn)、主題論壇、行業(yè)研討，內(nèi)容豐富，干貨十足。 需要購買的朋友，請抓住這最后的機(jī)會，點(diǎn)擊報名！

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈