0


第16篇:Elasticsearch文档元数据信息

背景:目前国内有大量的公司都在使用 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。


本文转载自: https://blog.csdn.net/wangyongfei5000/article/details/125116089
版权归原作者 老王随聊 所有, 如有侵权,请联系我们删除。

“第16篇:Elasticsearch文档元数据信息”的评论:

还没有评论