哈嘍，大家好，我是強(qiáng)哥。

當(dāng)今天下，ES(ElasticSearch)作為搜索服務(wù)界的扛把子，憑借其分布式、高擴(kuò)展、高實(shí)時的搜索與數(shù)據(jù)分析能力，備受程序員小屁民的追捧。而ES在穩(wěn)坐老大位置的同時，將Kibana和Logstash收為麾下，成立幫會：ELK，成為江湖上赫赫有名的第一大幫。

然而，隨著時間的慢慢流逝，幫主ES的一些霸道手段也慢慢展露出來。

雄霸一方，欺壓百姓

在江湖之上，碼農(nóng)們要用到搜索引擎的服務(wù)，就必須和幫主ES交易，而ES性格怪誕，定下號令，想要與他交易的，必須使用他自創(chuàng)的DSL語法。而就是學(xué)習(xí)這一語法讓碼農(nóng)們痛苦不堪。

碼農(nóng)們師從一派，自幼受SQL語法的熏陶，由于往日與其他幫派交易也都多以SQL方式，大家往來甚是融洽。而唯獨(dú)與這ELK幫交易最為難受，其蹩腳難懂的DSL語法讓碼農(nóng)們苦不堪言。而搜索服務(wù)又往往是日常生活中或多或少要用的上的，于是乎，江湖上開始怨聲載道。

而ES顯然也注意到了這點(diǎn)，也有搞出xpack等工具來“幫助”大家?？墒牵@玩意更是暴露了其貪婪的特性。xpack的使用采用類似租賃制，碼農(nóng)們想要使用，就要交錢。這明顯的就是對窮困潦倒的碼農(nóng)們的一種嘲諷。

碼農(nóng)們也是敢怒而不敢言，搜索服務(wù)不得不用，誰讓ES一家獨(dú)大，DSL難用也得學(xué)啊，總比什么都沒有強(qiáng)。

風(fēng)云再起，救星降臨

要問當(dāng)下，碼農(nóng)們與數(shù)據(jù)庫第一大幫Mysql交易最為密切，彼此交易使用SQl語法來進(jìn)行通信，智者更是創(chuàng)造了Mybatis-Plus工具使碼農(nóng)們與Mysql交易起來更為便捷快速。

而一提到要和ES交易，人們就愁容滿面，每次交易前，都需帶上一大本工具書，仔細(xì)查閱一番后，才能順利生成DSL語法進(jìn)行交易。

隨著時間的流逝，越來越多的有志之士開始另辟蹊徑，而一個工具的誕生，也打破了江湖多年的沉寂。

這個工具，就是easy-es。

博采眾長，備受追捧

要說發(fā)明這個工具的智者，也是師出Mybatis-Plus，同時對ES DSL語法的研究也是極為深入。

他在DSL語法之上，對照Mybatis-Plus的功能，造出了一個能與ES交易的ES版Mybatis-Plus，起名easy-es。

工具使用起來也極為簡單。我們可以拿它與DSL的RestHighLevelClient（碼農(nóng)們原來生成DSL語法的工具）對比一下。

需求:查詢出文檔標(biāo)題為 "中國功夫"且作者為"老漢"的所有文檔

使用Easy-Es僅需3行代碼即可完成查詢：

LambdaEsQueryWrapper<Document> wrapper = new LambdaEsQueryWrapper<>();wrapper.eq(Document::getTitle, "中國功夫").eq(Document::getCreator, "老漢");List<Document> documents = documentMapper.selectList(wrapper);

傳統(tǒng)方式, 直接用RestHighLevelClient進(jìn)行查詢：

// 傳統(tǒng)方式, 直接用RestHighLevelClient進(jìn)行查詢 需要11行代碼,還不包含解析JSON代碼String indexName = "document";SearchRequest searchRequest = new SearchRequest(indexName);BoolQueryBuilder boolQueryBuilder = QueryBuilders.boolQuery();TermQueryBuilder titleTerm = QueryBuilders.termQuery("title", "中國功夫");TermsQueryBuilder creatorTerm = QueryBuilders.termsQuery("creator", "老漢");boolQueryBuilder.must(titleTerm);boolQueryBuilder.must(creatorTerm);SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder();searchSourceBuilder.query(boolQueryBuilder);searchRequest.source(searchSourceBuilder);try { SearchResponse searchResponse = restHighLevelClient.search(searchRequest, RequestOptions.DEFAULT); // 然后從searchResponse中通過各種方式解析出DocumentList 省略這些代碼...} catch (IOException e) { e.printStackTrace();}

可以看出，上面一個簡單的查詢演示，在代碼量上就有了很大的差別。實(shí)際使用場景越復(fù)雜,效果就越好,平均可節(jié)省3-5倍代碼量。

當(dāng)然，ES經(jīng)常被作為大數(shù)據(jù)量的準(zhǔn)實(shí)時查詢，那么，使用了easy-es之后，對查詢的性能會不會有所影響呢？畢竟，這個工作是在傳統(tǒng)工具上的再創(chuàng)作。

我們先來看easy-es在整個查詢過程中做了什么事? 總結(jié)起來就2件:

1. 把用戶輸入的MySQL語法(Mybatis-Plus語法)轉(zhuǎn)換成RestHighLevel語法,然后調(diào)用RestHighLevelClient執(zhí)行本次查詢
2. 把查詢結(jié)果轉(zhuǎn)換成用戶想要的格式:如List并返回.

• 其中,語法轉(zhuǎn)換是按照MySQL和RestHighLevelClient語法對照表的關(guān)系進(jìn)行轉(zhuǎn)換.這種轉(zhuǎn)換其實(shí)耗費(fèi)的性能非常低,因?yàn)榧词鼓阒苯邮褂肦estHighLevelClient進(jìn)行查詢,你依舊需要創(chuàng)建出termQueryBuilder和BoolQueryBuilder. 唯一的區(qū)別就是我把用戶輸入的查詢條件eq放入了隊列,然后通過隊里FIFO(除查詢條件中有or的情況)的順序逐一進(jìn)行轉(zhuǎn)換,對于絕大多數(shù)查詢語句,查詢條件都不會太多,所以隊里中的元素數(shù)大多數(shù)情況下都會小于10,而且隊列中我只存了枚舉和參數(shù),既不會占用過多內(nèi)存,也不會因?yàn)殛犃械谋闅v消耗多少性能. 對于現(xiàn)代計算機(jī)而言,別說遍歷10條小數(shù)據(jù),就是成百上千條也是毫秒級的,所以這點(diǎn)性能損耗基本可以忽略不計。
• 再說結(jié)果解析,結(jié)果解析其實(shí)就是把調(diào)用RestHighLevelClient返回的SearchResponse中的hits取出并用fastJson轉(zhuǎn)換成數(shù)組,這個過程就算不用EE,你直接用RestHighLevelClient也是會有這一步,所以這一步并沒有過多的損耗,即便是我用了反射,字段的反射和注解信息,都在框架啟動時加載進(jìn)內(nèi)存中了,做了jvm的緩存,所以這點(diǎn)損耗可忽略不計。

當(dāng)然如上都是基于理論分析,在0.9.6版本中,Sample模塊的test目錄Performance測試類中,大家可以看到我針對CURD分別作了不同維度的性能測試,實(shí)際測試的結(jié)果也很好的印證了我上面的理論分析,EE除了查詢會比直接使用RestHighLevelClient平均慢10-15毫秒,增刪改API并無差異,而且隨著查詢數(shù)據(jù)量的增大,實(shí)體字段緩存生效后,查詢差異會進(jìn)一步降低,幾乎可以忽略不計. 犧牲10毫秒,對用戶而言是無感知的,但對開發(fā)而言,可以節(jié)省大量代碼和時間,我認(rèn)為這是值得的,基本上沒有哪款ORM框架是不會損耗性能的,權(quán)衡利弊,主公們心理應(yīng)該都會有答案.

智者還保證，只要使用工具除了問題，都會積極的耐心解答。

由此可見，碼農(nóng)們接入easy-es，可謂優(yōu)勢多多：

• 簡單易用高效不用我多說了吧,MyBatis-Plus用戶懂的都懂! 大把的時間節(jié)省出來,做…愛做的事情,真香!
• 使用門檻降低,就算是剛不懂Es的小白,也可以用EE開發(fā)各種功能
• 大幅減少代碼量,提升代碼可讀性,降低重復(fù)代碼量,提升代碼質(zhì)量
• 專業(yè)答疑團(tuán)隊,無憂售后
• 永久免費(fèi)

easy-es工具附錄

項(xiàng)目地址：https://gitee.com/dromara/easy-es

文檔地址：https://easy-es.cn/#/README