13document相关知识

初步解析document的核心元数据：_index,_type,_id 1、_index元数据

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

比如product，website，blog

index创建的反例

假如有一个很大的index,叫做company index。里面存放着很多种document，比如product （包含了所有的商品），sales （包含了所有的商品销售数据），inventory （包含了所有库存相关的数据）等等，每种document的fileds都是完全不同的。

根据负载均衡，那么每个shard里面都可能包含了各种样式的数据。

假如后天数据分析系统要搜索最近一年销售相关的趋势变化，并且还要算出各种复杂的数据指标分析，进行aggs聚合，那么这一条超复杂的聚合分析查询，设计的数据量很大，非常耗时才能完成这一次数据分析，而且所有的shard都会耗费大量的资源：IO、CPU、memory。

在执行非常耗时的复杂聚合分析查询时，有可能电商网站前台发来查询product数据的请求，如果并发量非常大，请求落到了正在进行聚合分析查询的shard上，这些shard正在执行复杂的查询，可能导致用户的请求响应不及时甚至超时，影响了用户的体验。

这样我们可以将相同功能的数据放在同一个index，放在独立的一个shard中，与其他的数据不在同一个shard中，就不会互相影响了。

2、_type元数据

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

Elasticsearch 6.X 中，一个 index 下已经只能包含一个 type， Elasticsearch 7.X 中, Type 的概念已经被删除了。

3、_id元数据

（1）代表document的唯一标识，与index和type一起，可以唯一标识和定位一个document （2）我们可以手动指定document的id（put /index/type/id），也可以不指定，由es自动为我们创建一个id

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "1",
  "_version": 1,
  "found": true,
  "_source": {
    "test_content": "test test"
  }
}

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的方式。

（2）put /index/type/id

PUT /test_index/test_type/2
{
  "test_content": "my test"
}

2、自动生成document id

（1）post /index/type

POST /test_index/test_type
{
  "test_content": "my test"
}

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "AVp4RN0bhjxldOOnBxaE",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "created": true
}

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

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

所以es的自动生成_ id的机制，绝对能够保证不会出现两个document的_ id是一样的

document的_source元数据以及定制返回结果解析 1、_source元数据

PUT /test_index/test_type/1
{
  "test_field1": "test field1",
  "test_field2": "test field2"
}

响应结果

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "1",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 1,
    "successful": 1,
    "failed": 0
  },
  "created": true
}

查询

GET /test_index/test_type/1

响应结果

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "1",
  "_version": 1,
  "found": true,
  "_source": {
    "test_field1": "test field1",
    "test_field2": "test field2"
  }
}

_source元数据：就是说，我们在创建一个document的时候，使用的那个放在request body中的json串，默认情况下，在get的时候，会原封不动的给我们返回回来。

2、定制返回结果

有时候我们不想返回所有的field，可以定制返回的结果，指定_source中，返回哪些field

GET /test_index/test_type/1?_source=test_field2

响应结果

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "1",
  "_version": 1,
  "found": true,
  "_source": {
    "test_field2": "test field2"
  }
}

也可以指定多个filed

GET /test_index/test_type/1?_source=test_field1,test_field2

响应结果

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "1",
  "_version": 3,
  "found": true,
  "_source": {
    "test_field1": "test field1",
    "test_field2": "test field2"
  }
}

document的全量替换、强制创建以及图解lazy delete机制 1、document的全量替换

（1）语法与创建文档是一样的，如果document id不存在，那么就是创建；如果document id已经存在，那么就是全量替换操作，替换document的json串内容

PUT /test_index/test_type/4
{
  "test_field1": "test field1"
}

响应结果

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "4",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "created": true
}

version ： 1 created: true

全量替换

PUT /test_index/test_type/4
{
  "test_field1": "test field111111"
}

响应结果

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "4",
  "_version": 2,
  "result": "updated",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "created": false
}

version ： 2 created : false

（2）document是不可变的，如果要修改document的内容，第一种方式就是全量替换，直接对document重新建立索引，替换里面所有的内容

全量替换

（3)es会将老的document标记为deleted，然后新增我们给定的一个document，当我们创建越来越多的document的时候，es会在适当的时机在后台自动删除标记为deleted的document，以释放空间。

2、document的强制创建

（1）创建文档与全量替换的语法是一样的，有时我们只是想新建文档，不想替换文档，可以强制进行创建 （2）强制创建

PUT /index/type/id?op_type=create

或

PUT /index/type/id/_create

3、document的删除

（1）DELETE /index/type/id （2）和全量替换的原理一样，不会直接物理删除，只会将其标记为deleted，当数据越来越多的时候，在后台自动删除标记为deleted的document，以释放空间。