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手动指定与自动生成两种方式:
- 手动指定
PUT命令行指定ID时,即手动方式
PUT /music/children/id
- 自动生成
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写操作
- 强制创建
强制创建在语法上多了_create参数,或op_type=create,如
PUT /music/children/id/_create
或PUT /music/children/id?op_type=create
强制创建与全量替换的异同点:
- 当ID不存在时,二者的效果一样。
- 当ID存在时,全量替换做更新操作,强制创建报错,提示"version conflict, document already exists"错误。
- 删除document
如果对一个document执行delete操作,ES不会立即进行物理删除,而是先标记为deleted状态,当文件数据变多满足一定条件后,ES再执行物理删除,类似于JVM的垃圾清理。
这个过程叫软删除,也叫lazy delete。
- 全量替换&增量更新
全量替换
全量替换命令可以多次执行,如果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的印象。
专注Java高并发、分布式架构,更多技术干货分享与心得,请关注公众号:Java架构社区
可以扫左边二维码添加好友,邀请你加入Java架构社区微信群共同探讨技术
相关推荐
另外一部分,则需要先做聚类、分类处理,将聚合出的分类结果存入ES集群的聚类索引中。数据处理层的聚合结果存入ES中的指定索引,同时将每个聚合主题相关的数据存入每个document下面的某个field下。