查询快到起飞的 ES，真的适合你的应用场景吗？

发布时间：2025-11-05 15:59:40 来源：云智核 作者：IT科技

序言

大学上编程课程，查询场景老师都会先介绍编程思想与编程语言，起飞其中会着重介绍一下面向过程编程与面向对象编程，的适再延伸到编程语言，应用如C、查询场景Java等;那么当下，起飞从个人认知层面来讲，的适正在处于面向数据编程阶段，应用社会分工越来越细，查询场景编程思想与编程方式已经出现了很大的起飞变化。毕业后走上工作岗位，的适经历过很多业务项目系统之后，应用越来越多的查询场景人可能已经认识到，需要越来越重视数据产品，起飞应用系统核心支撑越来越依赖数据库产品，的适上层的编程语言仅仅是一种交互接口而已;底层的数据产品提供的能力，从某种程度上说，已经决定了业务系统的支撑能力，交互形式、甚至是编程方式、编程语言等。

Elasticsearch是b2b信息网数据产品领域一个不可替代的多面手，业务应用范围非常广，其最核心的能力是查询方式丰富，且查询性能杠杠的。下面就从ES查询方式的形态展开，看看它提供的哪些查询方式可以适配当下的业务痛点场景。

注：本文内容基于ES 7.15.x版本编写，若是其它版本可能会存在差异。

一、Query string query

Query string query(简称代号：QS)，英语直译“查询字符串”就是基于字符串表达式的一种查询语法，从当前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几乎支持了ES内部所有的查询表达式能力，其中全文文本分词查询(full text query)与词项精确查询(term level query)几乎是最常用的场景;还有一些高级的查询特性，在进入ES之前，见过很多工程师在代码中使用正则或者特别复杂的逻辑判断来替代，实在UGLY，代码丑陋，性能也丑陋。

DSL带来了丰富的查询表达能力，也带了一定的复杂度，也是被一些其它数据产品领域的工程师所抨击的地方，特别是SQL领域。本人认为这个是不正确的认知，相反，本人认为任何数据库产品都有自己的独特性，其独特的内部实现与应用场景，决定了它的能力，DSL由于其丰富的查询表达能力，需要稍微系统的学习一下，反而带来了比SQL更好的查询体验;在数据产品领域还有很多各自产品的DSL，如图数据产品Arrangodb、Cassandra等，正式由于他们的产品独特性，其表达方式已经验证了不能完全由SQL替代。

建议，千万不要因为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相比社区做了更多的创新，其中有一点，本人是特别推荐的，基于官方SQL执行查询，返回结果数据量同比DSL查询要减少近一倍;官方SQL支持多种数据格式查询结果，其中Json是最常用，也是REST API时代，广大程序员们最热衷的数据交互接口协议。这对于应用ES执行查询后需要返回大量数据结果场景非常好，大大减轻网络流量IO，也是一个性能优化点。

官方SQL同时为了兼容DSL，也提供了转换DSL的API，如果对于DSL不太熟悉，可以借助此能力。

官方SQL给带来很多优越的便利性，也存在一些局限性，并不完整支持标准的SQL，与当下最新的SQL兼容，很多查询特性还是有明显的DSL影子;官方SQL持续演进，从最早6.5.x到现在7.15.x，已经增加了很多SQL标准支持，但是SQL不能替代DSL，至今DSL依然是ES领域最好的查询方式，这一点必须要明确。

四、EQL

EQL 全称 Event Query Language ，直译过来“直接查询语言”，核心需要基于时序数据，必须要指定时间字段与类别字段，如日志，指标、全链路等场景，ES官方推出此查询方式主要目的是安全分析场景。

EQL目前并未在应用系统中非常大规模使用，介绍见到工程师使用，可能是其定位在安全分析场景原因。必须承认其带来的一些查询特性，其语法非常直观，表达式也非常丰富，对于有编程基础的工程师，非常容易掌握，必须强调，这是一个面向安全行业的设计的查询语言，所以运用其最多的应该也是安全方面的工程师。

五、ES查询方式内部

到目前为止，ES主要提供了以上4种查询方向，也分别按照以上顺序演进，还不存在谁替代谁，依然保持并行独立发展进化。ES执行所有的查询方式，先是转换为DSL，构建各自的QueryBuilder，其次构建各自的Query，最后交由Lucene执行。

六、经验认知

以上基于ES提供的查询方式，详细谈了一下个人的经验认知，仅仅在ES领域，就可以看到，如果我们深度的掌握ES数据产品，我们的工作方式与编程方式都会发生很大的变化，我们不再需要基于编程语言去构建复杂的原始查询业务场景，不在需要编程语言承载数据表达能力。

在面向数据编程时代，我们的编程方式与认知都需要进化，掌握一门编程语言仅仅是能做应用项目的第一步，编程语言掌握的深入其实本质上没有太多意义，一个应用系统最终需要的是数据产品来承载，编程语言仅仅是一个交互入口，我们可以在很短的时间内学会一门编程语言并进行项目实战，但是对于一个数据产品的掌控确需要相当长的时间与经验积累。

“ES玩的好，下班下得早!”不仅仅是一句ES的口号，更多的是期望通过“面向数据编程”理念，重新审视编程的本质。

参考资料

作者介绍

李猛，数据领域专家，Elastic Stack国内顶尖实战专家，国内首批Elastic官方认证工程师21人之一。2012年入手Elasticsearch，对Elastic Stack技术栈开发、架构、运维、源码、算法等方面有深入实战经验。负责过多种Elastic Stack项目，包括大数据分析领域、机器学习预测领域、业务查询加速领域、日志分析领域、基础指标监控领域等。十余年技术实战从业经验，擅长大数据多种技术栈混合，系统架构领域。

相关文章