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手动指定与自动生成两种方式：

手动指定

PUT命令行指定ID时，即手动方式

PUT /music/children/id

自动生成

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写操作

强制创建

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

PUT /music/children/id/_create
或
PUT /music/children/id?op_type=create

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

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

删除document

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

全量替换&增量更新

全量替换

全量替换命令可以多次执行，如果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架构社区

概要