ElasticStack学习（四）：ElasticSearch文档的CRUD使用

1、文档的CRUD介绍

ElasticSearch中存在五种操做，分别以下：

一、Index

该操做表示：若是文档的ID不存在，则建立新的文档。如有相同的ID，先删除现有文档，而后再建立新的文档，同时版本会增长。

语法格式以下：

PUT index_name/_doc/100
{"field1":"value1","field2":"value2"}

其中，index_name【索引名称】，_doc【Type名称，约定都用_doc】，100【文档ID】

二、Create

该操做表示：建立新的文档，可是若是ID已经存在，会失败。

该操做支持两种操做方式：1）自动生成文档ID；2）指定文档ID；

语法格式以下：

根据文档ID，建立文档信息。（指定文档ID的方式）
PUT index_name/_create/100
{"field1":"value1","field2":"value2"}
或者

PUT index_name/_doc/100?op_type=create
{"field1":"value1","field2":"value2"}

若不指定文档ID，建立文档时会自动生成。（自动生成文档ID的方式）
POST index_name/_doc
{"field1":"value1","field2":"value2"}

三、Update

该操做表示：更新的文档必须存在，更新时只会对相应字段作增量修改。

语法格式以下：

POST index_name/_update/100
{
    "doc":{"field1":"value1","field2":"value2"}  
}

四、Delete

该操做表示：根据文档ID，对相应文档进行删除。

语法格式以下：

DELETE index_name/_doc/100

五、Read

该操做表示：根据文档ID，获取相应文档信息。

语法格式以下：

GET index_name/_doc/100

注意：Index操做相对于Create、Update操做的不一样之处在于：若是文档不存在，Index就会建立新的文档。不然，若是文档存在，现有文档会被删除，新的文档会被建立，版本信息也会加1。而反观Create操做，若是具备相同文档ID的文档信息存在了，则不能建立新的文档，会报错；Update操做，若是发现有相同文档ID的信息，不会删除原来的文档，而是实现真正的数据更新，若没有发现相同的文档ID，则会报错。

 

2、文档CRUD操做实例

咱们如今经过Kibana中的Dev Tools进行上述操做的演示：

一、Create操做

　　1）自动生成文档ID的方式

经过以自动生成文档ID的形式进行文档建立，会发现建立的文档ID是自动生成的，版本为1。

　　2）指定文档ID的方式

若是文档ID已经存在，则会报错，以下所示：

二、Read操做

经过给定相应文档ID，能够读取相应的文档信息，以下所示：

从读取出来的结果信息中能够发现，蓝色区域部分就是文档的metadata，包括索引的名称、类型、文档ID、版本等信息；红色区域部分就是文档的全部原始信息。

 三、Index操做

经过执行Index操做，咱们能够发现，version由1更改成2。同时经过读取文档ID为100的信息，会发现name变成了“张三”，而字段des已经不存在了。说明Index操做是先删除原有ID的文档记录，而后再建立一个相同ID的文档信息。

四、Update操做

由于上面在执行Index操做时，文档的Des字段已经不存在了，如今将这个字段增长到文档ID为100的文档上，此时就须要执行Update操做，以下所示：

读取文档信息后会发现，文档信息中新增长了”des"、"age"两个字段，同时版本号又增长了一次。

五、Delete操做

 

3、文档批量操做

一、Bulk API（批量操做）

Bulk API的做用：在访问网络API时，每一次的访问都须要从新创建网络开销，所以是很是损耗性能的。 而Bulk API的核心思想就是在一次Rest请求中，对不一样索引执行屡次操做。它支持四种操做类型：Index、Create、Update、Delete。

经过上图中实例操做，能够看出：

1）对于索引“users”执行index操做，返回成功；

2）对于索引"users"中，文档ID为2的文档信息进行删除，返回状态是404，结果是not_found，说明在索引“users”中并无文档ID=2的文档信息；

3）对于索引"users"中，文档ID为2的文档信息进行更新，新增字段field2；

4）对于索引"shops"中，建立文档ID为1的文档信息；

在Bulk API操做中，如有单条操做失败，并不会影响其余操做。同时，返回结果包括了每一条操做执行的结果。

二、mget（批量读取）

mget与Bulk API的思路是同样的，都是为了减小网络链接所产生的开销，以提升性能。经过提供一系列的文档ID，在一次API请求中，就能够将全部的文档信息返回回来。

上图中，咱们经过mget操做访问索引“users”中文档ID为“1”、“101”的文档信息，访问索引“shops”中文档ID为“1”的文档信息。其中两条均返回成功，而文档ID=101的文档信息没有找到。

 三、msearch（批量查询）

msearch经过一次Rest访问，对不一样的索引进行不一样的查询。

经过上图中能够看出，这次批量查询一共执行了三段查询操做，第一次是针对索引users，查询文档ID大于等于1的文档信息，一共查询10条；第二次是查询索引users中全部的文档信息；第三条是查询索引shops中全部的文档信息。

 

4、常见错误返回说明及注意事项 

一、对于Bulk API、mget、msearch等批量操做的API，经过调用它们能够很好的提升性能，可是在调用时也不要过多的发送数据，不然也会容易致使ES集群过大的压力，形成性能的降低。

那么过多的数据通常控制在多少为好呢？通常建议是1000-5000个文档，若是文档很大，能够适当减小队列，大小建议是5-15M，默认不能超过100M，不然会报错。

二、虽咱们在执行CU操做，或者批量执行CU操做时，动态的向索引更新或者建立了字段。此时并无对索引预先作mapping定义，可是ES也会根据文档类型进行类型推断，将新增的字段定义在mapping中。在生产环境中，建议作mapping设定后再写入数据。

三、mget与msearch的区别：mget是经过文档ID列表获得文档信息，msearch是根据查询条件，搜索到相关文档。

四、自建立文档ID时，须要考虑ID的均衡性，避免产生分配不均衡的问题。

 

　你们可关注个人公众号

　　

　　知识学习来源：《Elasticsearch核心技术与实战》