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的不斷提升.
?
總結
以上是生活随笔為你收集整理的ElasticSearch vs. Solr的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： @RequestParam注解详解
- 下一篇： application.properti