先展示一个document数据结构GET /product/_doc/1 { _index : product, _type : _doc, _id : 1, _version : 1, _seq_no : 0, _primary_term : 1, found : true, _source : { name : gaolujie yagao, desc : gaoxiao meibai, price : 30, producer : gaolujie producer, tags : [ meibai, fangzhu ] } }下面我们就来开始分析了1、document的核心元数据1_index元数据1、_index代表一个document存放在哪个index中2、对于document类似的数据都是放在一个索引里面的非类似的数据放在不同的索引中。例如product_index是包含了所有商品的index,sales_index是包含了所有商品的销售数据的indexinventory_index是包含了所有库存相关的数据。如果想把所有的这些数据都放在一个索引中,比如创建一个company_index是不合适的。3、对于每个索引一般都是包含了很多类似的document类似是什么意思其实指的就是说这些document的fields很大一部分是相同的如果说你放了三个document,但是每个document的fields都完全不一样这就不是类似了就不太适合放到一个index里面去了。4、对于语法要求每个索引名称必须是小写的不能用下划线开头不能包含逗号。2_type元数据1、_type代表这个document属于index中的哪个类别type2、一个索引只能有一个type在后面的ES高版本中可能会废弃掉3、对于type的语法它可以是大写或是小写但是同时不能用下划线开头不能包含逗号3_id元数据1、_id代表document的唯一标识与index和type一起可以唯一标识和定位一个document2、我们可以手动指定document的id也可以不指定那ES就会自动为我们创建一个id下面附上中华石衫老师的手工图说明一下为什么不同类型的数据不用一个索引存放归纳一下就是如果把多个不同类型的数据放在一个索引中存储当用户查询某一类的数据的时候比如商品数据大量的请求过来发现此时后台数据分析系统对这个索引下的另一类数据在做聚合分析比如销售数据此时这些shard正在执行非常耗时耗费资源的大型的聚合分析操作。就会导致document get请求大量的性能不好甚至超时。让用户感觉上来说网速好慢影响用户体验。2、document id的生成1手动指定document id1、手动指定document id时需要看下是否满足前提条件一般来说是从某些其他的系统中导入一些数据到es时会采取这种方式就是使用系统中已有数据的唯一标识作为es中的document id。举个例子假如我们现在在开发一个电商网站做搜索功能或者是OA系统做员工的检索功能。这个时候数据首先会在网站系统或者IT系统内部的数据库中会先有一份此时肯定就会有一个数据库的primary id(自增长UUID或者是业务编号)如果将数据导入到ES中此时就比较适合采用数据在数据库中的已有primary key。2、格式PUT /{index}/{type}/{id}2自动生成document id在什么情况下使用自动的document id。对于日志的搜集使用自动的document id是比较适合的。还有就是比如我们是在做一个系统这个系统主要的数据存储就是es一种也就是说数据产生出来以后可能就没有id直接就放ES存储那么这个时候可能就不太适合说手动指定document id的形式了。格式POST /{index}/{type}注自动生成的id长度为20个字符URL安全base64编码GUID,分布式系统并行生成时不可能会发生冲突3、_source元数据以及定制返回结果1_source元数据先用一个例子引出一个document的_source以及它的结构GET /product/_doc/1 { _index : product, _type : _doc, _id : 1, _version : 1, _seq_no : 0, _primary_term : 1, found : true, _source : { name : gaolujie yagao, desc : gaoxiao meibai, price : 30, producer : gaolujie producer, tags : [ meibai, fangzhu ] } }可以看出_source元数据就是说我们在创建一个document的时候使用的那个放在request body请求体中的json串。2定制返回结果指定_source参数返回哪些field即可GET /product/_doc/1?_sourcename,desc,tags { _index : product, _type : _doc, _id : 1, _version : 1, _seq_no : 0, _primary_term : 1, found : true, _source : { name : gaolujie yagao, desc : gaoxiao meibai, tags : [ meibai, fangzhu ] } }4、document的全量替换、强制创建以及lazy delete机制1document的全量替换1、全量替换的语法和创建文档是一样的如果document id不存在那么就是创建如果document id已经存在那么就是全量替换操作替换document的json串内容2、document是不可变的如果要修改document的内容第一种方式就是全量替换直接对document重新建立索引替换里面所有的内容3、ES会将老的document标记为deleted然后新增我们给定的一个document当我们创建越来越多的document的时候es会在适当的时机在后台自动删除标记为deleted的document2document强制创建创建文档和全量替换的语法是一样的但是有时我们想新建文档不想替换文档格式PUT /{index}/{type}/{id}?op_typecreate3document的删除格式DELETE /{index}/{type}/{id}注意删除并不是物理删除只是会将文档标记为deleted当数据越来越多的时候会在后台自动删除
elasticsearch学习笔记(十一)——document的核心元数据、操作以及原理
发布时间:2026/7/5 15:30:40
先展示一个document数据结构GET /product/_doc/1 { _index : product, _type : _doc, _id : 1, _version : 1, _seq_no : 0, _primary_term : 1, found : true, _source : { name : gaolujie yagao, desc : gaoxiao meibai, price : 30, producer : gaolujie producer, tags : [ meibai, fangzhu ] } }下面我们就来开始分析了1、document的核心元数据1_index元数据1、_index代表一个document存放在哪个index中2、对于document类似的数据都是放在一个索引里面的非类似的数据放在不同的索引中。例如product_index是包含了所有商品的index,sales_index是包含了所有商品的销售数据的indexinventory_index是包含了所有库存相关的数据。如果想把所有的这些数据都放在一个索引中,比如创建一个company_index是不合适的。3、对于每个索引一般都是包含了很多类似的document类似是什么意思其实指的就是说这些document的fields很大一部分是相同的如果说你放了三个document,但是每个document的fields都完全不一样这就不是类似了就不太适合放到一个index里面去了。4、对于语法要求每个索引名称必须是小写的不能用下划线开头不能包含逗号。2_type元数据1、_type代表这个document属于index中的哪个类别type2、一个索引只能有一个type在后面的ES高版本中可能会废弃掉3、对于type的语法它可以是大写或是小写但是同时不能用下划线开头不能包含逗号3_id元数据1、_id代表document的唯一标识与index和type一起可以唯一标识和定位一个document2、我们可以手动指定document的id也可以不指定那ES就会自动为我们创建一个id下面附上中华石衫老师的手工图说明一下为什么不同类型的数据不用一个索引存放归纳一下就是如果把多个不同类型的数据放在一个索引中存储当用户查询某一类的数据的时候比如商品数据大量的请求过来发现此时后台数据分析系统对这个索引下的另一类数据在做聚合分析比如销售数据此时这些shard正在执行非常耗时耗费资源的大型的聚合分析操作。就会导致document get请求大量的性能不好甚至超时。让用户感觉上来说网速好慢影响用户体验。2、document id的生成1手动指定document id1、手动指定document id时需要看下是否满足前提条件一般来说是从某些其他的系统中导入一些数据到es时会采取这种方式就是使用系统中已有数据的唯一标识作为es中的document id。举个例子假如我们现在在开发一个电商网站做搜索功能或者是OA系统做员工的检索功能。这个时候数据首先会在网站系统或者IT系统内部的数据库中会先有一份此时肯定就会有一个数据库的primary id(自增长UUID或者是业务编号)如果将数据导入到ES中此时就比较适合采用数据在数据库中的已有primary key。2、格式PUT /{index}/{type}/{id}2自动生成document id在什么情况下使用自动的document id。对于日志的搜集使用自动的document id是比较适合的。还有就是比如我们是在做一个系统这个系统主要的数据存储就是es一种也就是说数据产生出来以后可能就没有id直接就放ES存储那么这个时候可能就不太适合说手动指定document id的形式了。格式POST /{index}/{type}注自动生成的id长度为20个字符URL安全base64编码GUID,分布式系统并行生成时不可能会发生冲突3、_source元数据以及定制返回结果1_source元数据先用一个例子引出一个document的_source以及它的结构GET /product/_doc/1 { _index : product, _type : _doc, _id : 1, _version : 1, _seq_no : 0, _primary_term : 1, found : true, _source : { name : gaolujie yagao, desc : gaoxiao meibai, price : 30, producer : gaolujie producer, tags : [ meibai, fangzhu ] } }可以看出_source元数据就是说我们在创建一个document的时候使用的那个放在request body请求体中的json串。2定制返回结果指定_source参数返回哪些field即可GET /product/_doc/1?_sourcename,desc,tags { _index : product, _type : _doc, _id : 1, _version : 1, _seq_no : 0, _primary_term : 1, found : true, _source : { name : gaolujie yagao, desc : gaoxiao meibai, tags : [ meibai, fangzhu ] } }4、document的全量替换、强制创建以及lazy delete机制1document的全量替换1、全量替换的语法和创建文档是一样的如果document id不存在那么就是创建如果document id已经存在那么就是全量替换操作替换document的json串内容2、document是不可变的如果要修改document的内容第一种方式就是全量替换直接对document重新建立索引替换里面所有的内容3、ES会将老的document标记为deleted然后新增我们给定的一个document当我们创建越来越多的document的时候es会在适当的时机在后台自动删除标记为deleted的document2document强制创建创建文档和全量替换的语法是一样的但是有时我们想新建文档不想替换文档格式PUT /{index}/{type}/{id}?op_typecreate3document的删除格式DELETE /{index}/{type}/{id}注意删除并不是物理删除只是会将文档标记为deleted当数据越来越多的时候会在后台自动删除