ElasticSearch常见名词解释

文档元数据

一个文档不只有数据。它还包含了 元数据(metadata)—— 关于文档的信息。三个必须的元数据节点是：

节点  说明

index 索引）  文档存储的地方 索引时具有相同结构的文档集合。例如，有一个用户信息的索引、订单数据的索引。

type 文档代表的对象的类型 在索引中，可以定义一个或多个类型，类型是索引的逻辑分区，一般情况下，一种类型被定义为具有一组公共字段的文档。

document（文档）

文档是存储在ElasticSearch中的一个JSON格式的字符串。它就像是关系型数据库中表的一行。每个存储在索引中的一个文档都有一个类型和一个ID，每个文档都是一个JSON对象，存储了零个或多个字段。

id  文档的唯一标识

 

mapping（映射）
映射像关系型数据库中的表结构，每个索引都有一个映射，它定义了索引中每一个字段类型。
14、field（字段）
文档中包含零个或多个字段，字段可以是一个简单的值（例如字符串、整数、日期），也可以是一个数组或对象。字段类似于关系型数据库中表的列。每个字段都对应一个字段类型，例如字符串、整数、日期、对象等。

索引(index)

这里说的索引，是一个名词，一个存储关联数据的地方。实际上，索引只是一个用来指向一个或多个分片(shards)的“逻辑命名空间”。 索引(index)类似于关系型数据库里的“数据库”——它是我们存储和索引关联数据的地方。

事实上，我们的数据被存储和索引在 分片(shards)中，索引只是一个把一个或多个分片分组在一起的逻辑空间。然而，这只是一些内部细节——我们的程序完全不用关心分片。对于我们的程序而言，文档存储在 索引(index)中。剩下的细节由Elasticsearch关心既可。

类型（type） 

在应用中，我们使用对象表示一些“事物”，例如一个用户、一篇博客、一个评论，或者一封邮件。每个对象都属于一个 类(class)，这个类定义了属性或与对象关联的数据。 user 类的对象可能包含姓名、性别、年龄和Email地址。      

在关系型数据库中，我们经常将相同类的对象存储在一个表里，因为它们有着相同的结构。同理，在Elasticsearch中，我们使用相同 类型(type)的文档表示相同的“事物”，因为他们的数据结构也是相同的。在ES中的type就相当于关系型数据库中的表。

每个 类型(type)都有自己的映射(mapping)或者结构定义，就像传统数据库表中的列一样。所有类型下的文档被存储在同一个索引下，但是类型的映射(mapping)会告诉Elasticsearch不同的文档如何被索引。 

_type 的名字可以是大写或小写，不能包含下划线或逗号。我们将使用``blog`做为类型名。      

一个索引可以有多个类型。例如一个索引下可以有文章类型，也可以有用户类型，也可以有评论类型。在一个索引中不能再创建多个类型，在以后的版本中将删除类型的整个概念。

在Elasticsearch 7.0.0或更高版本中创建的索引不再接受 _default_映射。在6.x中创建的索引将继续像以前一样在Elasticsearch 6.x中运行。在7.0中的API中不推荐使用类型，对索引创建，放置映射，获取映射，放置模板，获取模板和获取字段映射API进行重大更改

        ES7之后Type被完全废弃，即只有index(索引，等同于数据库+表定义)和Document（文档，即行记录）

唯一标识（id）

id仅仅是一个字符串，它与 _index 和 _type 组合时，就可以在ELasticsearch中唯一标识一个文档。当创建一个文档，你可以自定义 _id ，也可以让Elasticsearch帮你自动生成。（自动生成ID需要用Post请求）

field（字段）
文档中包含零个或多个字段，字段可以是一个简单的值（例如字符串、整数、日期），也可以是一个数组或对象。字段类似于关系型数据库中表的列。每个字段都对应一个字段类型，例如字符串、整数、日期、对象等。
source field（来源字段）
默认情况下，文档将被存储在_source字段中，当查询时也是返回这个字段。

分片(shard)

一个分片是一个最小级别的工作单元。他只是保存了索引中所有数据的一部分，分片就是一个lucene实例，他本身就是一个完整的搜索引擎。我们的文档存储在分片中，并且在分片中被索引，但应用程序不会直接与分片进行通信，而是直接与索引进行通信。

分片是ElasticSearch在集群中分发数据的关键，把分片想象成数据的容器，文档存储在分片中，然后分片分配到集群中的节点上。当集群扩容或缩小，ES会自动在你的节点间迁移分片，使集群保持平衡。

分片可以是主分片和复制分片。索引中的每个文档属于一个单独的主分片，所以主分片的数量决定了索引最多能存储多少数据。

复制分片只是主分片的一个副本，它可以防止硬件故障导致的数据丢失，同时可以提供读请求，比如搜索或者从别的shard取回文档

当索引创建完成的时候，主分片的数量就固定了，但是复制分片的数量可以随时调整。

文档的索引将首先被存储在主分片中，然后并发复制到对应的复制节点上。这可以确保我们的数据在主节点和复制节点上都可以被检索。理论上讲，随着节点的增加，ES的搜索性能也会随之增加（因为在分片数一定的情况下，节点数越多，每个分片所能分到到硬件资源 内存，CPU等越高。但节点数不大于分片数）。

当然，在同样数量的节点上增加更多的复制分片并不能提高性能，因为这样做的话平均每个分片的所占有的硬件资源就减少了，你需要增加硬件来提高吞吐量。不过这些额外的复制分片使我们有更多的冗余：也就是说在节点充裕的情况下，增加复制分片，是通过空间换时间；
————————————————
索引有两层含义：
1. 搜索中的数据库或表的定义
2. 构建文档时候的索引创建

分词：
1. 搜索是以词为单位做最基本的搜索单元
2. 依靠分词器构建分词
3. 用分词构建倒排索引

假设我要求职，这里我们有一张职位数据表jobs，我想从中检索一些我想要的工作，一般我会先想好关键词，比如"舒适办公环境"、"有良好晋升空间"等，如果用MySQL实现，你可能会这样写SQL：SELECT * FROM jobs WHERE job_desc LIKE %关键词%。这样做，理论上是可以搜到一些数据的，比如和用户输入的关键词完全匹配的就可以，但是假设jobs表中很多对工作职位的描述换了个说法，比如"办公环境舒适"、"晋升空间良好"等，颠倒了词的顺序，LIKE关键词肯定是匹配不到了。另外，LIKE是全表扫描的一个操作，如果你的数据量较小，还好说，但如果你数据量在百万、千万甚至更多的时候，耗时将是不可想象的，更别说还有恼人的分词问题，单单使用MySQL是无法解决的。

https://zhuanlan.zhihu.com/p/32112952

 

ElasticSearch(7.2.2)-为什么不⽤mysql做全⽂搜索