解析ES的document核心元数据:_index,_type,_id,_source

解析ES的document核心元数据:_index,_type,_id,_source

96 WinnXUDONG 关注

2018.04.05 20:24 字数 1099 阅读 324评论 0喜欢 3

进入Kibana的DevTools执行下面操作:

#添加一条document
PUT /test_index/test_type/1
{
  "test_content":"test test"
}

#查询
GET /test_index/test_type/1
#返回
{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "1",
  "_version": 1,
  "found": true,
  "_source": {
    "test_content": "test test"
  }
}

1、 _index元数据解析

  • 代表这个document存放在哪个index中
  • 类似的数据放在一个索引,非类似的数据放不同索引。例如:product index(包含了所有的商品),sales index(包含了所有的商品销售数据),inventory index(包含了所有库存相关的数据)。如果你把比如product,sales,human resource(employee),全都放在一个大的index里面,比如说company index,不合适的。
  • index中包含了很多类似的document:类似是什么意思,其实指的就是说,这些document的fields很大一部分是相同的,你说你放了3个document,每个document的fields都完全不一样,这就不是类似了,就不太适合放到一个index里面去了。
  • 索引名称必须是小写的,不能用下划线开头,不能包含逗号:product,website,blog

     

    为什么类似的数据放在一个索引,非类似的数据放不同索引

2、 _type元数据解析

  • 代表document属于index中的哪个类别(type)
  • 一个索引通常会划分为多个type,逻辑上对index中有些许不同的几类数据进行分类:因为一批相同的数据,可能有很多相同的fields,但是还是可能会有一些轻微的不同,可能会有少数fields是不一样的,举个例子,就比如说,商品,可能划分为电子商品,生鲜商品,日化商品,等等。
  • type名称可以是大写或者小写,但是同时不能用下划线开头,不能包含逗号

3、 _id元数据解析

  • 代表document的唯一标识,id与index和type一起,可以唯一标识和定位一个document
  • 我们可以手动指定document的id(put /index/type/id),也可以不指定,由es自动为我们创建一个id

4、document id的手动指定与自动生成两种方式解析

1. 手动指定document id
(1)根据应用情况来说,是否满足手动指定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
#手动生成id
PUT /test_index/test_type/2
{
  "test_content": "my test"
}

2. 自动生成document id

#语法:
post /index/type
#自动生成id
POST /test_index/test_type
{
  "test_content": "my test"
}
#返回
{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "AWKVr3MWWhuqAs-7Mpj5",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "created": true
}

自动生成的id,长度为20个字符,URL安全,base64编码,GUID,分布式系统并行生成时不可能会发生冲突

GUID:GUID算法,可保证在分布式的环境下,不同节点同一时间创建的 _id 一定是不冲突的。

 

GUID不冲突解释

4、_source元数据以及定制返回结果解析

  1. _source元数据
#添加数据
put /test_index/test_type/1
{
  "test_field1": "test field1",
  "test_field2": "test field2"
}

#获取
get /test_index/test_type/1
#返回
{
  "_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串(所有的field),默认情况下,在get的时候,会原封不动的给我们返回回来。

  1. 定制返回结果

定制返回的结果,指定_source中,返回哪些field

#语法:
GET /test_index/test_type/1?_source=test_field2
#返回
{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "1",
  "_version": 2,
  "found": true,
  "_source": {
    "test_field2": "test field2"
  }
}

#也可返回多个field使用都好分割
GET /test_index/test_type/1?_source=test_field2,test_field1
展开阅读全文

没有更多推荐了,返回首页