elasticsearch学习笔记(十一)——document的核心元数据、操作以及原理

栏目: 后端 · 发布时间: 5年前

内容简介:先展示一个document数据结构下面我们就来开始分析了1、_index代表一个document存放在哪个index中

先展示一个document数据结构

GET /product/_doc/1

{
  "_index" : "product",
  "_type" : "_doc",
  "_id" : "1",
  "_version" : 1,
  "_seq_no" : 0,
  "_primary_term" : 1,
  "found" : true,
  "_source" : {
    "name" : "gaolujie yagao",
    "desc" : "gaoxiao meibai",
    "price" : 30,
    "producer" : "gaolujie producer",
    "tags" : [
      "meibai",
      "fangzhu"
    ]
  }
}

下面我们就来开始分析了

1、document的核心元数据

(1)_index元数据

1、_index代表一个document存放在哪个index中

2、对于document,类似的数据都是放在一个索引里面的,,非类似的数据放在不同的索引中。例如,product_index是包含了所有商品的index,sales_index是包含了所有商品的销售数据的index,inventory_index是包含了所有库存相关的数据。如果想把所有的这些数据都放在一个索引中,比如创建一个company_index,是不合适的。

3、对于每个索引一般都是包含了很多类似的document,类似是什么意思,其实指的就是说,这些document的fields很大一部分是相同的,如果说你放了三个document,但是每个document的fields都完全不一样,这就不是类似了,就不太适合放到一个index里面去了。

4、对于语法,要求每个索引名称必须是小写的,不能用下划线开头,不能包含逗号。

(2)_type元数据

1、_type代表这个document属于index中的哪个类别(type)

2、一个索引只能有一个type,在后面的ES高版本中可能会废弃掉

3、对于type的语法,它可以是大写或是小写,但是同时不能用下划线开头,不能包含逗号

(3)_id元数据

1、_id代表document的唯一标识,与index和type一起,可以唯一标识和定位一个document

2、我们可以手动指定document的id,也可以不指定,那ES就会自动为我们创建一个id

下面附上中华石衫老师的手工图,说明一下为什么不同类型的数据不用一个索引存放

elasticsearch学习笔记(十一)——document的核心元数据、操作以及原理

归纳一下就是如果把多个不同类型的数据放在一个索引中存储,当用户查询某一类的数据的时候比如商品数据,大量的请求过来,发现此时后台数据分析系统对这个索引下的另一类数据在做聚合分析比如销售数据,此时这些shard正在执行非常耗时,耗费资源的大型的聚合分析操作。就会导致document get请求,大量的性能不好,甚至超时。让用户感觉上来说,网速好慢,影响用户体验。

2、document id的生成

(1)手动指定document id

1、手动指定document id时,需要看下是否满足前提条件:

一般来说,是从某些其他的系统中,导入一些数据到es时,会采取这种方式,就是使用系统中已有数据的唯一标识,作为es中的document id。举个例子,假如我们现在在开发一个电商网站,做搜索功能,或者是OA系统,做员工的检索功能。这个时候数据首先会在网站系统或者IT系统内部的数据库中,会先有一份,此时肯定就会有一个数据库的primary id(自增长,UUID,或者是业务编号)如果将数据导入到ES中,此时就比较适合采用数据在数据库中的已有primary key。

2、格式

PUT /{index}/{type}/{id}

(2)自动生成document id

在什么情况下使用自动的document id。对于日志的搜集使用自动的document id是比较适合的。还有就是比如我们是在做一个系统,这个系统主要的数据存储就是es一种,也就是说,数据产生出来以后,可能就没有id,直接就放ES存储,那么这个时候,可能就不太适合说手动指定document id的形式了。

格式:

POST /{index}/{type}

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

3、_source元数据以及定制返回结果

(1)_source元数据

先用一个例子引出一个document的_source,以及它的结构

GET /product/_doc/1
{
  "_index" : "product",
  "_type" : "_doc",
  "_id" : "1",
  "_version" : 1,
  "_seq_no" : 0,
  "_primary_term" : 1,
  "found" : true,
  "_source" : {
    "name" : "gaolujie yagao",
    "desc" : "gaoxiao meibai",
    "price" : 30,
    "producer" : "gaolujie producer",
    "tags" : [
      "meibai",
      "fangzhu"
    ]
  }
}

可以看出_source元数据就是说,我们在创建一个document的时候,使用的那个放在request body请求体中的json串。

(2)定制返回结果

指定_source参数返回哪些field即可

GET /product/_doc/1?_source=name,desc,tags
{
  "_index" : "product",
  "_type" : "_doc",
  "_id" : "1",
  "_version" : 1,
  "_seq_no" : 0,
  "_primary_term" : 1,
  "found" : true,
  "_source" : {
    "name" : "gaolujie yagao",
    "desc" : "gaoxiao meibai",
    "tags" : [
      "meibai",
      "fangzhu"
    ]
  }
}

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

(1)document的全量替换

1、全量替换的语法和创建文档是一样的,如果document id不存在,那么就是创建;如果document id已经存在,那么就是全量替换操作,替换document的json串内容

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

3、ES会将老的document标记为deleted,然后新增我们给定的一个document,当我们创建越来越多的document的时候,es会在适当的时机在后台自动删除标记为deleted的document

(2)document强制创建

创建文档和全量替换的语法是一样的,但是有时我们想新建文档,不想替换文档

格式:

PUT /{index}/{type}/{id}?op_type=create

(3)document的删除

格式:

DELETE /{index}/{type}/{id}

注意删除并不是物理删除,只是会将文档标记为deleted,当数据越来越多的时候,会在后台自动删除


以上所述就是小编给大家介绍的《elasticsearch学习笔记(十一)——document的核心元数据、操作以及原理》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

信息乌托邦

信息乌托邦

桑斯坦 / 毕竞悦 / 法律出版社 / 2008-10-1 / 28.50元

我们被无限的媒体网从四面包围,如何能够确保最准确的信息脱颖而出、并且引起注意?在本书中,凯斯•R. 桑斯坦对于积蓄信息和运用知识改善我们生活的人类潜能,展示了深刻的乐观理解。 在一个信息超负荷的时代里,很容易退回到我们自己的偏见。人群很快就会变为暴徒。伊拉克战争的合法理由、安然破产、哥伦比亚号航天载人飞机的爆炸——所有这些都源自埋于“信息茧房”的领导和组织做出的决定,以他们的先入之见躲避意见......一起来看看 《信息乌托邦》 这本书的介绍吧!

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

随机密码生成器
随机密码生成器

多种字符组合密码

UNIX 时间戳转换
UNIX 时间戳转换

UNIX 时间戳转换