需要注意的是,Elastic Search 6之后,_type 只有一个,而到了Elastic Search 7 之后,取消了 _type。

为什么 _type 被移除了?

起初,我们说"索引"和关系数据库的“库”是相似的,“类型”和“表”是对等的。这是一个不正确的对比,导致了不正确的假设。在关系型数据库里,"表"是相互独立的,一个“表”里的列和另外一个“表”的同名列没有关系,互不影响。但在类型里字段不是这样的。在一个Elasticsearch索引里,所有不同类型的同名字段内部使用的是同一个lucene字段存储。也就是说,上面例子中,user类型的user_name字段和tweet类型的user_name字段是存储在一个字段里的,两个类型里的user_name必须有一样的字段定义。这可能导致一些问题,例如你希望同一个索引中"deleted"字段在一个类型里是存储日期值,在另外一个类型里存储布尔值。最后,在同一个索引中,存储仅有小部分字段相同或者全部字段都不相同的文档,会导致数据稀疏,影响Lucene有效压缩数据的能力。因为这些原因,我们决定从Elasticsearch中移除类型的概念。
_id
文档唯一标识
ID 是一个字符串,当它和_index以及_type组合就可以唯一确定 Elasticsearch 中的一个文档。 当你创建一个新的文档,要么提供自己的_id,要么让 Elasticsearch 帮你生成。
当Elastic Search7 取消_type之后,及_index和_id即可确定唯一的文档。

六、新建,索引,删除操作的基本逻辑

集群
假设我们如上面所示,上面每个节点都可以接收写请求,那么新增数据的一个流程如下所示:
步骤顺序如下:
(1) 客户端向Node1发送新建请求(如果客户端向Node2或者Node3等其他节点发送请求,请求会被转发给Master节点,本图中为Node1,更新,删除同理)。
(2) master根据_id确定文档属于分片0,那么请求会被转发到Node3,因为分片 0 的主分片目前被分配在 Node3上。
(3) Node 3在主分片上面执行请求。如果成功了,它将请求并行转发到 Node 1和Node 2 的副本分片上。一旦所有的副本分片都报告成功, Node3 将向Master节点报告成功,Master节点向客户端报告成功(ES新版本是可用shard写入成功过半,Node3会发送消息给master,并由Master节点转发给请求来源节点)。
在客户端收到成功响应时,文档变更已经在主分片和所有副本分片执行完成,变更是安全的。

七、查询的基本逻辑

以下是从主分片或者副本分片检索文档的步骤顺序:
1、客户端向Node 1发送获取请求。
2、节点使用文档的_id来确定文档属于分片0。分片0的副本分片存在于所有的三个节点上。 在这种情况下,它将请求转发到Node 2。在处理读取请求时,Master节点在每次请求的时候都会通过轮询所有的副本分片来达到负载均衡,因此会转发请求到Node 2。
3、Node 2将文档返回给Node 1,然后将文档返回给客户端。
在文档被检索时,已经被索引的文档可能已经存在于主分片上但是还没有复制到副本分片。 在这种情况下,副本分片可能会报告文档不存在,但是主分片可能成功返回文档。 一旦索引请求成功返回给用户,文档在主分片和副本分片都是可用的。