Elasticsearch系列---全面了解Document

概要

本篇主要介绍一下document的知识,对document的元数据和基本的语法进行讲解。

document核心元数据

前面入门实战一节有简单介绍过document数据示例,这次我们来详细了解一下它的核心元数据,查询响应报文如下:

{
  "_index": "music",
  "_type": "children",
  "_id": "1",
  "_version": 1,
  "found": true,
  "_source": {
    "name": "gymbo",
    "content": "I hava a friend who loves smile, gymbo is his name",
    "language": "english",
    "length": "75"
  }
}

_index元数据

代表一个document存放在哪个index中,项目约定结构类似的数据放在一个索引,不同数据放不同索引里,所以同一个index中document结构基本是类似的,个别document多一个或少一个field,这样Elasticsearch对磁盘存储的利用率最高。
每个index有自己独立的shard存储文件,与其他index互不影响。

命名规范:名称小写,不能以‘_‘, ‘-‘, 或 ‘+‘开头。

_type元数据

ES 6.0.0之后一个index下面只能有一个type,最早指定是啥就是啥。

命名规范:可以用‘_‘开头,由于只有一个,官方示例上直接使用‘_doc‘。

_id元数据

document的唯一标识,与index一起唯一标识和定位一个document,可以手动指定,也可以由ES自动创建。

_version元数据

ES内部使用乐观锁对document的写操作进行控制,version版本号最初是1,更新操作成功后自动+1。

found元数据

document的搜索标志,成功是true,未搜索到是false。

_source元数据

里面是我们在新增时放在http request body的json串内容,是保存的业务数据,默认Get操作时,会原封不动地全部返回给客户端。

用Get命令搜索document时,可以定制返回的结果,在请求的_source中指定想要的field即可,示例命令:

GET /music/children/_search
{
  "query": {
    "match_all" : {}
  },
  "_source": ["name","content"]
}

document id

document的id手动指定与自动生成两种方式:

  1. 手动指定
    PUT命令行指定ID时,即手动方式

PUT /music/children/id

  1. 自动生成
    PUT命令行没指定ID时,此时ES会自动生成的id,长度为20个字符,URI安全,base64编码,GUID,保证不重复。

PUT /music/children

我们的项目中怎么选择ID生成方式呢?
一般来说,看Elasticsearch在系统里承担的角色,如果是业务系统,本身有关系型数据完成数据的落地,Elasticsearch的价值就是填补关系型数据的全文搜索的短板,Elasticsearch的数据源头,本身在带ID的,这种情况下应该使用手动指定ID的方式,直接用数据库存储数据的ID即可,后续的搜索功能,也很容易与数据库建立对应 关系。例如订单数据,此时的ID直接使用订单ID即可,而订单ID的生成方式,无论是自增ID,雪花ID,对Elasticsearch来讲都不要紧,保证唯一性即可。

而自动ID生成的场景,比如有些系统,它没有关系型数据库,Elasticsearch可能就是它唯一的数据落地方案,这种数据结构,ID没有太多的重要性,这时让Elasticsearch自动生成一个,可以保存到Elasticsearch即可。

tips: GUID、UUID、COMB概念

  • UUID:是128位整数(16字节)的通用唯一识别码 (Universally Unique Identifier),它是由开放软件基金会(OSF)定义的一个软件建构的标准。
  • GUID:是微软对UUID这个标准的实现。UUID还有其它各种实现,不止GUID一种。
  • COMB(combine)型是数据库特有的一种设计思想,可以理解为一种改进的GUID,它通过组合GUID和系统时间,以使其在索引和检索时有更优的性能。

GUID与UUID的区别,生成的格式不同。

document写操作

  1. 强制创建
    强制创建在语法上多了_create参数,或op_type=create,如

PUT /music/children/id/_create

PUT /music/children/id?op_type=create

强制创建与全量替换的异同点:

  • 当ID不存在时,二者的效果一样。
  • 当ID存在时,全量替换做更新操作,强制创建报错,提示"version conflict, document already exists"错误。
  1. 删除document

如果对一个document执行delete操作,ES不会立即进行物理删除,而是先标记为deleted状态,当文件数据变多满足一定条件后,ES再执行物理删除,类似于JVM的垃圾清理。
这个过程叫软删除,也叫lazy delete。

  1. 全量替换&增量更新
全量替换

全量替换命令可以多次执行,如果ID不存在,执行创建document操作,如果ID存在,执行更新,语法示例:

PUT /music/children/id

全量替换的原理:当全量替换请求发送到ES上时,会将该ID原有的document执行软删除,然后再新建一个document,把request body的内容存储到新的document中,后续的GET查询只关注非deleted状态的document,这样就完成了一次全量替换操作。

增量更新前必须保证该ID是存在的,存在执行更新操作,若不存在,抛出"document_missing_exception"错误信息。

增量更新

增量更新的原理,与全量替换基本一致,也有软删除过程,只是创建新的document时,需要将原有的document数据拷贝一份,再用增量的内容进行覆盖,得到一个新的document。

增量更新比全量替换的优点

  • 查询修改写回操作,都发生在一个shard内部,网络带宽更小(有2次网络传输),大大提升了性能
  • 减少了查询和修改中的时间时隔,可以有效减少并发冲突的情况(毫秒级的更新)
  • 减轻应用程序拼接全量数据的工作量(如果json field比较多,拼接一个完整的document是很费事的)

小结

本篇主要围绕document的元数据进行了简单的讲解,希望可以加深对document的印象。

专注Java高并发、分布式架构,更多技术干货分享与心得,请关注公众号:Java架构社区
可以扫左边二维码添加好友,邀请你加入Java架构社区微信群共同探讨技术
Elasticsearch系列---全面了解Document

相关推荐