[譯]ElasticSearch vs. Solr

爲什麼日誌服務商Loggly選擇ElasticSearch而非Solr.
原文連接: http://loggly.wpengine.com/bl...

在Gen2產品的早期階段, 咱們事實上是失敗的, 這促使咱們從新審視咱們現有的技術棧. 咱們仔細分析系統中的每一個獨立的組件,並記錄下來, 固然其中也包括構成咱們核心功能的搜索引擎技術.

在咱們的通用日誌管理系統場景中, 提供了對每條單獨日誌事件的查詢以及對全部日誌事件的分析圖表以幫助客戶他們瞭解他們的數據動態. 解決這些場景的基本要求以下:

• 一個可擴展且高容錯能力的日誌收集管道. 咱們團隊使用了Apache Kafka做爲數據管道;須要強調的是若是你須要爲任何一個搜索引擎訂閱大量數據, 你須要一個穩定的管道系統.

• 強大的搜索能力: 能給大量的數據提供準實時的索引支持, 同時也能提供高可用的搜索請求.

在咱們的第一代產品Gen1(2010)時, 咱們使用了當時具備雲處理能力而且提供NRT(near real-time)搜索功能的Solr, 恰好Solr的這兩項功能正是咱們所須要的. 起初基於初版具備雲能力支持的Solr分支開始了咱們系統的構建. 因爲一些緣由, 穩定版的SolrCloud + NRT功能直到2012年才基本可用. 那段時間, 咱們經過插件和直接修改源代碼的形式持續擴展和使用Solr.

在2012年, 咱們準備啓動Gen2, 當時SolrCloud4.0剛剛發佈, 同時ElasticSearch也有了0.19.9版本. 在技術調研的時候,我是Solr技術的強烈支持者, 然而通過幾個月的對比, 我終於意識到ElasticSearch纔是咱們更好的選擇.

在任何技術選型過程當中, 總有不少考慮因素. 下面是當時促使咱們選擇ElasticSearch的一些重要考慮. 不過這些總結是基於2012年時候的場景, 最近幾年可能已經發生了翻天覆地的變化.

1) 搜索特性

由於ES和Solr都是基於Lucene構建, 因此不管選擇哪一個都能提供咱們所須要的搜索特性. 然而由於每一個系統的發展歷程及其設計目標又讓咱們必須面對和區分他們的強項和不足.

Solr的設計目標主要是爲了解決困難的信息檢索(IR: information retrieval)問題. 這也反映在它的API設計上, 比ES提供了更強大的搜索能力. ES, 如其名稱所述, 主要是定位在彈性擴展能力, 所以在IR特性上稍有欠缺. 就咱們的業務場景, 並不須要當即使用這些複雜的高級特性. 儘管Solr具備更好的搜索技術優點, 然而ES知足了咱們當前的需求並所以勝出.

2) 搜索擴展性

由於在Gen1中已經使用了Solr, 因此咱們有能力對Solr進行擴展, 而且掌握瞭如何管理以及Solr在這方面的一些限制. ES有所不一樣, 咱們必須驗證它的擴展能力能夠知足咱們的需求.

咱們開始爲每一個系統各部署一個集羣, 並經過加載大量的數據進行極限測試, 以及經過強制關停部分節點以觀察每一個系統的表現. 那個時候, 咱們就像一羣搗亂的猴子.

在測試中發現SolrCloud最大的問題在於它的集羣管理能力. 同時在內存不足時, SolrCound也面臨着穩定性的穩定. 另外還遇到了集羣鎖定(lock-up)問題, 只能整個集羣的重啓才能解決. 與此同時, 一樣的場景下ES並未遇到不可恢復的失敗. 雖然也有辦法能讓ES丟失數據, 但咱們清楚的知道何時會發生, 並能有辦法解決這些問題.

3)配置管理

在Gen1中, 咱們耗費了大量的精力來處理Solr的配置管理,包括數據流向以及索引和分片的管理等. 當時咱們經過一系統的插件以及源代碼修改來處理的.雖然這項技術挑戰讓人興奮, 但咱們並不想在這上面耗費太多時間, 而是把更多的精力放在產品差別化上: 更好的展現經過引擎獲取和分析後的結果, 並給客戶提供更好的數據內涵.

毫無疑問, ES贏得了這項比較. 由於ES團隊對靈活性的追求幾近瘋狂. 具體以下:

• Solr的Collections API是最新提供的,而且很是簡陋.而ES則提供了原生的, 穩定的索引管理功能.

• Solr和ES都默認提供了合理的分片分配策略, 但ES的路由框架相比Solr的Collections API更強大可靠.

• 咱們曾討論過ES的Master/Slave模型是否不如Solr的分佈式模型,事實上功能實現的質量遠比完美的理論更重要.

4) 性能

儘管ES和Solr都基於Lucene, 但在咱們的性能測試過程當中發現了他們在使用方式上的不一樣. 在索引速度上, Solr無疑更高效, 以下圖所示:

上圖中每一個結點都是一組獨立的測試結果, 在每一組中咱們在一個固定的時間週期(2,5,10,20分鐘等等)裏每次批量索引8000次. 在測試結果中能夠清楚的看到結果被分紅了兩組: Solr基本上能穩定的索引18000次/秒, 而ES在開始的時候速度至關(雖然也不太穩定), 但隨着測試時間變長, ES的索引速度降低不能承受12000次/秒.

儘管看起來Solr贏了, 但很大的變數可能在於Solr使用的是Lucene4, 而ES使用的是Lucene3.6.因此很難客觀的說哪一個更好. 而且ES也將引入Lucene4, 因此這項差別應該也將會不復存在.

最終, 在咱們的決定中性能只做爲一個參考因素而非決定因素.

5) 社區支持

ES和Solr都是開源項目, 而且社區都很活躍. 咱們討論了ES和Solr的模型在理論上的不一樣, 更傾向於Solr的開放模型, 同時也對ES團隊的管理工做印象深入. 雖然Solr在社區的規模和活躍度上都佔優點, 但ES也在快速增加,而且增加速度飛快.

6) 其餘因素

咱們對這兩個產品還有不少討論, 下面再簡單看下其中的幾個:

• ES的API很是優雅強大, 而且其REST服務很是適合咱們先後端分離的架構

• ES的掃描和過濾特性很是有趣, 而且發現了不少可能的使用場景

• 都原生支持JSON數據格式, 能節省不少咱們曾在Loggly Gen1中寫的代碼

• ES的類型自動解析和Solr的動態字段都很是有用, 能夠避免對持續演進的輸入數據的管理

• Solr4原生的分層/中心模型很贊

• ES的內存管理比Solr更簡單

• 兩者對插件支持都很是好, 但Solr支持更核心層的插件

還有一些咱們並未執拗堅持的因素, 以下;

• 索引一旦建立, 都不容許動態修改分片數量

• ES只有單層模型, 不過也不要緊

• 在ES中使用主分片和副本分片有數據不一致的狀況, 在一個準實時系統中可能會帶來潛在問題

在討論的最後, 咱們認爲這些影響並非很是嚴重. 隨着討論的深刻, 咱們更清晰的意識到哪些因素對系統具備更深的影響, 相應的這些因素被賦予了更高的權重.

咱們的選擇

最後, 基於如下兩點, 咱們選擇了ES:

• 咱們但願減小在配置管理上的精力, 更多的關注產品自己

• 咱們相信隨着ES的強大, 一些相比於Solr的不一樣也會逐步解決

固然這個選擇也會有所付出. 雖然須要把ES配置歸入咱們的管道, 而且先後端和架構團隊須要實現管道管理, 但相比在Gen1中的付出, 這些都是更高層次的工做. 因此咱們能夠更聚焦在本身的產品自己, 這也是開始時所想要的, 也是咱們的客戶所須要獲得的.

隨着SolrCloud和ElasticSearch的成熟, 差距的縮小, 今天很難再對兩者進行決擇. 不過對你們來講,這確是件好事: 兩者的較力驅使它們以及Lucene的不斷提高.