› ›

约定和术语

为了清晰起见，建立某些词语背后的含义是很重要的，因为相同的词语可能会对不同读者传达不同的含义，这取决于他们对SQL与Elasticsearch的熟悉程度。

本说明文档虽然力求完整，但假设读者对Elasticsearch和/或SQL有基本了解。如果情况并非如此，请继续阅读文档，但请做笔记并通过Elasticsearch主文档或通过开放的SQL资料中大量可用的资源来深入研究不清楚的主题（这里优秀的资源实在太多，无法一一列举）。

一般来说，正如名称所示，Elasticsearch SQL 提供了 SQL 接口到 Elasticsearch。因此，它尽可能遵循 SQL 术语和约定。然而，背后的引擎本身是 Elasticsearch，Elasticsearch SQL 正是为此而创建的，因此，在 SQL 中不可用或无法正确映射的功能或概念会出现在 Elasticsearch SQL 中。最后但同样重要的是，Elasticsearch SQL 尽量遵循最小惊奇原则，尽管正如世界上所有事物一样，一切都是相对的。

跨SQL和Elasticsearch的映射概念

edit

虽然SQL和Elasticsearch在数据组织方式（以及不同的语义）上有不同的术语，但本质上它们的目的是相同的。

所以让我们从底部开始；这些大致是：

SQL	Elasticsearch	Description
`列`	`字段`	在这两种情况下，在最底层，数据存储在具有各种数据类型的命名条目中，包含一个值。SQL 称这样的条目为列，而 Elasticsearch 称其为字段。请注意，在 Elasticsearch 中，一个字段可以包含多个相同类型的值（本质上是一个列表），而在 SQL 中，一个列只能包含恰好一个该类型的值。 Elasticsearch SQL 将尽最大努力保留 SQL 语义，并根据查询拒绝那些返回包含多个值的字段的查询。
`行`	`文档`	`列`和`字段`本身并不存在；它们是`行`或`文档`的一部分。这两者有略微不同的语义：`行`往往是严格的（并且有更多的强制性），而`文档`则往往更加灵活或松散（尽管仍然具有结构）。
`表`	`索引`	查询所针对的目标，无论是SQL还是Elasticsearch。
`schema`	隐式	在关系数据库管理系统（RDBMS）中，`schema` 主要是一个表的命名空间，通常用作安全边界。Elasticsearch 没有提供与之等效的概念。然而，当启用安全性时，Elasticsearch 会自动应用安全策略，使得一个角色只能看到其被允许访问的数据（在 SQL 术语中，即其 schema）。
`catalog` 或 `database`	`cluster` 实例	在SQL中，`catalog` 或 `database` 可以互换使用，并表示一组模式，即若干个表。在Elasticsearch中，可用索引的集合被分组在一个 `cluster` 中。语义也有所不同；`database` 本质上是一个命名空间（这可能会对数据的存储方式产生一些影响），而Elasticsearch的 `cluster` 是一个运行时实例，或者更确切地说，是一组至少一个Elasticsearch实例（通常以分布式方式运行）。实际上，这意味着在SQL中，一个实例内可能包含多个catalog，而在Elasticsearch中，只能有一个 cluster。
`集群`	`cluster`（联邦）	传统上在SQL中，集群指的是包含多个`目录`或`数据库`（见上文）的单个RDBMS实例。然而，在Elasticsearch中，同样的词也可以被重新使用，但其语义有所澄清。虽然关系型数据库管理系统（RDBMS）通常只有一个运行实例，位于单台机器上（非分布式），但Elasticsearch则采取了相反的方式，默认情况下是分布式的，并且是多实例的。此外，一个 Elasticsearch `集群` 可以通过联合方式连接到其他 `集群`，因此 `集群` 意味着：单个集群:: 多个 Elasticsearch 实例通常分布在多台机器上，运行在同一个命名空间内。多个集群:: 多个集群，每个集群都有自己的命名空间，通过联邦设置相互连接（参见跨集群搜索）。

正如人们所见，尽管概念之间的映射并不完全是一对一的，语义也有些不同，但共同点比差异更多。事实上，由于SQL的声明性质，许多概念可以透明地在Elasticsearch之间移动，并且在接下来的内容中，两者的术语可能会互换使用。

« Getting Started with SQL Security »