Elasticsearch對(duì)壘8大競(jìng)品技術(shù)，孰優(yōu)孰劣？

來(lái)自：DBAplus社群

作者介紹

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

序言

青出于藍(lán)，而勝于藍(lán)。

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

• 哪些應(yīng)用場(chǎng)景下使用Elasticsearch最佳？

• 哪些應(yīng)用場(chǎng)景下不使用Elasticsearch最好？

本文僅代表個(gè)人的觀(guān)點(diǎn)，不代表社區(qū)技術(shù)陣營(yíng)觀(guān)點(diǎn)，無(wú)意口水之爭(zhēng)，限于本人的經(jīng)驗(yàn)知識(shí)有限，可能與讀者觀(guān)點(diǎn)認(rèn)知不一致。

競(jìng)爭(zhēng)產(chǎn)品

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

1、Lucene

Lucene是一個(gè)搜索的核心庫(kù)，Elastic也是在Lucene基礎(chǔ)之上構(gòu)建，它們之間的競(jìng)爭(zhēng)關(guān)系是由Lucene本身決定的。

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

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

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

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

• 每個(gè)獨(dú)立業(yè)務(wù)線(xiàn)需求，都需要單獨(dú)構(gòu)建一個(gè)Lucene索引進(jìn)程，業(yè)務(wù)線(xiàn)多了之后，管理是個(gè)麻煩的事情

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

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

Elasticsearch與Lucene核心庫(kù)競(jìng)爭(zhēng)的優(yōu)勢(shì)在于：

• 完美封裝了Lucene核心庫(kù)，設(shè)計(jì)了友好的Restful-API，開(kāi)發(fā)者無(wú)需過(guò)多關(guān)注底層機(jī)制，直接開(kāi)箱即用。

• 分片與副本機(jī)制，直接解決了集群下性能與高可用問(wèn)題。

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

本次的競(jìng)爭(zhēng)中，Elasticsearch完勝。

2、Solr

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

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

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

個(gè)人認(rèn)為有以下幾個(gè)原因：

• ES比Solr更加友好簡(jiǎn)潔，門(mén)檻更低。

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

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

• ES社區(qū)發(fā)展更加活躍，Solr幾乎沒(méi)有專(zhuān)門(mén)的技術(shù)分析大會(huì)。

本次競(jìng)爭(zhēng)中，Elasticsearch完勝。

3、RDBMS

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

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

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

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

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

• 關(guān)系型數(shù)據(jù)庫(kù)側(cè)重均衡性，Elasticsearch側(cè)重專(zhuān)一查詢(xún)速度。

  
  

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

4、OpenTSDB

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

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

Elasticsearch構(gòu)建時(shí)間序列很簡(jiǎn)單，性能也相當(dāng)不錯(cuò)：

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

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

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

除非對(duì)于時(shí)間序列數(shù)據(jù)有非?？量痰谋O(jiān)控需求，否則選擇Elasticsearch會(huì)更加合適一些。

5、HBase

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

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

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

關(guān)于其各種技術(shù)原理就不多說(shuō)了，說(shuō)說(shuō)它的一些使用情況。

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

如果用列式數(shù)據(jù)庫(kù)僅限于Rowkey訪(fǎng)問(wèn)場(chǎng)景，其實(shí)采用Elastic也可以，只要設(shè)計(jì)好 _id，與HBase可以達(dá)到相同的效果。

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

除非對(duì)使用列式數(shù)據(jù)庫(kù)有非?？量痰囊螅駝tElasticsearch更具備通用性，業(yè)務(wù)需求場(chǎng)景適用性更多。

6、MongoDB

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

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

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

• 集群分片副本機(jī)制，ES架構(gòu)設(shè)計(jì)更勝一籌。

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

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

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

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

7、ClickHouse

ClickHouse是一款MPP查詢(xún)分析型數(shù)據(jù)庫(kù)，近幾年活躍度很高，很多頭部公司都引入其中。我們?yōu)槭裁匆肽兀蚩赡芨渌^部公司不太一樣，如下：

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

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

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

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

ClickHouse與Elasticsearch一樣，都采用列式存儲(chǔ)結(jié)構(gòu)，都支持副本分片，不同的是ClickHouse底層有一些獨(dú)特的實(shí)現(xiàn)，如下：

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

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

8、Druid

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

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

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

• Druid更加專(zhuān)注，產(chǎn)品設(shè)計(jì)圍繞Rollup展開(kāi)，Elastic只是附帶；

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

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

• Druid與Elastic的技術(shù)架構(gòu)非常類(lèi)似，都支持節(jié)點(diǎn)職責(zé)分離，都支持橫向擴(kuò)展；

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

關(guān)于Rollup這個(gè)大數(shù)據(jù)分析領(lǐng)域，若有大規(guī)模的Rollup的場(chǎng)景需求，個(gè)人更傾向于Druid。

結(jié)語(yǔ)

總結(jié)：

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

• Elasticsearch在搜索查詢(xún)領(lǐng)域，幾乎完勝所有競(jìng)爭(zhēng)產(chǎn)品，在筆者的技術(shù)?？磥?lái)，關(guān)系型數(shù)據(jù)庫(kù)解決數(shù)據(jù)事務(wù)問(wèn)題，Elasticsearch幾乎解決一切搜索查詢(xún)問(wèn)題。

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

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

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

注：

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

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

---

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

		

長(zhǎng)按訂閱更多精彩▼
			

		
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝