约定和术语
Elastic Stack Serverless
为了清晰起见，重要的是要确定某些词背后的含义，因为同样的措辞可能会根据读者对 SQL 与 Elasticsearch 的熟悉程度，向不同的读者传达不同的含义。
注意
本文档虽然力求完整，但确实假设读者对 Elasticsearch 和/或 SQL 有基本的理解。如果情况并非如此，请继续阅读文档，但记下笔记，并通过主要的 Elasticsearch 文档或开放源代码中提供的大量 SQL 材料来追溯不清楚的主题（这里有太多优秀的资源无法一一列举）。
作为一般规则，Elasticsearch SQL 顾名思义，提供了一个 Elasticsearch 的 SQL 接口。因此，在可能的情况下，它首先遵循 SQL 术语和约定。然而，支持引擎本身就是 Elasticsearch，Elasticsearch SQL 是专门为其创建的，因此 SQL 中不可用或无法正确映射的功能或概念会出现在 Elasticsearch SQL 中。最后但同样重要的是，Elasticsearch SQL 试图遵守 最小惊讶原则，尽管与世界上的所有事物一样，一切都是相对的。
虽然 SQL 和 Elasticsearch 对于数据的组织方式有不同的术语（和不同的语义），但本质上它们的目的是相同的。
所以让我们从底部开始；这些大致是
| SQL | Elasticsearch | 描述 |
|---|---|---|
列 (column) |
字段 (field) |
在这两种情况下，在最低级别，数据都存储在命名的条目中，这些条目具有各种数据类型，包含一个值。 SQL 将这样的条目称为列，而 Elasticsearch 称为字段。请注意，在 Elasticsearch 中，一个字段可以包含相同类型的多个值（本质上是一个列表），而在 SQL 中，一个列可以包含该类型的恰好一个值。Elasticsearch SQL 将尽最大努力保留 SQL 语义，并根据查询，拒绝那些返回多个值的字段的查询。 |
行 (row) |
文档 (document) |
Column 和 field 本身并不存在；它们是 row 或 document 的一部分。 两者具有略微不同的语义：row 倾向于严格（并具有更多强制执行），而 document 倾向于更灵活或松散（同时仍具有结构）。 |
表 (table) |
索引 (index) |
无论是 SQL 还是 Elasticsearch，查询都针对的目标。 |
模式 (schema) |
隐式 (implicit) | 在 RDBMS 中，schema 主要是一个表命名空间，通常用作安全边界。 Elasticsearch 没有为此提供等效的概念。 但是，启用安全性后，Elasticsearch 会自动应用安全强制，以便角色只能看到允许的数据（用 SQL 行话说，就是它的schema）。 |
catalog 或 database |
cluster 实例 |
在 SQL 中，catalog 或 database 可以互换使用，表示一组 schema，即许多表。在 Elasticsearch 中，可用的索引集被分组到一个 cluster 中。 语义也有点不同；database 本质上是另一个命名空间（可能对数据的存储方式产生一些影响），而 Elasticsearch cluster 是一个运行时实例，或者更确切地说，是至少一个 Elasticsearch 实例的集合（通常以分布式方式运行）。实际上，这意味着虽然在 SQL 中，一个实例中可能包含多个 catalog，但在 Elasticsearch 中，一个实例只能限制为一个。 |
集群 (cluster) |
cluster (联合) |
传统上，在 SQL 中，cluster 指的是一个包含多个 catalog 或 database 的单个 RDBMS 实例（参见上文）。 Elasticsearch 中也可以重复使用同一个词，但其语义需要稍微澄清一下。虽然 RDBMS 往往只有一个在单台机器上运行的实例（不是分布式的），但 Elasticsearch 却相反，默认情况下是分布式和多实例的。 此外，Elasticsearch cluster 可以以联合方式连接到其他 cluster，因此 cluster 的意思是单个集群 <> 多个 Elasticsearch 实例通常分布在多台机器上，在同一命名空间中运行。多个集群多个集群，每个集群都有自己的命名空间，以联合设置相互连接（请参阅跨集群搜索）。 |
可以看出，虽然概念之间的映射并非完全一一对应，并且语义有所不同，但共同点多于差异。 事实上，由于 SQL 的声明性，许多概念可以透明地跨 Elasticsearch 移动，并且这两种术语可能会在其余材料中互换使用。