老余博客上线了!!!

ElasticStack学习(四):ElasticSearch文档的CRUD使用

后端 老余 7℃ 0评论

一、文档的CRUD介绍 ElasticSearch中存在五种操作,分别如下: 1、Index 该操作表示:如果文档的ID不存在,则创建新的文档。若有相同的ID,先删除现有文档,然后再创建新的文档,同时版本会增加。 语法格式如下: PUT index_name/_doc/100 ...

一、文档的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核心技术与实战》

转载请注明:老余博客 » ElasticStack学习(四):ElasticSearch文档的CRUD使用

读后有收获可以请作者喝咖啡:

喜欢 (0)or分享 (0)
发表我的评论
取消评论
表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址