來自：DBAplus社群

作者介紹

李猛(ynuosoft)，Elastic-stack產(chǎn)品深度用戶，ES認證工程師，2012年接觸Elasticsearch，對Elastic-Stack開發(fā)、架構、運維等方面有深入體驗，實踐過多種Elasticsearch項目，最暴力的大數(shù)據(jù)分析應用，最復雜的業(yè)務系統(tǒng)應用；業(yè)余為企業(yè)提供Elastic-stack咨詢培訓以及調優(yōu)實施。

序言

青出于藍，而勝于藍。

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

• 哪些應用場景下使用Elasticsearch最佳？

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

本文僅代表個人的觀點，不代表社區(qū)技術陣營觀點，無意口水之爭，限于本人的經(jīng)驗知識有限，可能與讀者觀點認知不一致。

競爭產(chǎn)品

Elasticseach從做搜索引擎開始，到現(xiàn)在主攻大數(shù)據(jù)分析領域，逐步進化成了一個全能型的數(shù)據(jù)產(chǎn)品，在Elasticsearch諸多優(yōu)秀的功能中，與很多數(shù)據(jù)產(chǎn)品有越來越多的交叉競爭，有的功能很有特色，有的功能只是附帶，了解這些產(chǎn)品特點有助于更好的應用于業(yè)務需求。

1、Lucene

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

在互聯(lián)網(wǎng)2.0時代，考驗各互聯(lián)網(wǎng)公司最簡單的技術要求，就是看他們的搜索做的怎么樣，那時大家的做法幾乎一樣，都基于Lucene核心庫構建一套搜索引擎，剩下的就看各公司的開發(fā)者們的水平。筆者有幸在2012年之前，基于Lucene做過垂直行業(yè)的搜索引擎，遇到很多問題有必要說一下：

• 項目基于Lucene包裝，業(yè)務代碼與核心庫一起構建發(fā)布，代碼耦合度很高，每次有數(shù)據(jù)字段變更，都需要重新編譯打包發(fā)布，這個過程非常的繁瑣，且相當危險。

• 程序重新發(fā)布，需要關閉原有的程序，涉及到進程切換問題。

• 索引數(shù)據(jù)定期全量重新生成，也涉及到新舊索引切換，索引實時刷新等問題，都需要設計一套復雜的程序機制保障

• 每個獨立業(yè)務線需求，都需要單獨構建一個Lucene索引進程，業(yè)務線多了之后，管理是個麻煩的事情

• 當單個Lucene索引數(shù)據(jù)超過單實例限制之后，需要做分布式，這個原有Lucene是沒有辦法的，所以常規(guī)的做法也是按照某特定分類，拆分成多個索引進程，客戶端查詢時帶上特定分類，后端根據(jù)特定分類路由到具體的索引。

• Lucene庫本身的掌控難度，對于功力尚淺的開發(fā)工程師，需要考慮的因素實在太多了，稍微不慎，就會出現(xiàn)很大的程序問題。

Elasticsearch與Lucene核心庫競爭的優(yōu)勢在于：

• 完美封裝了Lucene核心庫，設計了友好的Restful-API，開發(fā)者無需過多關注底層機制，直接開箱即用。

• 分片與副本機制，直接解決了集群下性能與高可用問題。

Elastic近年的快速發(fā)展，市面上已經(jīng)很少發(fā)現(xiàn)基于Lucene構建搜索引擎的項目，幾乎清一色選擇Elasticsearch作為基礎數(shù)據(jù)庫服務，由于其開源特性，廣大云廠商也在此基礎上定制開發(fā)，與自己的云平臺深度集成，但也沒有獨自發(fā)展一個分支。

本次的競爭中，Elasticsearch完勝。

2、Solr

Solr是第一個基于Lucene核心庫功能完備的搜索引擎產(chǎn)品，誕生遠早于Elasticsearch，早期在全文搜索領域，Solr有非常大的優(yōu)勢，幾乎完全壓倒Elastic，在近幾年大數(shù)據(jù)發(fā)展時代，Elastic由于其分布式特性，滿足了很多大數(shù)據(jù)的處理需求，特別是后面ELK這個概念的流行，幾乎完全忘記了Solr的存在，雖然也推出了Solr-Coud分布式產(chǎn)品，但已經(jīng)基本無優(yōu)勢。

接觸過幾個數(shù)據(jù)類公司，全文搜索都基于Solr構建，且是單節(jié)點模式，偶然出現(xiàn)一些問題，找咨詢顧問排查問題，人員難找，后面都遷移到Elasticsearch之上。

現(xiàn)在市面上幾乎大大小小公司都在使用Elasticsearch，除了老舊系統(tǒng)有的基于Solr的，新系統(tǒng)項目應該全部是Elasticsearch。

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

• ES比Solr更加友好簡潔，門檻更低。

• ES比Solr產(chǎn)品功能特點更加豐富，分片機制，數(shù)據(jù)分析能力。

• ES生態(tài)發(fā)展，Elastic-stack整個技術棧相當全，與各種數(shù)據(jù)系統(tǒng)都很容易集成。

• ES社區(qū)發(fā)展更加活躍，Solr幾乎沒有專門的技術分析大會。

本次競爭中，Elasticsearch完勝。

3、RDBMS

關系型數(shù)據(jù)庫與Elasticsarch相比主要優(yōu)點是事務隔離機制無可替代，但其局限性很明顯，如下：

• 關系型數(shù)據(jù)庫查詢性能，數(shù)據(jù)量超過百萬級千萬級之后下降厲害，本質是索引的算法效率不行，B+樹算法不如倒排索引算法高效。

• 關系型數(shù)據(jù)庫索引最左原則限制，查詢條件字段不能任意組合，否則索引失效，相反Elasticserach可以任意組合，此場景在數(shù)據(jù)表關聯(lián)查詢時特別明顯，Elasticsearch可以采用大寬表解決，而關系型數(shù)據(jù)庫不能。

• 關系型數(shù)據(jù)庫分庫分表之后多條件查詢，難于實現(xiàn)，Elasticsearch天然分布式設計，多個索引多個分片皆可聯(lián)合查詢。

• 關系型數(shù)據(jù)庫聚合性能低下，數(shù)據(jù)量稍微多點，查詢列基數(shù)多一點性能下降很快，Elasticsearch在聚合上采用的是列式存儲，效率極高。

• 關系型數(shù)據(jù)庫側重均衡性，Elasticsearch側重專一查詢速度。

  
  

若數(shù)據(jù)無需嚴格事務機制隔離，個人認為都可以采用Elasticsearch替代。若數(shù)據(jù)既要事務隔離，也要查詢性能，可以采用DB與ES混合實現(xiàn)。

4、OpenTSDB

OpenTSDB內(nèi)部基于HBase實現(xiàn)，屬于時間序列數(shù)據(jù)庫，主要針對具有時間特性和需求的數(shù)據(jù)，進行過數(shù)據(jù)結構的優(yōu)化和處理，從而適合存儲具有時間特性的數(shù)據(jù)，如監(jiān)控數(shù)據(jù)、溫度變化數(shù)據(jù)等，小米公司開源監(jiān)控體系open-falcon的就是基于OpenTSDB實現(xiàn)。

Elastic產(chǎn)品本身無意時間序列這個領域，隨著ELK的流行，很多公司采用ELK來構建監(jiān)控體系，雖然在數(shù)值類型上不像時間序列數(shù)據(jù)庫做過特別處理，但由于其便利的使用，以及生態(tài)技術棧的優(yōu)勢，我們也接受了這樣的事實。

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

• 索引創(chuàng)建規(guī)則，可以按年、按月、按周、按星期、按天、按小時等都創(chuàng)建索引，非常便利。

• 數(shù)據(jù)填充方面，定制一個時間字段做區(qū)分排序，其余的字段無需。

• 數(shù)據(jù)查詢方面，除了按實際序列查詢外，還可以有更多的搜索條件。

除非對于時間序列數(shù)據(jù)有非常苛刻的監(jiān)控需求，否則選擇Elasticsearch會更加合適一些。

5、HBase

HBase是列式數(shù)據(jù)庫的代表，其內(nèi)部有幾個致命設計大大限制了它的應用范圍：

• 訪問HBase數(shù)據(jù)只能基于Rowkey，Rowkey設計的好壞直接決定了HBase使用優(yōu)劣。

• 本身不支持二級索引，若要實現(xiàn)，則需要引入第三方。

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

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

如果用列式數(shù)據(jù)庫僅限于Rowkey訪問場景，其實采用Elastic也可以，只要設計好 _id，與HBase可以達到相同的效果。

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

除非對使用列式數(shù)據(jù)庫有非常苛刻的要求，否則Elasticsearch更具備通用性，業(yè)務需求場景適用性更多。

6、MongoDB

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

• 文檔查詢性能，倒排索引/KDB-Tree比B+Tree厲害。

• 數(shù)據(jù)的聚合分析能力，ES本身提供了列式數(shù)據(jù)doc_value，比Mongo的行式要快不少。

• 集群分片副本機制，ES架構設計更勝一籌。

• ES特色功能比MongoDB提供的更多，適用的場景范圍更寬泛。

• 文檔數(shù)據(jù)樣例，ObjectId由MongoDB內(nèi)置自動生成。

公司剛好有個項目，原來數(shù)據(jù)層基于MongoDB設計構建的，查詢問題不少 ，后面成功遷移到Elasticsearch平臺上，服務器數(shù)據(jù)量從15臺降低到3臺，查詢性能還大幅度提升十倍。

拋開數(shù)據(jù)事務隔離，Elasticsearch可以完全替代MongoDB。

7、ClickHouse

ClickHouse是一款MPP查詢分析型數(shù)據(jù)庫，近幾年活躍度很高，很多頭部公司都引入其中。我們?yōu)槭裁匆肽?，原因可能跟其他頭部公司不太一樣，如下：

• 筆者長期從事大數(shù)據(jù)工作，經(jīng)常會碰到數(shù)據(jù)聚合的實時查詢需求，早期我們會選擇一款關系型數(shù)據(jù)庫來做做聚合查詢，如MySQL/PostgreSQL，稍微不注意就很容易出現(xiàn)性能瓶頸。

• 后面引入Elasticsearch產(chǎn)品，其基于列式設計以及分片架構，性能各方面確實明顯優(yōu)于單節(jié)點的關系型數(shù)據(jù)庫。

• Elasticsearch局限性也很明顯，一是數(shù)據(jù)量超過千萬或者億級時，若聚合的列數(shù)太多，性能也到達瓶頸；二是不支持深度二次聚合，導致一些復雜的聚合需求，需要人工編寫代碼在外部實現(xiàn)，這又增加很多開發(fā)工作量。

• 后面引入了ClickHouse，替代Elasticserach做深度聚合需求，性能表現(xiàn)不錯，在數(shù)據(jù)量千萬級億級表現(xiàn)很好，且資源消耗相比之前降低不少，同樣的服務器資源可以承擔更多的業(yè)務需求。

ClickHouse與Elasticsearch一樣，都采用列式存儲結構，都支持副本分片，不同的是ClickHouse底層有一些獨特的實現(xiàn)，如下：

• MergeTree 合并樹表引擎，提供了數(shù)據(jù)分區(qū)、一級索引、二級索引。

• Vector Engine 向量引擎，數(shù)據(jù)不僅僅按列存儲，同時還按向量(列的一部分)進行處理，這樣可以更加高效地使用CPU。

8、Druid

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

Druid樣本數(shù)據(jù)，必須帶有time時間字段。

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

• Druid更加專注，產(chǎn)品設計圍繞Rollup展開，Elastic只是附帶；

• Druid支持多種外接數(shù)據(jù)，直接可以對接Kafka數(shù)據(jù)流，也可以直接對接平臺自身內(nèi)部數(shù)據(jù)；而Elastic僅支持內(nèi)部索引數(shù)據(jù)，外部數(shù)據(jù)需要借助三方工具導入到索引里；

• Druid在數(shù)據(jù)Rollup之后，會丟棄原始數(shù)據(jù)；Elastic在原有索引基礎之后，生成新的Rollup之后的索引數(shù)據(jù)；

• Druid與Elastic的技術架構非常類似，都支持節(jié)點職責分離，都支持橫向擴展；

• Druid與Elastic在數(shù)據(jù)模型上都支持倒排索引，基于此的搜索與過濾。

關于Rollup這個大數(shù)據(jù)分析領域，若有大規(guī)模的Rollup的場景需求，個人更傾向于Druid。

結語

總結：

• Elasticsearch產(chǎn)品功能全面，適用范圍廣，性能也不錯，綜合應用是首選。

• Elasticsearch在搜索查詢領域，幾乎完勝所有競爭產(chǎn)品，在筆者的技術?？磥?，關系型數(shù)據(jù)庫解決數(shù)據(jù)事務問題，Elasticsearch幾乎解決一切搜索查詢問題。

• Elasticsearch在數(shù)據(jù)分析領域，產(chǎn)品能力偏弱一些，簡單通用的場景需求可以大規(guī)模使用，但在特定業(yè)務場景領域，還是要選擇更加專業(yè)的數(shù)據(jù)產(chǎn)品，如前文中提到的復雜聚合、大規(guī)模Rollup、大規(guī)模的Key-Value。

• Elasticsearch越來越不像一個搜索引擎，更像是一個全能型的數(shù)據(jù)產(chǎn)品，幾乎所有行業(yè)都在使用，業(yè)界非常受歡迎。

• Elasticsearch用得好，下班下得早。

注：

• 內(nèi)容來源于筆者實際工作中運用多種技術棧實現(xiàn)場景需求，得出的一些實戰(zhàn)經(jīng)驗與總結思考，提供后來者借鑒參考。

• 本文圍繞Elastic的競爭產(chǎn)品對比僅限概要性分析，粒度較粗，深度有限，之后會有更加專業(yè)深入競爭產(chǎn)品分析文章，敬請期待。

---

特別推薦一個分享架構+算法的優(yōu)質內(nèi)容，還沒關注的小伙伴，可以長按關注一下：
			

		

長按訂閱更多精彩▼
			

		
如有收獲，點個在看，誠摯感謝