背景：目前国内有大量的公司都在使用 Elasticsearch，包括阿里、京东、滴滴、今日头条、小米、vivo等诸多知名公司。除了搜索功能之外，Elasticsearch还结合Kibana、Logstash、Elastic Stack还被广泛运用在大数据近实时分析领域，包括日志分析、指标监控等多个领域。

本节内容：Elasticsearch文档元数据。

我们知道，一个文档中，不仅仅包含它的业务数据 ，也包含有关文档的元数据信息。 一个文档必须有以下3个元数据。

_index：文档存放的位置，相当于关系型数据库Mysql的db_name。
_type：文档表示的对象类别，相当于关系型数据库Mysql的表，不过在ES 7.x之后统一为_doc了。
_id：文档唯一标识，类似于关系型数据库Mysql的主键。

1、文档索引 _index

一个索引应该是因共同的特性被分组到一起的文档集合。 例如，你可能存储所有的学生在索引 student 中，而存储所有的学生成绩到索引 student_score 中。 虽然也允许存储不相关的数据到一个索引中，但这通常看作是一个反模式的做法。

实际上，在 Elasticsearch 中，我们的数据是被存储和索引在分片中，而一个索引仅仅是逻辑上的命名空间， 这个命名空间由一个或者多个分片组合在一起。 然而，这是一个内部细节，我们的应用程序根本不应该关心分片，对于应用程序而言，只需知道文档位于一个索引内。 Elasticsearch 会处理所有的细节。

Elasticsearch 创建索引名，这个名字必须小写，不能以下划线开头，不能包含逗号。

仅限小写字母
不能包含、/、 *、?、"、<、>、|、#以及空格符等特殊符号
从7.0版本开始不再包含冒号
不能以-、_或+开头
不能超过255个字节

例如，创建一个学生成绩索引。

POST http://localhost:9200/student_score

student_score 为索引名

{
    "settings": {
        "index": {
            "number_of_shards": 5,
            "number_of_replicas": 3
        }
    }
}

2、文档类型 _type

数据可能在索引中只是松散的组合在一起，但是通常明确定义一些数据中的子分区是很有用的。 例如，所有的学生都放在一个索引中，但是你有许多不同年级的学生，比如 "grade one" 、 和 "grade two"。

这些文档共享一种相同的（或非常相似）的模式：他们有共同的姓名、成绩和课程。他们只是正好属于“不同年级”下的一些子类。

Elasticsearch 公开了一个称为 types类型的特性，它允许您在索引中对数据进行逻辑分区。不同 types 的文档可能有不同的字段，但最好能够非常相似。

_type规范：

一个 _type 命名可以是大写或者小写，但是不能以下划线或者句号开头，不应该包含逗号， 并且长度限制为256个字符。

{
    "settings": {
        "index": {
            "number_of_shards": 5,
            "number_of_replicas": 3
        }
    },
    "mappings": {
        "score": { // _type, 在7.x之后，默认为_doc
            "_source": {
                "enabled": false
            },
            "properties": {
                "name": {
                    "type": "string"
                },
                "score": {
                    "type": "integer"
                }
            }
        }
    }
}

3、文档主键 _id

ID 是一个字符串，当它和 _index 以及 _type 组合就可以唯一确定 Elasticsearch 中的一个文档。 当你创建一个新的文档，要么提供自己的 _id ，要么让 Elasticsearch 帮你生成。

自定义格式：

http://localhost:9203/index/_doc/id #id可以自己指定

例如，http://localhost:9203/student/_doc/100

Elasticsearch 自动生成：

4、其他元数据

4.1 版本 _version

主要为了解决数据冲突问题。

ElasticSearch采用乐观并发控制。Elasticsearch是分布式的，当文档被创建、更新或删除，文档的新版本会被复制到集群的其它节点。Elasticsearch即是同步的又是异步的，意思是这些复制请求都是平行发送的，并无序(out of sequence)的到达目的地。这就需要一种方法确保老版本的文档永远不会覆盖新的版本。

版本规则：

每个文档都有一个_version编号，这个编号在文档被改变时加1，Elasticsearch使用这个_version保证所有修改都被正确排序。当一个旧版本出现在新版本之后，它会被简单的忽略。

{
    "_index": "student",
    "_type": "_doc",
    "_id": "100",
    "_version": 1, //版本号
    "_seq_no": 20,
    "_primary_term": 1,
    "found": true,
    "_source": {
        "name": "xiaoli",
        "age": 18,
        "love": "I like swimming.",
        "createTime": "2022-05-04 20:00:00"
    }
}

4.2 顺序号 _seq_no

_seq_no是严格递增的顺序号，每个文档一个，Shard级别严格递增，保证后写入的Doc的_seq_no大于先写入的Doc的_seq_no。任何类型的写操作，包括index、create、update和Delete，都会生成一个_seq_no。

{
    "_index": "student",
    "_type": "_doc",
    "_id": "100",
    "_version": 1, 
    "_seq_no": 20, //顺序号
    "_primary_term": 1,
    "found": true,
    "_source": {
        "name": "xiaoli",
        "age": 18,
        "love": "I like swimming.",
        "createTime": "2022-05-04 20:00:00"
    }
}

4.3 Primary编号 _primary_term

_primary_term主要是用来恢复数据时处理当多个文档的_seq_no一样时的冲突，比如当一个shard宕机了，raplica需要用到最新的数据，就会根据_primary_term和_seq_no这两个值来拿到最新的document

_primary_term：_primary_term也和_seq_no一样是一个整数，每当Primary Shard发生重新分配时，比如重启，Primary选举等，_primary_term会递增1

4.4 执行结果状态 found

found表示执行最中结果成功与否。

4.5 数据源 _source

Elasticsearch中有一个重要的概念是source，存储原始文档，也可以通过过滤设置只存储特定Field。