Categories
程式開發

Elasticsearch對壘8大競品技術,孰優孰劣?


本文由 dbaplus 社群授權轉載。

序言

Elasticsearch對壘8大競品技術,孰優孰劣? 1

Elasticsearch當前熱度排名很高

青出於藍,而勝於藍。

入行Elastic-Stack技術棧很久很久,為了免於知識匱乏眼光局限,有必要到外面的世界看看,豐富自己的世界觀。本篇內容從Elastic的競爭產品角度分析探討。

  • 哪些應用場景下使用Elasticsearch最佳?
  • 哪些應用場景下不使用Elasticsearch最好?

本文僅代表個人的觀點,不代表社區技術陣營觀點,無意口水之爭,限於本人的經驗知識有限,可能與讀者觀點認知不一致。

競爭產品

Elasticseach從做搜索引擎開始,到現在主攻大數據分析領域,逐步進化成了一個全能型的數據產品,在Elasticsearch諸多優秀的功能中,與很多數據產品有越來越多的交叉競爭,有的功能很有特色,有的功能只是附帶,了解這些產品特點有助於更好的應用於業務需求。

Elasticsearch對壘8大競品技術,孰優孰劣? 2

圖片:Elasticsearch競爭圖譜示意圖

1、Lucene

Lucene是一個搜索的核心庫,Elastic也是在Lucene基礎之上構建,它們之間的競爭關係是由Lucene本身決定的。

在互聯網2.0時代,考驗各互聯網公司最簡單的技術要求,就是看他們的搜索做的怎麼樣,那時大家的做法幾乎一樣,都基於Lucene核心庫構建一套搜索引擎,剩下的就看各公司的開發者們的水平。筆者有幸在2012年之前,基於Lucene做過垂直行業的搜索引擎,遇到很多問題有必要說一下:

  • 項目基於Lucene包裝,業務代碼與核心庫一起構建發布,代碼耦合度很高,每次有數據字段變更,都需要重新編譯打包發布,這個過程非常的繁瑣,且相當危險。
  • 程序重新發布,需要關閉原有的程序,涉及到進程切換問題。
  • 索引數據定期全量重新生成,也涉及到新舊索引切換,索引實時刷新等問題,都需要設計一套複雜的程序機制保障
  • 每個獨立業務線需求,都需要單獨構建一個Lucene索引進程,業務線多了之後,管理是個麻煩的事情
  • 當單個Lucene索引數據超過單實例限制之後,需要做分佈式,這個原有Lucene是沒有辦法的,所以常規的做法也是按照某特定分類,拆分成多個索引進程,客戶端查詢時帶上特定分類,後端根據特定分類路由到具體的索引。
  • Lucene庫本身的掌控難度,對於功力尚淺的開發工程師,需要考慮的因素實在太多了,稍微不慎,就會出現很大的程序問題。

Elasticsearch對壘8大競品技術,孰優孰劣? 3

圖示:Lucene內部索引構建與查詢過程

Elasticsearch與Lucene核心庫競爭的優勢在於:

  • 完美封裝了Lucene核心庫,設計了友好的Restful-API,開發者無需過多關注底層機制,直接開箱即用。
  • 分片與副本機制,直接解決了集群下性能與高可用問題。

Elastic近年的快速發展,市面上已經很少發現基於Lucene構建搜索引擎的項目,幾乎清一色選擇Elasticsearch作為基礎數據庫服務,由於其開源特性,廣大雲廠商也在此基礎上定制開發,與自己的雲平台深度集成,但也沒有獨自發展一個分支。

本次的競爭中,Elasticsearch完胜。

2、Solr

Solr是第一個基於Lucene核心庫功能完備的搜索引擎產品,誕生遠早於Elasticsearch,早期在全文搜索領域,Solr有非常大的優勢,幾乎完全壓倒Elastic,在近幾年大數據發展時代,Elastic由於其分佈式特性,滿足了很多大數據的處理需求,特別是後面ELK這個概念的流行,幾乎完全忘記了Solr的存在,雖然也推出了Solr-Coud分佈式產品,但已經基本無優勢。

接觸過幾個數據類公司,全文搜索都基於Solr構建,且是單節點模式,偶然出現一些問題,找諮詢顧問排查問題,人員難找,後面都遷移到Elasticsearch之上。

現在市面上幾乎大大小小公司都在使用Elasticsearch,除了老舊系統有的基於Solr的,新系統項目應該全部是Elasticsearch。

個人認為有以下幾個原因:

  • ES比Solr更加友好簡潔,門檻更低。
  • ES比Solr產品功能特點更加豐富,分片機制,數據分析能力。
  • ES生態發展,Elastic-stack整個技術棧相當全,與各種數據系統都很容易集成。
  • ES社區發展更加活躍,Solr幾乎沒有專門的技術分析大會。

Elasticsearch對壘8大競品技術,孰優孰劣? 4

圖示:Solr產品功能模塊內部架構圖

本次競爭中,Elasticsearch完胜。

3、RDBMS

關係型數據庫與Elasticsarch相比主要優點是事務隔離機制無可替代,但其局限性很明顯,如下:

  • 關係型數據庫查詢性能,數據量超過百萬級千萬級之後下降厲害,本質是索引的算法效率不行,B+樹算法不如倒排索引算法高效。
  • 關係型數據庫索引最左原則限制,查詢條件字段不能任意組合,否則索引失效,相反Elasticserach可以任意組合,此場景在數據表關聯查詢時特別明顯,Elasticsearch可以採用大寬表解決,而關係型數據庫不能。
  • 關係型數據庫分庫分錶之後多條件查詢,難於實現,Elasticsearch天然分佈式設計,多個索引多個分片皆可聯合查詢。
  • 關係型數據庫聚合性能低下,數據量稍微多點,查詢列基數多一點性能下降很快,Elasticsearch在聚合上採用的是列式存儲,效率極高。
  • 關係型數據庫側重均衡性,Elasticsearch側重專一查詢速度。

若數據無需嚴格事務機制隔離,個人認為都可以採用Elasticsearch替代。若數據既要事務隔離,也要查詢性能,可以採用DB與ES混合實現,詳細見筆者的博客文章《DB與ES混合應用之數據實時同步》

Elasticsearch對壘8大競品技術,孰優孰劣? 5

圖示:RDBMS與ES各自優勢示意圖

4、OpenTSDB

OpenTSDB內部基於HBase實現,屬於時間序列數據庫,主要針對具有時間特性和需求的數據,進行過數據結構的優化和處理,從而適合存儲具有時間特性的數據,如監控數據、溫度變化數據等,小米公司開源監控體系open-falcon的就是基於OpenTSDB實現。

Elasticsearch對壘8大競品技術,孰優孰劣? 6

圖示:OpenTSDB時間序列數據庫內部實現

Elastic產品本身無意時間序列這個領域,隨著ELK的流行,很多公司採用ELK來構建監控體系,雖然在數值類型上不像時間序列數據庫做過特別處理,但由於其便利的使用,以及生態技術棧的優勢,我們也接受了這樣的事實。

Elasticsearch構建時間序列很簡單,性能也相當不錯:

  • 索引創建規則,可以按年、按月、按週、按星期、按天、按小時等都創建索引,非常便利。
  • 數據填充方面,定制一個時間字段做區分排序,其餘的字段無需。
  • 數據查詢方面,除了按實際序列查詢外,還可以有更多的搜索條件。

除非對於時間序列數據有非常苛刻的監控需求,否則選擇Elasticsearch會更加合適一些。

5、HBase

HBase是列式數據庫的代表,其內部有幾個致命設計大大限制了它的應用範圍:

  • 訪問HBase數據只能基於Rowkey,Rowkey設計的好壞直接決定了HBase使用優劣。
  • 本身不支持二級索引,若要實現,則需要引入第三方。

關於其各種技術原理就不多說了,說說它的一些使用情況。

公司所屬物流速運行業,一個與車輛有關的項目,記錄所有車輛行駛軌跡,車載設備會定時上報車子的軌跡信息,後端數據存儲基於HBase,數據量在幾十TB級以上,由於業務端需要依據車輛軌跡信息計算它的公里油耗以及相關成本,所以要按查詢條件批量查詢數據,查詢條件有一些非rowkey的字段,如時間範圍,車票號,城市編號等,這幾乎無法實現,原來暴力的做過,性能問題堪憂。此項目的問題首先也在於rowkey難設計滿足查詢條件的需求,其次是二級索引問題,查詢的條件很多。

如果用列式數據庫僅限於Rowkey訪問場景,其實採用Elastic也可以,只要設計好 _id,與HBase可以達到相同的效果。

如果用列式數據庫查詢還需要引入三方組件,那還不如直接在Elasticsearch上構建更直接。

除非對使用列式數據庫有非常苛刻的要求,否則Elasticsearch更具備通用性,業務需求場景適用性更多。

Elasticsearch對壘8大競品技術,孰優孰劣? 7

圖示:列式數據庫內部數據結構示意圖

6、MongoDB

MongoDB是文檔型數據庫的代表,數據模型基於Bson,而Elasticsearch的文檔數據模型是Json,Bson本質是Json的一種擴展,可以相互直接轉換,且它們的數據模式都是可以自由擴展的,基本無限制。 MongoDB本身定位與關係型數據庫競爭,支持嚴格的事務隔離機制,在這個層面實際上與Elasticsearch產品定位不一樣,但實際工作中,幾乎沒有公司會將核心業務數據放在MongoDB上,關係型數據庫依然是第一選擇。若超出這個定位,則Elasticsearh相比MongoDB有如下優點:

  • 文檔查詢性能,倒排索引/KDB-Tree比B+Tree厲害。
  • 數據的聚合分析能力,ES本身提供了列式數據doc_value,比Mongo的行式要快不少。
  • 集群分片副本機制,ES架構設計更勝一籌。
  • ES特色功能比MongoDB提供的更多,適用的場景範圍更寬泛。
  • 文檔數據樣例,ObjectId由MongoDB內置自動生成。

Elasticsearch對壘8大競品技術,孰優孰劣? 8

Elasticsearch對壘8大競品技術,孰優孰劣? 9

公司剛好有個項目,原來數據層基於MongoDB設計構建的,查詢問題不少,後面成功遷移到Elasticsearch平台上,服務器數據量從15台降低到3台,查詢性能還大幅度提升十倍,詳細可閱讀筆者另一篇文章《從MongoDB遷移到ES後,我們減少了80%的服務器

拋開數據事務隔離,Elasticsearch可以完全替代MongoDB。

7、ClickHouse

ClickHouse是一款MPP查詢分析型數據庫,近幾年活躍度很高,很多頭部公司都引入其中。我們為什麼要引入呢,原因可能跟其他頭部公司不太一樣,如下:

  • 筆者長期從事大數據工作,經常會碰到數據聚合的實時查詢需求,早期我們會選擇一款關係型數據庫來做做聚合查詢,如MySQL/PostgreSQL,稍微不注意就很容易出現性能瓶頸。
  • 後面引入Elasticsearch產品,其基於列式設計以及分片架構,性能各方面確實明顯優於單節點的關係型數據庫。
  • Elasticsearch局限性也很明顯,一是數據量超過千萬或者億級時,若聚合的列數太多,性能也到達瓶頸;二是不支持深度二次聚合,導致一些複雜的聚合需求,需要人工編寫代碼在外部實現,這又增加很多開發工作量。
  • 後面引入了ClickHouse,替代Elasticserach做深度聚合需求,性能表現不錯,在數據量千萬級億級表現很好,且資源消耗相比之前降低不少,同樣的服務器資源可以承擔更多的業務需求。

ClickHouse與Elasticsearch一樣,都採用列式存儲結構,都支持副本分片,不同的是ClickHouse底層有一些獨特的實現,如下:

  • MergeTree 合併樹表引擎,提供了數據分區、一級索引、二級索引。
  • Vector Engine 向量引擎,數據不僅僅按列存儲,同時還按向量(列的一部分)進行處理,這樣可以更加高效地使用CPU。

Elasticsearch對壘8大競品技術,孰優孰劣? 9

圖示:ClickHouse在大數據平台中的位置

8、Druid

Durid是一個大數據MPP查詢型數據產品,核心功能Rollup,所有的需要Rollup原始數據必須帶有時間序列字段。 Elasticsearch在6.3.X版本之後推出了此功能,此時兩者產品形成競爭關係,誰高誰下,看應用場景需求。

Druid樣本數據,必須帶有time時間字段。

Elasticsearch對壘8大競品技術,孰優孰劣? 11

筆者之前負責過公司所有Elasticsearch技術棧相關數據項目,當時也有碰到一些實時聚合查詢返回部分數據的需求,但我們的需求不太一樣,索引數據屬於離線型更新,每天都會全部刪除並重新創建索引插入數據,此時使用Elastic的版本是6.8.X,僅支持離線型數據Rollup,所以此功能沒用上,Elastic在7.2.X版本之後才推出實時Rollup功能。

  • Druid更加專注,產品設計圍繞Rollup展開,Elastic只是附帶;
  • Druid支持多種外接數據,直接可以對接Kafka數據流,也可以直接對接平台自身內部數據;而Elastic僅支持內部索引數據,外部數據需要藉助三方工具導入到索引裡;
  • Druid在數據Rollup之後,會丟棄原始數據;Elastic在原有索引基礎之後,生成新的Rollup之後的索引數據;
  • Druid與Elastic的技術架構非常類似,都支持節點職責分離,都支持橫向擴展;
  • Druid與Elastic在數據模型上都支持倒排索引,基於此的搜索與過濾。

Elasticsearch對壘8大競品技術,孰優孰劣? 12

圖示:Druid產品技術架構體系示意圖

關於Rollup這個大數據分析領域,若有大規模的Rollup的場景需求,個人更傾向於Druid。

結語

總結

  • Elasticsearch產品功能全面,適用範圍廣,性能也不錯,綜合應用是首選。
  • Elasticsearch在搜索查詢領域,幾乎完胜所有競爭產品,在筆者的技術棧看來,關係型數據庫解決數據事務問題,Elasticsearch幾乎解決一切搜索查詢問題。
  • Elasticsearch在數據分析領域,產品能力偏弱一些,簡單通用的場景需求可以大規模使用,但在特定業務場景領域,還是要選擇更加專業的數據產品,如前文中提到的複雜聚合、大規模Rollup 、大規模的Key-Value。
  • Elasticsearch越來越不像一個搜索引擎,更像是一個全能型的數據產品,幾乎所有行業都在使用,業界非常受歡迎。
  • Elasticsearch用得好,下班下得早。

  • 內容來源於筆者實際工作中運用多種技術棧實現場景需求,得出的一些實戰經驗與總結思考,提供後來者藉鑑參考。
  • 本文圍繞Elastic的競爭產品對比僅限概要性分析,粒度較粗,深度有限,之後會有更加專業深入競爭產品分析文章,敬請期待。

作者介紹

李猛(ynuosoft),Elastic-stack產品深度用戶,ES認證工程師,2012年接觸Elasticsearch,對Elastic-Stack開發、架構、運維等方面有深入體驗,實踐過多種Elasticsearch項目,最暴力的大數據分析應用,最複雜的業務系統應用;業餘為企業提供Elastic-stack諮詢培訓以及調優實施。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650787901&idx=1&sn=26107e829da02719546da979d50f07a8&chksm=f3f965a8c48eecbef472294ef6c5bc934e137dc7d5bfc776546f090738181947d83231096e5c&scene=27#wechat_redirect