查询DSL的正式规范？

Question

这个问题9年前就被问过。当时没有给出满意的答复。

如果你搜索这个，你会发现 a 2010 thread 涉及 Shay Bannon 零碎地解释为什么 OP 关于这样一个规范的猜测不太正确。但没有解释我们在哪里可以找到查询 DSL 如何工作以及如何不工作的完整细节。

这是由我开始阅读《Elasticsearch In Action》第二版（2023 年出版）引发的。请记住，所谓的“权威指南”已经过时了大约 8 年，而且自那时以来，ES（以及“Elastic Stack”）上已经出版了许多绝对糟糕的书籍，这是非常受欢迎的。

我目前是 ES 的近乎初学者/改进程度较低的人。在第 59 页，当我试图了解 DSL 的工作原理时，我看到了这个示例：

GET books/_search
{
  "query": {
    "match": {
      "author": { #A
        "query": "Joshua Schildt", #B
        "operator": "AND" #C
      }
    }
  }
}

...我可以看到键“query”在同一 JSON 结构中出现了两次。所以我自然地开始想：好吧，“查询”的使用是否以某种方式递归，即可能会引入非常非常复杂的深度嵌套查询？还是不？

要回答这样的问题，我需要一个适当的规范。

如果做不到这一点，理解这些方面的唯一方法是分析源代码吗？考虑到 ES 的发展规模，如果 2023 年不存在这样的规范，我认为这绝对是荒谬的。甚至还有一个“querydsl”的 SO 标签。

Answer 1

第一个

query

是

_search

端点的一个选项，您可以在其中指定查询，无论查询有多复杂。

第二个

query

是包含要搜索的术语的

match

查询的参数。同意，它可以被称为

value

或

input

或

whatever

。它没有什么递归性，我承认它可能会让新手望而却步，但这就像能够在函数外部和函数内部声明一个

int

变量一样。没有最佳实践表明关键字只能在给定语言的单个特定上下文中使用一次。

无论如何，我已经使用 DSL 13 年多了，但我同意 DSL 规范早就应该制定了。但是，如果我们重用您提供的示例查询并决定使用 OR 运算符而不是 AND 运算符，我们可以以简短形式编写如下，因为我们使用所有默认参数或

match

查询：

GET books/_search
{
  "query": {
    "match": {
      "author": "Joshua Schildt"
    }
  }
}

如您所见，不再有

query

并且

author

参数直接分配搜索项，而不是带有查询参数的 JSON 哈希。这种灵活性使得制定清晰的 DSL 规范变得困难，因为根据您想要的配置方式，有许多不同的方式来编写查询。

确实有一个关于可以在客户端和 Elasticsearch 服务器之间交换的所有操作和数据类型的 TypeScript “规范”，您可以在

elastic/elasticsearch-specification

Github 存储库中找到它，也可以准确地找到

 match

查询，其中描述了所有可能的参数。

在第 282 行，我们甚至可以看到

MatchQuery

带有

@shortcut_property query

注释，这意味着整个 JSON 结构可以替换为我们之前看到的

query

参数的值。