进入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元数据以及定制返回结果解析
- _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的时候，会原封不动的给我们返回回来。
- 定制返回结果
定制返回的结果，指定_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
