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的印象。