Elastic Search经常使用元数据简介

在ES中，除了定义的index，type，和管理的document外，还有若干的元数据。这些元数据用于记录ES中须要使用的核心数据。在ES中，元数据一般使用下划线’_’开头。

1 查看数据
GET /index_name/type_name/id
如：
GET /test_index/my_type/1
结果：

{
    "_index": "test_index",
    "_type": "my_type",
    "_id": "1",
    "_version": 1,
    "found": true,
    "_source": {
        "name": "test_doc_01",
        "remark": "first test elastic search",
        "order_no": 1
    }
}

　　

2 _index
表明document存放在哪一个index中，_index就是索引的名字。生产环境中，相似的Document存放在一个index中，非相似的Document存放在不一样的index中。一个index中包含若干类似的Document。index名称必须是小写的，且不能如下划线'_'，'-'，'+'开头。

3 _type
表明document属于index中的哪一个type（类别），就是type的名字。ES6.x版本中，一个index只能定义一个type。结构相似的document保存在一个index中。Type命名要求：字符大小写无要求，不能下划线开头，不能包含逗号。（ES低版本，5.x或更低版本。通常一个索引会划分若干type，逻辑上对index中的document进行细致的划分。在命名上，能够全大写或者全小写，不能下划线开头，不能包含逗号。）

4 _id
表明document的惟一标识。使用index、type和id能够定位惟一的一个document。id能够在新增document时手工指定，也能够由es自动建立。
4.1 手动指定id
语法：
PUT /index_name/type_name/id_value
{
    "field_name" : "field_value"
}

使用这种方式，须要考虑是否知足手动指定id的条件。若是数据是从其余数据源中读取并新增到ES中的时候，使用手动指定id。如：数据是从Database中读取并新增到ES中的，那么使用Database中的PK做为ES中的id比较合适。建议，不要把不一样表的数据新增到同一个index中，可能有id冲突。
4.2 自动生成id
语法：
POST /index_name/type_name
{
    "field_name" : "field_value"
}
自动生成的ID特色：长度为20的字符串；URL安全（通过base64编码的）；GUID生成策略，支持分布式高并发（在分布式系统中，并发生成ID也不会有重复可能，参考https://baike.baidu.com/item/GUID/3352285?fr=aladdin）。适合用于手工录入的数据。数据没有一个数据源，且未通过任何的管理和存储。这种数据，是没有惟一标识，若是使用手工指定id的方式，容易出现id冲突，致使数据丢失。相对少见。

5 _source元数据
就是查询的document中的field值。也就是document的json字符串。此元数据能够定义显示结果（field）。语法是：
GET /index_name/type_name/id_value?_source=field_name1,field_name2

6 _version元数据
表明的是document的版本。在ES中，为document定义了版本信息，document数据每次变化，表明一次版本的变动。版本变动能够避免数据错误问题（并发问题，乐观锁），同时提供ES的搜索效率。
第一次建立Document时，_version版本号为1，默认状况下，后续每次对Document执行修改或删除操做都会对_version数据自增1。
删除Document也会_version自增1。
当使用PUT命令再次增长同id的Document，_version会继续以前的版本继续自增。