easy-es的出现，江湖不再需要RestHighLevelClient（雄霸天下风云再起）

哈喽，大家好，我是强哥。

当今天下，ES(ElasticSearch)作为搜索服务界的扛把子，凭借其分布式、高扩展、高实时的搜索与数据分析能力，备受程序员小屁民的追捧。而ES在稳坐老大位置的同时，将Kibana和Logstash收为麾下，成立帮会：ELK，成为江湖上赫赫有名的第一大帮。

然而，随着时间的慢慢流逝，帮主ES的一些霸道手段也慢慢展露出来。

雄霸一方，欺压百姓

在江湖之上，码农们要用到搜索引擎的服务，就必须和帮主ES交易，而ES性格怪诞，定下号令，想要与他交易的，必须使用他自创的DSL语法。而就是学习这一语法让码农们痛苦不堪。

码农们师从一派，自幼受SQL语法的熏陶，由于往日与其他帮派交易也都多以SQL方式，大家往来甚是融洽。而唯独与这ELK帮交易最为难受，其蹩脚难懂的DSL语法让码农们苦不堪言。而搜索服务又往往是日常生活中或多或少要用的上的，于是乎，江湖上开始怨声载道。

而ES显然也注意到了这点，也有搞出xpack等工具来“帮助”大家。可是，这玩意更是暴露了其贪婪的特性。xpack的使用采用类似租赁制，码农们想要使用，就要交钱。这明显的就是对穷困潦倒的码农们的一种嘲讽。

码农们也是敢怒而不敢言，搜索服务不得不用，谁让ES一家独大，DSL难用也得学啊，总比什么都没有强。

风云再起，救星降临

要问当下，码农们与数据库第一大帮Mysql交易最为密切，彼此交易使用SQl语法来进行通信，智者更是创造了Mybatis-Plus工具使码农们与Mysql交易起来更为便捷快速。

而一提到要和ES交易，人们就愁容满面，每次交易前，都需带上一大本工具书，仔细查阅一番后，才能顺利生成DSL语法进行交易。

随着时间的流逝，越来越多的有志之士开始另辟蹊径，而一个工具的诞生，也打破了江湖多年的沉寂。

这个工具，就是easy-es。

博采众长，备受追捧

要说发明这个工具的智者，也是师出Mybatis-Plus，同时对ES DSL语法的研究也是极为深入。

他在DSL语法之上，对照Mybatis-Plus的功能，造出了一个能与ES交易的ES版Mybatis-Plus，起名easy-es。

工具使用起来也极为简单。我们可以拿它与DSL的RestHighLevelClient（码农们原来生成DSL语法的工具）对比一下。

需求:查询出文档标题为 "中国功夫"且作者为"老汉"的所有文档

使用Easy-Es仅需3行代码即可完成查询：

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

传统方式, 直接用RestHighLevelClient进行查询：

// 传统方式, 直接用RestHighLevelClient进行查询需要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(); }

可以看出，上面一个简单的查询演示，在代码量上就有了很大的差别。实际使用场景越复杂,效果就越好,平均可节省3-5倍代码量。

当然，ES经常被作为大数据量的准实时查询，那么，使用了easy-es之后，对查询的性能会不会有所影响呢？毕竟，这个工作是在传统工具上的再创作。

我们先来看easy-es在整个查询过程中做了什么事? 总结起来就2件:

把用户输入的MySQL语法(Mybatis-Plus语法)转换成RestHighLevel语法,然后调用RestHighLevelClient执行本次查询
把查询结果转换成用户想要的格式:如List并返回.

其中,语法转换是按照MySQL和RestHighLevelClient语法对照表的关系进行转换.这种转换其实耗费的性能非常低,因为即使你直接使用RestHighLevelClient进行查询,你依旧需要创建出termQueryBuilder和BoolQueryBuilder. 唯一的区别就是我把用户输入的查询条件eq放入了队列,然后通过队里FIFO(除查询条件中有or的情况)的顺序逐一进行转换,对于绝大多数查询语句,查询条件都不会太多,所以队里中的元素数大多数情况下都会小于10,而且队列中我只存了枚举和参数,既不会占用过多内存,也不会因为队列的遍历消耗多少性能. 对于现代计算机而言,别说遍历10条小数据,就是成百上千条也是毫秒级的,所以这点性能损耗基本可以忽略不计。
再说结果解析,结果解析其实就是把调用RestHighLevelClient返回的SearchResponse中的hits取出并用fastJson转换成数组,这个过程就算不用EE,你直接用RestHighLevelClient也是会有这一步,所以这一步并没有过多的损耗,即便是我用了反射,字段的反射和注解信息,都在框架启动时加载进内存中了,做了jvm的缓存,所以这点损耗可忽略不计。

当然如上都是基于理论分析,在0.9.6版本中,Sample模块的test目录Performance测试类中,大家可以看到我针对CURD分别作了不同维度的性能测试,实际测试的结果也很好的印证了我上面的理论分析,EE除了查询会比直接使用RestHighLevelClient平均慢10-15毫秒,增删改API并无差异,而且随着查询数据量的增大,实体字段缓存生效后,查询差异会进一步降低,几乎可以忽略不计. 牺牲10毫秒,对用户而言是无感知的,但对开发而言,可以节省大量代码和时间,我认为这是值得的,基本上没有哪款ORM框架是不会损耗性能的,权衡利弊,主公们心理应该都会有答案.

智者还保证，只要使用工具除了问题，都会积极的耐心解答。

由此可见，码农们接入easy-es，可谓优势多多：