ES 既是搜索引擎又是數據庫？真的有那麼全能嗎？

雲棲號資訊：【點擊查看更多行業資訊】
在這裏您能夠找到不一樣行業的第一手的上雲資訊，還在等什麼，快來！

序言
常常遇到不少朋友詢問，如何學好 Elasticsearch？這個問題本質上很很差回答，但我一直又很想好好回答，因此本文就以我我的的經驗視角，跟你們探討一下如何正確的擁抱 Elasticsearch。如有不當之處，歡迎留言指正。

ES 認知
一、ES 是什麼
Elasticsearch 是什麼，不一樣的人有不一樣的理解定位，以前寫過 Elasticsearch 對比其它數據產品的文章《Elasticsearch 對壘 8 大競品技術，孰優孰劣？》，看了文章下面的評論，不少人定位它是搜索引擎，我以爲也很片面，下面就談談個人認知：

1）Elasticsearch 是搜索引擎
Elasticsearch 在搜索引擎數據庫領域排名絕對第一，內核基於 Lucene 構建，支持全文搜索是職責所在，提供了豐富友好的 API。我的早期基於 Lucene 構建搜索應用，須要考慮的因素太多，自接觸到 Elasticsearch 就再無自主開發搜索應用。普通工程師要想掌控 Lucene 須要一些代價，且不少機制並不完善，須要作大量的周邊輔助程序，而 Elasticsearch 幾乎都已經幫你作完了。

2）Elasticsearch 不是搜索引擎
說它不是搜索引擎，估計不少從業者不承認，在我的涉及到的項目中，傳統意義上用 Elasticsearch 來作全文檢索的項目佔比愈來愈少，多數時候是用來作精確查詢加速，查詢條件不少，能夠任意組合，查詢速度很快，替代其它不少數據庫複雜條件查詢的場景需求；甚至有的數據庫產品直接使用 Elasticsearch 作二級索引，如 HBase、Redis 等。Elasticsearch 因爲自身的一些特性，更像一個多模數據庫。

3）Elasticsearch 是數據庫
Elasticsearch 使用 Json 格式來承載數據模型，已經成爲事實上的文檔型數據庫，雖然底層存儲不是 Json 格式，同類型產品有大名鼎鼎的 MongoDB，不過兩者在產品定位上有差異，Elasticsearch 更加擅長的基於查詢搜索的分析型數據庫，傾向 OLAP；MongoDB 定位於事務型應用層面 OLTP，雖然也支持數據分析，筆者簡單應用過以後再無使用，誰用誰知道。

4）Elasticsearch 不是數據庫
Elasticsearch 不是關係型數據庫，內部數據更新採用樂觀鎖，無嚴格的 ACID 事務特性，任何企圖將它用在關係型數據庫場景的應用都會有不少問題，不少其它領域的從業者喜歡拿這個來做爲它的缺陷，重申這不是 Elasticsearch 的本質缺陷，是產品設計定位如此。

二、ES 作什麼
Elasticsearch 雖然是基於 Lucene 構建，但應用領域確實很是寬泛。

1）全文檢索
Elasticsearch 靠全文檢索起步，將 Lucene 開發包作成一個數據產品，屏蔽了 Lucene 各類複雜的設置，爲開發人員提供了很友好的便利。不少傳統的關係型數據庫也提供全文檢索，有的是基於 Lucene 內嵌，有的是基於自研，與 Elasticsearch 比較起來，功能單一，性能也表現不是很好，擴展性幾乎沒有。
若是，你的應用有全文檢索需求，建議你優先遷移到 Elasticsearch 平臺上來，其提供豐富的 Full text queries 會讓你驚訝，一次用爽，一直用爽。

2）應用查詢
Elasticsearch 最擅長的就是查詢，基於倒排索引核心算法，查詢性能強於 B-Tree 類型全部數據產品，尤爲是關係型數據庫方面。當數據量超過千萬或者上億時，數據檢索的效率很是明顯。
我的更看中的是 Elasticsearch 在通用查詢應用場景，關係型數據庫因爲索引的左側原則限制，索引執行必須有嚴格的順序，若是查詢字段不多，能夠經過建立少許索引提升查詢性能，若是查詢字段不少且字段無序，那索引就失去了意義；相反 Elasticsearch 是默認所有字段都會建立索引，且所有字段查詢無需保證順序，因此咱們在業務應用系統中，大量用 Elasticsearch 替代關係型數據庫作通用查詢，自此以後對於關係型數據庫的查詢就很排斥，除了最簡單的查詢，其他的複雜條件查詢所有走 Elasticsearch。

3）大數據領域
Elasticserach 已經成爲大數據平臺對外提供查詢的重要組成部分之一。大數據平臺將原始數據通過迭代計算，以後結果輸出到一個數據庫提供查詢，特別是大批量的明細數據。
這裏會面臨幾個問題，一個問題是大批量明細數據的輸出，如何能在極短的時間內寫到數據庫，傳統上不少數據平臺選擇關係型數據庫提供查詢，好比 MySQL，以前在這方面吃過很多虧，瞬間寫入性能極差，根本沒法知足要求。另外一個問題是對外查詢，如何能像應用系統同樣提供性能極好的查詢，不限制查詢條件，不限制字段順序，支持較高的併發，支持海量數據快速檢索，也只有 Elasticsearch 可以作到比較均衡的檢索。

從官方的發佈版本新特性來看，Elasticseacrch 志在大數據分析領域，提供了基於列示存儲的數據聚合，支持的聚合功能很是多，性能表現也不錯，筆者有幸以前大規模深度使用過，很有感覺。
Elasticsearch 爲了深刻數據分析領域，產品又提供了數據 Rollup 與數據 Transform 功能，讓檢索分析更上一層樓。在數據 Rollup 領域，Apache Druid 的競爭能力很強，筆者以前作過一些對比，單純的比較確實不如 Druid，但自 Elasticsearch 增長了 Transfrom 功能，且單首創建了一個 Transfrom 的節點角色，我的更加看好 Elasticseach，跳出了 Rollup 基於時間序列的限制。

4）日誌檢索
著名的 ELK 三件套，講的就是 Elasticsearch，Logstash，Kibana，專門針對日誌採集、存儲、查詢設計的產品組合。不少第一次接觸到 Elasticsearch 的朋友，都會覺得 Elasticsearch 是專門作日誌的，其實這些都是誤解，只是說它很擅長這個領域，在此領域大有做爲，名氣很大。
日誌自身特色沒有什麼通用的規範性，人爲的隨意性很大，日誌內容也是任意的，更加需求全文檢索能力，傳統技術手段自己作全文檢索非常吃力。而 Elasticsearch 自己起步就是靠全文檢索，再加上其分佈式架構的特性，很是符合海量日誌快速檢索的場景。今天若是還發現有 IT 從業人員用傳統的技術手段作日誌檢索，應該要打屁股了。
現在已經從 ELK 三件套發展到 Elastic Stack 了，新增長了不少很是有用的產品，大大加強了日誌檢索領域。

5）監控領域
指標監控，Elasticsearch 進入此領域比較晚，卻遇上了好時代，Elasticsearch 因爲其倒排索引核心算法，也是支持時序數據場景的，性能也是至關不錯的，在功能性上徹底壓住時序數據庫。
Elasticsearch 搞監控得益於其提供的 Elastic Stack 產品生態，豐富完善，不少時候監控須要立體化，除了指標以外，還須要有各類日誌的採集分析，若是用其它純指標監控產品，如 Promethues，遇到有日誌分析的需求，還必須使用 Elasticsearch，這對於技術棧來講，又擴增了，相應的掌控能力會降低，我的精力有限，沒法同時掌握不少種數據產品，如此選擇一個更加通用的產品才符合現實。

6）機器學習
機器學習最近幾年風吹的很大，不少數據產品都集成了，Elasticsearch 也必須有，並且作的更好，真正將機器學習落地成爲一個產品 ，簡化使用，所見所得；而不像其它數據產品，僅僅集成算法包，使用者還必須開發不少應用支持。
Elasticsearch 機器學習提供了兩種方式，一種是異常檢測類型，屬於無監督學習，採用聚類模型，一般應用在安全分析領域，檢測異常訪問等；一種是數據幀分析，屬於分類與迴歸，屬於監督學習，可用於在業務模型領域，如電商行業，價格模型分析。
Elasticsearch 自己是數據平臺，集成了部分機器學習算法，同時又集成了 Kibana 可視化操做，使得從數據採集、到模型訓練、到模型預測應用均可以一鍵式完成。
Elasticserach 提供的機器學習套件，我的認爲最應該應用在數據質量這個領域，幫助大數據平臺自動檢測數據質量，從而下降人力提供效率。

需求等級
Elasticsearch 整個的技術棧很是複雜，涉及到的理論與技術點很是多，徹底掌握並不現實，做爲一個 IT 從業者，首先是定位好本身的角色，依據角色需求去學習掌握必備的知識點。如下是筆者對於一個技術產品的劃分模型：
一、概念
Elasticsearch 涉及到的概念不少，核心概念其實就那麼幾個，對於一個新手來講，掌握概念目的是爲了創建起本身的知識思惟模型，將以後學習到的知識點作一個很好的概括劃分；對於一個其它數據產品的老手來講 ，掌握概念的目的是爲了與其它數據產品劃分比較，深刻的瞭解各自的優劣，在以後工做中如有遇到新的業務場景，能夠迅速作出抉擇。
IT 從業者廣泛都有個感覺，IT 技術發展太快了，各類技術框架產品層出不窮，學習掌握太難了，跟不上節奏。其實我的反倒以爲變化不大，基礎理論核心概念並無什麼本質的發展變化，無非是工程技術實操變了不少，但這些是須要深刻實踐才須要的，對於概念上無須要。
做爲一個技術總監，前端工程師工做 1～2 年的問題均可以問倒他，這是你們對於概念認知需求不同。

二、開發
開發工程師的職責是將需求變成能夠落地運行的代碼。Elasticsearch 的應用開發工做總結起來就是增刪改查，掌握必備的 ES REST API，熟練運用足以。筆者以前任職某物流速運公司，負責 Elasticsearch 相關的工做，公司 Elasticsearch 的需求不少，尤爲是查詢方面，ES 最厲害的查詢是 DSL，這個查詢語法須要常常練習使用，不然很容易忘記，當每次有人詢問時，都安排一個工程師專門負責各類解答，他在編寫 DSL 方面很是熟練，幫助了不少的工程師新手使用 Elasticsearch，屏蔽了不少細節，如有一些難搞定的問題，會由我來解決，另一方面做爲負責人的我偶然還要請他幫忙編寫 DSL。
Elasticsearch 後面提供了 SQL 查詢的功能，但比較侷限，複雜的查詢聚合必須回到 DSL。

三、架構
Elasticsearch 集羣架構整體比較複雜，首先得深刻了解 Elasticseach 背後實現的原理，包括集羣原理、索引原理、數據寫入過程、數據查詢過程等；其次要有不少案例實戰的機會，遇到不少挑戰問題 ，逐一排除解決，增長本身的經驗。
對於開發工程師來講，知足平常需求開發無需掌握這些，但對於 Elasticsearch 技術負責人，就很是有必要了，面對各類應用需求，要能從架構思惟去平衡，好比日誌場景集羣需求、大數據分析場景需求、應用系統複雜查詢場景需求等，從實際狀況設計集羣架構以及資源分配等。

四、運維
Elasticsearch 本質是一個數據庫，也須要有專門的 DBA 運維，只是更偏重應用層面，因此運維職責相對傳統 DBA 沒有那麼嚴苛。對於集羣層面必須掌握集羣搭建，集羣擴容、集羣升級、集羣安全、集羣監控告警等；另外對於數據層面運維，必須掌握數據備份與還原、數據的生命週期管理，還有一些平常問題診斷等。

五、源碼
Elasticsearch 自己是開源，閱讀源碼是個很好的學習手段，不少獨特的特性官方操做文檔並無寫出來，須要從源碼中提煉，如集羣節點之間的鏈接數是多少，但對於多數 Elasticsearch 從業者來講，卻非必要。瞭解到國內主要是頭部大廠須要深刻源碼定製化改造，更多的是集中在應用的便捷性改造，而非結構性的改造，Elastic 原廠公司有幾百人的團隊作產品研發，而國內多數公司就極少的人，因此從產量上來講，根本不是一個等級的。
若是把 Elasticsearch 比喻爲一件軍事武器，對於士兵來講 ，熟練運用纔是最重要的，至於改造應該是武器製造商的職責，一個士兵可使用不少武器裝備，用最佳的組合才能打贏一場戰爭，而不是去深刻原理而後造輪子，容易本末倒置。

六、算法
算法應該算是數據產品本質的區別，關係型數據庫索引算法主要是基於 B-Tree， Elasticserach 索引算法主要是倒排索引，算法的本質決定了它們的應用邊界，擅長的應用領域。
一般掌握一個新的數據產品時，我的的作法是看它的關鍵算法。早期作過一個地理位置搜索相關的項目，基於某個座標搜索周邊的座標信息，開始的時候採用的是三角函數動態計算的方式，數據量大一點，掃描一張數據表要好久；後面接觸到 Geohash 算法，按照算法將座標編碼，存儲在數據庫中，基於前綴匹配查詢，性能高效幾個數量級，感嘆算法的偉大；再後面發現有專門的數據庫產品集成了 Geohash 算法，使用起來就更簡單了。
Elasticsearch 集成不少算法，每種算法實現都有它的應用場景。

擁抱 ES 的方法
一、官方文檔
Elasticsearch 早期出過一本參考手冊《Elastic 權威指南》，是一本很好的入門手冊，從概念到實戰都有涉及，缺點是版本針對的 2.0，過於陳舊，除去核心概念，其他的皆不適用，當前最新版本已是 7.7 了，跨度太大，Elasticsearch 在跨度大的版本之間升級稍微比較麻煩，索引數據幾乎是不兼容的，升級以後須要重建數據纔可。
Elasticsearch 當前最好的參考資料是官方文檔，資料最全，同步發佈版本，且同時能夠參考多個版本。Elasticsearch 官方參考文檔也是最亂的，什麼資料都有，系統的看完以後感受仍在此山中，有點相似一本字典，看完了字典，依然寫很差做文；並且資料仍是英文的，至此就阻擋了國內大部分程序進入。
但想要學習 Elasticsearch，官方文檔至少要看過幾遍，便於迅速查詢定位。

二、系統學習
Elasticsearch 成名很早，國內也有不少視頻課程，多數比較碎片，或是紙上談兵，缺少實戰經驗。Elasticsearch 有一些專門的書籍，建議購買閱讀，國內深度一些的推薦《Elasticsearch 源碼解析與優化實戰》，國外推薦《Elasticsearch 實戰》，並且看書還有助於培養系統思惟。
Elasticsearch 技術棧功能特性不少，系統學習要保持好的心態，鍥而不捨，須要很長時間，也須要參考不少資料。

三、背後原理
Elasticsearch 是站在巨人肩膀上產品，背後借鑑了不少設計思想，集成了不少算法，官方的參考文檔在技術原理探討這塊並無深刻，僅僅點到爲止。想要深刻了解，必須得另闢蹊徑。
Elastic 官方的博客有不少優質的文章，不少人由於英文的緣故會忽視掉，裏面有不少關鍵的實現原理，圖文並茂，寫得很是不錯；另外國內一些雲廠商因爲提供了 Elasticsearch 雲產品，須要深度定製開發，也會有一些深刻原理系列的文章，能夠去閱讀參考，加深理解。對於已經有比較好的編程思惟的人，也能夠直接去下載官方源碼，設置斷點調試閱讀。

四、項目實戰
項目實戰是很是有效的學習途徑，考過駕照的朋友都深有體會，教練一上來就直接讓你操練車，經過不少次的練習就掌握了。Elasticsearch 擅長的領域不少，總結一句話就是「非強事務 ACID 場景皆可適用」，因此能夠作的事情也不少。
日誌領域的需求會讓你對於數據寫入量很是的關心，不斷的調整優化策略，提升吞吐量，下降資源消耗；業務系統的需求會讓你對數據一致性與時效性特別關心，從其它數據庫同步到 ES，關注數據同步的速度，關注數據的準確性，不斷的調整你的技術方案與策略；大數據領域的需求會讓你對於查詢與聚合特別關注，海量的數據須要快速的檢索，也須要快速的聚合結果。
項目實戰的過程，就是一個挖坑填坑的過程，實戰場景多了，解決的問題多了，天然就掌握得很好了。
以前筆者在前公司任職時，全部涉及到的 Elasticsearch 疑難雜症都會找我解決，有一些項目採用別的數據產品問題比較多，也來找我評估更換 ES 是否合適，以及給出相關建議。筆者認爲最好的學習方式是找到組織，找到經驗豐富的大咖，持續交流學習，成長最快也最好。

做者介紹：
李猛 (ynuosoft)，Elastic-stack 產品深度用戶，ES 認證工程師，2012 年接觸 Elasticsearch，對 Elastic-Stack 開發、架構、運維等方面有深刻體驗，實踐過多種 Elasticsearch 項目，最暴力的大數據分析應用，最複雜的業務系統應用；業餘爲企業提供 Elastic-stack 諮詢培訓以及調優實施。

【雲棲號在線課堂】天天都有產品技術專家分享！
課程地址：https://yqh.aliyun.com/zhibo

當即加入社羣，與專家面對面，及時瞭解課程最新動態！
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK

原文發佈時間：2020-07-03
本文做者：dbaplus社羣
本文來自：「InfoQ」，瞭解相關信息能夠關注「InfoQ」