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

一、文档的crud介绍

elasticsearch中存在五种操作，分别如下：

1、index

该操作表示：如果文档的id不存在，则创建新的文档。若有相同的id，先删除现有文档，然后再创建新的文档，同时版本会增加。

语法格式如下：

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

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

2、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"}

3、update

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

语法格式如下：

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

4、delete

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

语法格式如下：

delete index_name/_doc/100

5、read

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

语法格式如下：

get index_name/_doc/100

注意：index操作相对于create、update操作的不同之处在于：如果文档不存在，index就会创建新的文档。否则，如果文档存在，现有文档会被删除，新的文档会被创建，版本信息也会加1。而反观create操作，如果具有相同文档id的文档信息存在了，则不能创建新的文档，会报错；update操作，如果发现有相同文档id的信息，不会删除原来的文档，而是实现真正的数据更新，若没有发现相同的文档id，则会报错。

 

二、文档crud操作实例

我们现在通过kibana中的dev tools进行上述操作的演示：

1、create操作

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

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

　　2）指定文档id的方式

如果文档id已经存在，则会报错，如下所示：

2、read操作

通过给定相应文档id，可以读取相应的文档信息，如下所示：

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

 3、index操作

通过执行index操作，我们可以发现，version由1更改为2。同时通过读取文档id为100的信息，会发现name变成了“张三”，而字段des已经不存在了。说明index操作是先删除原有id的文档记录，然后再创建一个相同id的文档信息。

4、update操作

因为上面在执行index操作时，文档的des字段已经不存在了，现在将这个字段增加到文档id为100的文档上，此时就需要执行update操作，如下所示：

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

5、delete操作

 

三、文档批量操作

1、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操作中，若有单条操作失败，并不会影响其他操作。同时，返回结果包括了每一条操作执行的结果。

2、mget（批量读取）

mget与bulk api的思路是一样的，都是为了减少网络连接所产生的开销，以提高性能。通过提供一系列的文档id，在一次api请求中，就可以将所有的文档信息返回回来。

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

 3、msearch（批量查询）

msearch通过一次rest访问，对不同的索引进行不同的查询。

通过上图中可以看出，此次批量查询一共执行了三段查询操作，第一次是针对索引users，查询文档id大于等于1的文档信息，一共查询10条；第二次是查询索引users中所有的文档信息；第三条是查询索引shops中所有的文档信息。

 

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

1、对于bulk api、mget、msearch等批量操作的api，通过调用它们可以很好的提高性能，但是在调用时也不要过多的发送数据，否则也会容易导致es集群过大的压力，造成性能的下降。

那么过多的数据一般控制在多少为好呢？一般建议是1000-5000个文档，如果文档很大，可以适当减少队列，大小建议是5-15m，默认不能超过100m，否则会报错。

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

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

4、自创建文档id时，需要考虑id的均衡性，避免产生分配不均衡的问题。

 

　大家可关注我的公众号

　　

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