Elasticsearch當前熱度排名很高
青出於藍，而勝於藍。
入行Elastic-Stack技術棧很久很久，爲了免於知識匱乏眼光侷限，有必要到外面的世界看看，豐富自己的世界觀。本篇內容從Elastic的競爭產品角度分析探討。
-
哪些應用場景下使用Elasticsearch最佳？
-
哪些應用場景下不使用Elasticsearch最好？
本文僅代表個人的觀點，不代表社區技術陣營觀點，無意口水之爭，限於本人的經驗知識有限，可能與讀者觀點認知不一致。
競爭產品
Elasticseach從做搜索引擎開始，到現在主攻大數據分析領域，逐步進化成了一個全能型的數據產品，在Elasticsearch諸多優秀的功能中，與很多數據產品有越來越多的交叉競爭，有的功能很有特色，有的功能只是附帶，瞭解這些產品特點有助於更好的應用於業務需求。
圖片：Elasticsearch競爭圖譜示意圖
1、Lucene
Lucene是一個搜索的核心庫，Elastic也是在Lucene基礎之上構建，它們之間的競爭關係是由Lucene本身決定的。
在互聯網2.0時代，考驗各互聯網公司最簡單的技術要求，就是看他們的搜索做的怎麼樣，那時大家的做法幾乎一樣，都基於Lucene核心庫構建一套搜索引擎，剩下的就看各公司的開發者們的水平。筆者有幸在2012年之前，基於Lucene做過垂直行業的搜索引擎，遇到很多問題有必要說一下：
-
項目基於Lucene包裝，業務代碼與核心庫一起構建發佈，代碼耦合度很高，每次有數據字段變更，都需要重新編譯打包發佈，這個過程非常的繁瑣，且相當危險。
-
程序重新發布，需要關閉原有的程序，涉及到進程切換問題。
-
索引數據定期全量重新生成，也涉及到新舊索引切換，索引實時刷新等問題，都需要設計一套複雜的程序機制保障
-
每個獨立業務線需求，都需要單獨構建一個Lucene索引進程，業務線多了之後，管理是個麻煩的事情
-
當單個Lucene索引數據超過單實例限制之後，需要做分佈式，這個原有Lucene是沒有辦法的，所以常規的做法也是按照某特定分類，拆分成多個索引進程，客戶端查詢時帶上特定分類，後端根據特定分類路由到具體的索引。
-
Lucene庫本身的掌控難度，對於功力尚淺的開發工程師，需要考慮的因素實在太多了，稍微不慎，就會出現很大的程序問題。
圖示：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幾乎沒有專門的技術分析大會。
圖示：Solr產品功能模塊內部架構圖
本次競爭中，Elasticsearch完勝。
3、RDBMS
關係型數據庫與Elasticsarch相比主要優點是事務隔離機制無可替代，但其侷限性很明顯，如下：
-
關係型數據庫查詢性能，數據量超過百萬級千萬級之後下降厲害，本質是索引的算法效率不行，B+樹算法不如倒排索引算法高效。
-
關係型數據庫索引最左原則限制，查詢條件字段不能任意組合，否則索引失效，相反Elasticserach可以任意組合，此場景在數據表關聯查詢時特別明顯，Elasticsearch可以採用大寬表解決，而關係型數據庫不能。
-
關係型數據庫分庫分表之後多條件查詢，難於實現，Elasticsearch天然分佈式設計，多個索引多個分片皆可聯合查詢。
-
關係型數據庫聚合性能低下，數據量稍微多點，查詢列基數多一點性能下降很快，Elasticsearch在聚合上採用的是列式存儲，效率極高。
-
關係型數據庫側重均衡性，Elasticsearch側重專一查詢速度。
若數據無需嚴格事務機制隔離，個人認爲都可以採用Elasticsearch替代。若數據既要事務隔離，也要查詢性能，可以採用DB與ES混合實現，詳細見筆者的博客文章《DB與ES混合應用之數據實時同步》
圖示：RDBMS與ES各自優勢示意圖
4、OpenTSDB
OpenTSDB內部基於HBase實現，屬於時間序列數據庫，主要針對具有時間特性和需求的數據，進行過數據結構的優化和處理，從而適合存儲具有時間特性的數據，如監控數據、溫度變化數據等，小米公司開源監控體系open-falcon的就是基於OpenTSDB實現。
圖示：OpenTSDB時間序列數據庫內部實現
Elastic產品本身無意時間序列這個領域，隨着ELK的流行，很多公司採用ELK來構建監控體系，雖然在數值類型上不像時間序列數據庫做過特別處理，但由於其便利的使用，以及生態技術棧的優勢，我們也接受了這樣的事實。
Elasticsearch構建時間序列很簡單，性能也相當不錯：
-
索引創建規則，可以按年、按月、按周、按星期、按天、按小時等都創建索引，非常便利。
-
數據填充方面，定製一個時間字段做區分排序，其餘的字段無需。
-
數據查詢方面，除了按實際序列查詢外，還可以有更多的搜索條件。
除非對於時間序列數據有非常苛刻的監控需求，否則選擇Elasticsearch會更加合適一些。
5、HBase
HBase是列式數據庫的代表，其內部有幾個致命設計大大限制了它的應用範圍：
-
訪問HBase數據只能基於Rowkey，Rowkey設計的好壞直接決定了HBase使用優劣。
-
本身不支持二級索引，若要實現，則需要引入第三方。
關於其各種技術原理就不多說了，說說它的一些使用情況。
公司所屬物流速運行業，一個與車輛有關的項目，記錄所有車輛行駛軌跡，車載設備會定時上報車子的軌跡信息，後端數據存儲基於HBase，數據量在幾十TB級以上，由於業務端需要依據車輛軌跡信息計算它的公里油耗以及相關成本，所以要按查詢條件批量查詢數據，查詢條件有一些非rowkey的字段，如時間範圍，車票號，城市編號等，這幾乎無法實現，原來暴力的做過，性能問題堪憂。此項目的問題首先也在於rowkey難設計滿足查詢條件的需求，其次是二級索引問題，查詢的條件很多。
如果用列式數據庫僅限於Rowkey訪問場景，其實採用Elastic也可以，只要設計好 _id，與HBase可以達到相同的效果。
如果用列式數據庫查詢還需要引入三方組件，那還不如直接在Elasticsearch上構建更直接。
除非對使用列式數據庫有非常苛刻的要求，否則Elasticsearch更具備通用性，業務需求場景適用性更多。
圖示：列式數據庫內部數據結構示意圖
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內置自動生成。
公司剛好有個項目，原來數據層基於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。
圖示：ClickHouse在大數據平臺中的位置
8、Druid
Durid是一個大數據MPP查詢型數據產品，核心功能Rollup，所有的需要Rollup原始數據必須帶有時間序列字段。Elasticsearch在6.3.X版本之後推出了此功能，此時兩者產品形成競爭關係，誰高誰下，看應用場景需求。
Druid樣本數據，必須帶有time時間字段。
筆者之前負責過公司所有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在數據模型上都支持倒排索引，基於此的搜索與過濾。
圖示：Druid產品技術架構體系示意圖
關於Rollup這個大數據分析領域，若有大規模的Rollup的場景需求，個人更傾向於Druid。
結語
總結：
-
Elasticsearch產品功能全面，適用範圍廣，性能也不錯，綜合應用是首選。
-
Elasticsearch在搜索查詢領域，幾乎完勝所有競爭產品，在筆者的技術棧看來，關係型數據庫解決數據事務問題，Elasticsearch幾乎解決一切搜索查詢問題。
-
Elasticsearch在數據分析領域，產品能力偏弱一些，簡單通用的場景需求可以大規模使用，但在特定業務場景領域，還是要選擇更加專業的數據產品，如前文中提到的複雜聚合、大規模Rollup、大規模的Key-Value。
-
Elasticsearch越來越不像一個搜索引擎，更像是一個全能型的數據產品，幾乎所有行業都在使用，業界非常受歡迎。
-
Elasticsearch用得好，下班下得早。