序言
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 用得好，下班下得早。
注：
- 内容來源于筆者實際工作中運用多種技術棧實作場景需求，得出的一些實戰經驗與總結思考，提供後來者借鑒參考。
- 本文圍繞 Elastic 的競争産品對比僅限概要性分析，粒度較粗，深度有限，之後會有更加專業深入競争産品分析文章，敬請期待。