查詢快到起飛的 ES,真的適合你的應用場景嗎?

語言: CN / TW / HK

作者介紹

李猛, 資料領域專家, Elastic Stack國內頂尖實戰專家,國內首批Elastic官方認證工程師21人之一。2012年入手Elasticsearch,對Elastic Stack技術棧開發、架構、運維、原始碼、演算法等方面有深入實戰經驗。負責過多種Elastic Stack專案,包括大資料分析領域、機器學習預測領域、業務查詢加速領域、日誌分析領域、基礎指標監控領域等。十餘年技術實戰從業經驗,擅長大資料多種技術棧混合,系統架構領域。

序言

圖示: Elasticsearch 在 DB-Engine 權威熱度綜合排名第 8

大學上程式設計課程,老師都會先介紹程式設計思想與程式語言,其中會著重介紹一下面向過程程式設計與面向物件程式設計,再延伸到程式語言,如C、Java等; 那麼當下,從個人認知層面來講,正在處於面向資料程式設計階段,社會分工越來越細,程式設計思想與程式設計方式已經出現了很大的變化。 畢業後走上工作崗位,經歷過很多業務專案系統之後,越來越多的人可能已經認識到,需要越來越重視資料產品,應用系統核心支撐越來越依賴資料庫產品,上層的程式語言僅僅是一種互動介面而已; 底層的資料產品提供的能力,從某種程度上說,已經決定了業務系統的支撐能力,互動形式、甚至是程式設計方式、程式語言等。

El asticsearch是資料產品領域一個不可替代的多面手,業務應用範圍非常廣,其最核心的能力是查詢方式豐富,且查詢效能槓槓的。下面就從ES查詢方式的形態展開,看看它提供的哪些查詢方式可以適配當下的業務痛點場景。

注:本文內容基於ES 7.15.x版本編寫,若是其它版本可能會存在差異。

圖示: 某些業務系統需要同時融合多種資料產品、多種程式語言

一、Query string query

Query string query(簡稱代號:QS),英語直譯“查詢字串”就是基於字串表示式的一種查詢語法,從當前ES版本來看,雖然已經算是比較原始,但也非常具有意義,且有應用意義。

圖示:query string 與 simple query string 查詢示例,來自ES官方

QS查詢語法簡單直接,表達能力按照人腦最直接的思維方式,有點類似我們的語言對話的表達方式,很容易掌握,初學者稍微有點程式設計經驗也會很快學會。從應用角度來說,非常適合一些需要很強自由度查詢表達的業務場景, 且使用這些業務系統的人不是非計算機專業的人士。

適用場景舉例,某些物流公司內部系統或者電商內部業務系統, 資料關聯欄位特別多,幾百個甚至上千個,業務操作人員需要組合任意的條件進行查詢,這些業務人員並非計算機專業工程師,不可能快速學會一些高階查詢語言的,如SQL,那麼QS就顯得非常適合了,其內部的簡單組合條件查詢表示式,基本上只要稍微有點數學邏輯的人,看幾眼就學會了。可能有一些IT工程師會說,系統設計增加一些固定查詢條件不就好了嗎,其實不然,當業務系統資料欄位超過一定數量時,系統設計開發仍然採用固定查詢方式,本身就是一種罪過,最後就會演變IT工程師覺得業務需求好多,開發進度跟不上,業務操作人員會任務業務系統設計的非常死板,且跟不上業務發展訴求。

可能會有工程師好奇,為什麼不使用關係型資料庫來解決,SQL也比較適合此場景的查詢,當然這裡就屬於另外的話題,需要深入套路RDB與ES底層特性,此處不展開,詳細可以參考作者之前寫過的文章,已經充分論證。

如下圖,某物流公司內部的查詢系統,查詢條件已經非常多了,依然還不能滿足查詢訴求。

圖示:某物流系統內部查詢模組,這還是相對簡單的,來自百度圖片

QS雖然查詢方式直接簡潔,表達方式非常人性,侷限性也很明顯,但不足以支援ES豐富的查詢能力、未來的新特性、未來更多的應用場景。

建議依然工程師掌握瞭解,納入腹中,可能某個業務場景就非常適合,可能這個特性就是某個業務系統核心的技術支撐,至少我已經見識過了。

二、Query DSL

DSL 全稱 Query Domain Specific Language,直譯過來“領域特定語言”,是ES專門面向ES特性設計的一種類抽象語法樹(Abstract Syntax Trees)的查詢語言,查詢表達能力非常豐富,也是當下使用ES的首選,也是任何時候使用ES的首選。

ES支援了很多種查詢,初步入手ES的工程師可能都會有深深體會,之前在基於傳統資料庫產品做的非常難解決的查詢問題,在ES都非常容易,不僅僅是效能,而是豐富的查詢方式,其實這也得益於ES設計的DSL。

圖示: DSL查詢語言示例,來自官方

DSL幾乎支援了ES內部所有的查詢表示式能力,其中全文文字分詞查詢(full text query)與詞項精確查詢(term level query)幾乎是最常用的場景; 還有一些高階的查詢特性,在進入ES之前,見過很多工程師在程式碼中使用正則或者特別複雜的邏輯判斷來替代,實在UGLY,程式碼醜陋,效能也醜陋。

DSL帶來了豐富的查詢表達能力,也帶了一定的複雜度,也是被一些其它資料產品領域的工程師所抨擊的地方,特別是SQL領域。本人認為這個是不正確的認知,相反,本人認為任何資料庫產品都有自己的獨特性,其獨特的內部實現與應用場景,決定了它的能力,DSL由於其豐富的查詢表達能力,需要稍微系統的學習一下,反而帶來了比SQL更好的查詢體驗;在資料產品領域還有很多各自產品的DSL,如圖資料產品Arrangodb、Cassandra等,正式由於他們的產品獨特性,其表達方式已經驗證了不能完全由SQL替代。

圖示: Arangodb查詢語言AQL,來自官方

建議,千萬不要因為SQL與DSL之爭問題而錯過了Elasticsearch,其帶給你的便利性,誰用誰知道。

三、SQL

SQL 全稱 Structured Query Language,直譯過來“結構化查詢語言“,這個不用多說,廣大的工程師入行程式設計時,必學的查詢語法,在之前主要是在傳統關係型資料庫上使用,不過隨著NOSQL越來越得人心,NOSQL也開始逐步整合此特性,因為廣大的群組基礎,業界俗語“大資料BI工程師就是SQL工程師“,每日的工作就是寫SQL。

Elasticsearch官方自 6.5.x 版本開始整合自家SQL查詢方式,在此之前一般會採用NLPChina提供外掛,全稱Elasticsearch-sql,帶來了一定的便利性,但其本質上是將SQL表示式直接轉換為DSL表示式查詢,僅僅多了一次轉換,並未有什麼革命性的變化。但不可否認其在IT工程師的業務應用訴求。

曾在某物流公司見過業務部門系統架構師,將SQL的複雜表達能力應用到極致,用來解決資料與使用者許可權方面的通用性表達語言,本人見過最強大複雜的許可權系統,也覺得設計的非常優秀的;從事過業務系統的工程師可能都會有同感,常規的業務系統都需要一個許可權系統,用來隔離使用者與資料方面的訪問許可權,需要精確到資料行,資料欄位等層面,而且還需要支援很多定製化場景,如就指定某些人某個時間點可訪問等;該系統的核心關鍵設計就是基於SQL來完成,無論多麼複雜個性化的許可權隔離需求,都只要轉換為SQL表示式來執行而已,一招輕鬆化解;當然也應用了Elasticsearch,想象一下,如果沒有提供SQL支援,那麼業務系統的變態許可權隔離需求,又該如何設計完成呢?

圖示: 社群SQL外掛查詢示例,來自NLPChina

官方SQL相比社群做了更多的創新,其中有一點,本人是特別推薦的,基於官方SQL執行查詢,返回結果資料量同比DSL查詢要減少近一倍; 官方SQL支援多種資料格式查詢結果,其中Json是最常用,也是REST API時代,廣大程式設計師們最熱衷的資料互動介面協議。 這對於應用ES執行查詢後需要返回大量資料結果場景非常好,大大減輕網路流量IO,也是一個性能優化點。

圖示: 官方SQL外掛查詢示例,來自Elastic官方

官方SQL同時為了相容DSL,也提供了轉換DSL的API,如果對於DSL不太熟悉,可以藉助此能力。

圖示: SQL轉換為DSL示例,來自Elastic官方

官方SQL給帶來很多優越的便利性,也存在一些侷限性,並不完整支援標準的SQL,與當下最新的SQL相容,很多查詢特性還是有明顯的DSL影子; 官方SQL持續演進,從最早6.5.x到現在7.15.x,已經增加了很多SQL標準支援,但是SQL不能替代DSL,至今DSL依然是ES領域最好的查詢方式,這一點必須要明確。

四、EQL

EQL 全稱 Event Query Language ,直譯過來“直接查詢語言”,核心需要基於時序資料,必須要指定時間欄位與類別欄位,如日誌,指標、全鏈路等場景,ES官方推出此查詢方式主要目的是安全分析場景。

圖示: 官方EQL查詢示例,來自Elastic官方

EQL目前並未在應用系統中非常大規模使用,介紹見到工程師使用,可能是其定位在安全分析場景原因。 必須承認其帶來的一些查詢特性,其語法非常直觀,表示式也非常豐富,對於有程式設計基礎的工程師,非常容易掌握,必須強調,這是一個面向安全行業的設計的查詢語言,所以運用其最多的應該也是安全方面的工程師。

五、ES查詢方式內部

到目前為止,ES主要提供了以上4種查詢方向,也分別按照以上順序演進,還不存在誰替代誰,依然保持並行獨立發展進化。ES執行所有的查詢方式,先是轉換為DSL,構建各自的QueryBuilder,其次構建各自的Query,最後交由Lucene執行。

六、經驗認知

以上基於ES提供的查詢方式,詳細談了一下個人的經驗認知,僅僅在ES領域,就可以看到,如果我們深度的掌握ES資料產品,我們的工作方式與程式設計方式都會發生很大的變化,我們不再需要基於程式語言去構建複雜的原始查詢業務場景,不在需要程式語言承載資料表達能力。

在面向資料程式設計時代,我們的程式設計方式與認知都需要進化,掌握一門程式語言僅僅是能做應用專案的第一步,程式語言掌握的深入其實本質上沒有太多意義,一個應用系統最終需要的是資料產品來承載,程式語言僅僅是一個互動入口,我們可以在很短的時間內學會一門程式語言並進行專案實戰,但是對於一個數據產品的掌控確需要相當長的時間與經驗積累。

“ES玩的好,下班下得早!”不僅僅是一句ES的口號,更多的是期望通過“面向資料程式設計”理念,重新審視程式設計的本質。

> > > >

參考資料

  • 查詢字串 query string

    https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-query-string-query.html

  • 簡單查詢字串 simple-query-string

    https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-simple-query-string-query.html

  • 查詢領域特定語言 query-dsl

    https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html

  • SQL社群外掛 elasticsearch-sql

    https://github.com/NLPchina/elasticsearch-sql

  • SQL官方外掛 xpack-sql

    https://www.elastic.co/guide/en/elasticsearch/reference/current/xpack-sql.html

  • 官方EQL

    https://www.elastic.co/guide/en/elasticsearch/reference/current/eql.html

dbaplus社群歡迎廣大技術人員投稿,投稿郵箱: [email protected]