Elasticsearch由浅入深(三)document的核心元数据、Id、_source元数据、全量替换、强制创建以及删除机制
document的核心元数据
document的核心元数据有三个:_index、_type、_id
初始化数据:
PUT test_index/test_type/1 { "test_content":"test test" }
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
{ "_index": "test_index", "_type": "test_type", "_id": "1", "_version": 1, "result": "created", "_shards": { "total": 2, "successful": 1, "failed": 0 }, "created": true }
查询数据:
GET test_index/test_type/1
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
{ "_index": "test_index", "_type": "test_type", "_id": "1", "_version": 1, "found": true, "_source": { "test_content": "test test" } }
_index元数据
- 代表一个document存放在哪个index中
- 类似的数据放在一个索引中,非类似的数据放在不同的索引中:product index(包含了所有的商品)、sales index(包含了所有的商品销售数据)、inventory index(包含了所有库存的相关数据)
- index中包含了很多类似的document: 类似是什么意思呢,其实指的就是说,这些document的fields很大一部分是相同的,你说你放了3个document,每个document的fields都完全不一样,这就不是类似了,就不太适合放到一个index里面去了
- 索引名称必须是小写,不能用下划线开头,不包含逗号
_type元数据
- 代表document属于index的哪个类别
- 一个索引通常会划分为多个type,逻辑上对index有些许不同的几类数据进行分类
- type名称可以是大写或者小写,但是同时不能用下划线开头,不能包含逗号
_id元数据
- 代表document的唯一标识,与_index和_type一起可以起唯一标识和定位一个document
- 我们可以手动指定document的id,也可以不指定,由es自动为我们创建一个id
Id手动与自动生成
手动指定document id
根据应用情况来说,是否满足手动指定document id的前提:
一般来说,是从某些其他的系统中,导入一些数据到es时,会采取这种方式,就是使用系统中已有数据的唯一标识,作为es中document的id。举个例子,比如说,我们现在在开发一个电商网站,做搜索功能,或者是OA系统,做员工检索功能。这个时候,数据首先会在网站系统或者IT系统内部的数据库中,会先有一份,此时就肯定会有一个数据库的primary key(自增长,UUID,或者是业务编号)。如果将数据导入到es中,此时就比较适合采用数据在数据库中已有的primary key。
如果说,我们是在做一个系统,这个系统主要的数据存储就是es一种,也就是说,数据产生出来以后,可能就没有id,直接就放es一个存储,那么这个时候,可能就不太适合说手动指定document id的形式了,因为你也不知道id应该是什么,此时可以采取下面要讲解的让es自动生成id的方式。
语法:
put /index/type/id
{
“json”
}
示例:
PUT /test_index/test_type/2 { "test_content": "my test" }
自动生成document id
语法:
post /index/type { "json" }
示例:
POST /test_index/test_type { "test_content": "my test" }
{ "_index": "test_index", "_type": "test_type", "_id": "AWypxxLYFCl_S-ox4wvd", "_version": 1, "result": "created", "_shards": { "total": 2, "successful": 1, "failed": 0 }, "created": true }
自动生成的id,长度为20个字符,URL安全、base64编码、GUID、分布式系统并行生成时不可能发生冲突。
_source元数据以及定制返回结果解析
初始化数据:
put /test_index/test_type/1 { "test_field1": "test field1", "test_field2": "test field2" }
查看数据:
GET /test_index/test_type/1
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
{ "_index": "test_index", "_type": "test_type", "_id": "1", "_version": 2, "found": true, "_source": { "test_field1": "test field1", "test_field2": "test field2" } }
_source元数据,就是说,我们在创建一个document的时候,使用的那个放在request body中的json串,默认情况下,在get的时候会原封不动的给我们返回。
定制返回结果
定制返回的结果,指定_source中,返回哪些field
GET /test_index/test_type/1?_source=test_field1,test_field2
{ "_index": "test_index", "_type": "test_type", "_id": "1", "_version": 2, "found": true, "_source": { "test_field1": "test field1", "test_field2": "test field2" } }
全量替换、强制创建以及删除
document的全量替换
数据准备:
PUT test_index/test_type/4 { "test_field":"test test" }
- 语法与创建文档是一样的,如果document id不存在,那么就是创建;如果document id已经存在,那么就是全量替换操作,替换document的json串内容
- document是不可变的,如果要修改document的内容,第一种方式就是全量替换,直接对document重新建立索引,替换里面所有的内容
- es会将老的document标记为deleted,然后新增我们给定的一个document,当我们创建越来越多的document的时候,es会在适当的时机在后台自动删除标记为deleted的document
document的强制创建
创建文档与全量替换的语法是一样的,有时我们只是想新建文档,不想替换文档,如果强制进行创建呢?
语法:
PUT /index/type/id?op_type=create
或者
PUT /index/type/id/_create
document的删除
语法:
DELETE /index/type/id
不会理解物理删除,只会将其标记为deleted,当数据越来越多的时候,在后台自动删除
-------------------------------------------
个性签名:独学而无友,则孤陋而寡闻。做一个灵魂有趣的人!
如果觉得这篇文章对你有小小的帮助的话,记得在右下角点个“推荐”哦,博主在此感谢!
万水千山总是情,打赏一分行不行,所以如果你心情还比较高兴,也是可以扫码打赏博主,哈哈哈(っ•̀ω•́)っ✎⁾⁾!
![](https://www.cnblogs.com/images/cnblogs_com/wyt007/1375409/t_alipay.bmp)
![](https://www.cnblogs.com/images/cnblogs_com/wyt007/1375409/t_wxpay.bmp)