序言

青出于藍桌吃，而勝于藍。

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

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

?哪些應(yīng)用場景下不使用Elasticsearch最好契邀？

本文僅代表個人的觀點摆寄，無意口水之爭，限于本人的經(jīng)驗知識有限坯门，可能與讀者觀點認知不一致微饥。

競爭產(chǎn)品

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

1始锚、 Lucene

Lucene是一個搜索的核心庫,Elastic也是在Lucene基礎(chǔ)之上構(gòu)建，它們之間的競爭關(guān) 系是由Lucene本身決定的喳逛。

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

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

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

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

每個獨立業(yè)務(wù)線需求，都需要單獨構(gòu)建一個Lucene索引進程贸弥，業(yè)務(wù)線多了之后窟坐，管理 是個麻煩的事情。

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

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

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

?完美封裝了 Lucene核心庫蝴乔，設(shè)計了友好的Restful-API记餐，開發(fā)者無需過多關(guān)注底層機 制，直接開箱即用薇正。

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

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

2疾渣、Solr

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

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

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

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

-ES比Solr更加友好簡潔，門檻更低似炎。

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

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

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

3瘩扼、RDBMS

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

?關(guān)系型數(shù)據(jù)庫查詢性能集绰，數(shù)據(jù)量超過百萬級千萬級之后下降厲害规辱，本質(zhì)是索引的算法效 率不行，B+樹算法不如倒排索引算法高效栽燕。

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

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

?關(guān)系型數(shù)據(jù)庫聚合性能低下猛计，數(shù)據(jù)量稍微多點唠摹，查詢列基數(shù)多一點性能下降很快， Elasticsearch在聚合上采用的是列式存儲奉瘤，效率極高勾拉。

?關(guān)系型數(shù)據(jù)庫側(cè)重均衡性，Elasticsearch側(cè)重專一查詢速度盗温。

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

4、OpenTSDB

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

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

Elasticsearch構(gòu)建時間序列很簡單澄惊，性能也相當不錯：

?索引創(chuàng)建規(guī)則唆途，可以按年富雅、按月、按周肛搬、按星期没佑、按天、按小時等都創(chuàng)建索引温赔，非常便 利蛤奢。

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

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

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

5志衍、HBase

H Base是列式數(shù)據(jù)庫的代表，其內(nèi)部有幾個致命設(shè)計大大限制了它的應(yīng)用范圍： ?訪問HBase數(shù)據(jù)只能基于Rowkey聊替，Rowkey設(shè)計的好壞直接決定了 HBase使用優(yōu)劣足画。

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

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

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

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

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

除非對使用列式數(shù)據(jù)庫有非晨咚苛刻的要求陈症，否則Elasticsearch更具備通用性蔼水，業(yè)務(wù)需求場 景適用性更多震糖。

6、MongoDB

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

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

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

?集群分片副本機制寒瓦，ES架構(gòu)設(shè)計更勝一籌。

? ES特色功能比MongoDB提供的更多坪仇，適用的場景范圍更寬泛孵构。

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

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

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

7望伦、Clickhouse

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

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

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

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

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

ClickHouse與Elasticsearch 一樣堰塌，都采用列式存儲結(jié)構(gòu)，都支持副本分片分衫，不同的是 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) 品形成競爭關(guān)系太抓，誰高誰下空闲，看應(yīng)用場景需求。

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

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

結(jié)語

總結(jié)：

Elasticsearch產(chǎn)品功能全面影斑，適用范圍廣给赞，性能也不錯机打，綜合應(yīng)用是首選。

Elasticsearch在搜索查詢領(lǐng)域片迅，幾乎完勝所有競爭產(chǎn)品残邀，在筆者的技術(shù)棧看來柑蛇，關(guān)系型 數(shù)據(jù)庫解決數(shù)據(jù)事務(wù)問題芥挣，Elasticsearch幾乎解決一切搜索查詢問題。

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

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

Elasticsearch用得好，下班下得早映挂。

本文分享就到這里了泽篮，入想要了解更多Elasticsearch的盗尸，小編在此也整理了一些資料《Elasticsearch實戰(zhàn)》、《Elasticsearch筆記》帽撑、《Elasticsearch面試題》等振劳，如有需要關(guān)注微信公眾號“老周扯IT”進行領(lǐng)取油狂！