ES 5 新特性

版权声明:RML 版权所有 https://blog.csdn.net/slml08/article/details/54574756

ES 5 新增功能

性能有关

1. Lucene 6.x 的支持

最重要的特性就是 Dimensional Point Fields,多维浮点字段,ES里面相关的字段如date, numeric,ip 和 Geospatial 都将大大提升性能。

磁盘空间少一半;索引时间少一半;查询性能提升25%;IPV6也支持了。

为什么快?底层使用的是Block k-d trees,核心思想是将数字类型编码成定长的字节数组,对定长的字节数组内容进行编码排序,然后来构建二叉树,然后依次递归构建,目前底层支持8个维度和最多每个维度16个字节,基本满足大部分场景。

索引小了之后,merge的时间也相应的减少了。
相应的Java堆内存占用只原来的一半。

索引性能方面的其他优化。
ES5.0在Internal engine级别移除了用于避免同一文档并发更新的竞争锁,带来15%-20%的性能提升 #18060。

另一个和aggregation的改进也是非常大,Instant Aggregations。
Elasticsearch已经在Shard层面提供了Aggregation缓存,如果你的数据没有变化,ES能够直接返回上次的缓存结果,

但是有一个场景比较特殊,就是 date histogram,大家kibana上面的条件是不是经常设置的相对时间,如:from:now-30d to:now,now是一个变量在变,所以query条件一直在变,缓存也就是没有利用起来。
经过一年时间大量的重构,现在可以做到对查询做到灵活的重写:

首先,now关键字最终会被重写成具体的值;
其次,每个shard会根据自己的数据的范围来重写查询为 match_all或者是match_none查询,所以现在的查询能够被有效的缓存,并且只有个别数据有变化的Shard才需要重新计算,大大提升查询速度

和Scroll相关的
新增了一个:Sliced Scroll类型
数据量很大,用Scroll遍历数据那确实是接受不了,现在Scroll接口可以并发来进行数据遍历了。
每个Scroll请求,可以分成多个Slice请求,可以理解为切片,各Slice独立并行,利用Scroll重建或者遍历要快很多倍。
这里写图片描述
可以看到两个scroll请求,id分别是0和1,max是最大可支持的并行任务,可以各自独立进行数据的遍历获取。

查询优化
新增Profile API https://www.elastic.co/guide/en/elasticsearch/reference/master/search-profile.html
要调优当然需要先监控啦,elasticsearch在很多层面都提供了stats方便你来监控调优,但是还不够,其实很多情况下查询速度慢很大一部分原因是糟糕的查询引起的,玩过SQL的人都知道,数据库服务的执行计划(execution plan)非常有用,可以看到那些查询走没走索引和执行时间,用来调优,elasticsearch现在提供了Profile API来进行查询的优化,只需要在查询的时候开启profile:true就可以了,一个查询执行过程中的每个组件的性能消耗都能收集到。

各子查询耗时多少,占比多少,一目了然。
同时支持search和aggregation的profile。

深度分页
老大难的问题,因为需要全局排序(number_of_shards * (from + size)),所以需要消耗大量内存。

无限制 —–> from+size<1w —–> scroll

scroll问题:

  • 没有顺序,直接从底层segment进行遍历读取
  • 非实时,中间修改不可见

新的 Search After 机制,其实和scroll类似,也是游标的机制,它的原理是对文档按照多个字段进行排序,然后利用上一个结果的最后一个文档作为起始值,拿size个文档,一般我们建议使用_uid这个字段,它的值是唯一的id。

索引与分片管理相关
新增Shrink API
https://www.elastic.co/guide/en/elasticsearch/reference/master/indices-shrink-index.html#_shrinking_an_index

将分片数进行收缩成它的因数,如之前你是15个分片,你可以收缩成5个或者3个又或者1个,那么我们就可以想象成这样一种场景,在写入压力非常大的收集阶段,设置足够多的索引,充分利用shard的并行写能力,索引写完之后收缩成更少的shard,提高查询性能。
这里写图片描述
有人肯定会问慢不慢?非常快! Shrink的过程会借助操作系统的Hardlink进行索引文件的链接,这个操作是非常快的,毫秒级Shrink就可收缩完成,当然windows不支持hard link,需要拷贝文件,可能就会很慢了。

新增Rollover API
https://www.elastic.co/guide/en/elasticsearch/reference/master/indices-rollover-index.html#indices-rollover-index
对于日志类的数据非常有用,一般按天来对索引进行分割(数据量更大还能进一步拆分),以前是设置一个自动生成索引的模板,大家用过logstash应该就记得有这么一个模板logstash-[YYYY-MM-DD]这样的模板,现在es5.0里面提供了一个更加简单的方式:Rollover API
这里写图片描述
首先创建一个logs-0001的索引,它有一个别名是logs_write,然后我们给这个logs_write创建了一个rollover规则,即这个索引文档不超过1000个或者最多保存7天的数据,超过会自动切换别名到logs-0002,你也可以设置索引的setting、mapping等参数,剩下的es会自动帮你处理。

新增:Reindex
借助Reindex可以很方便的异步进行重建,并且支持跨集群间的数据迁移。
如按天创建的索引可以定期重建合并到以月为单位的索引里面去。
当然索引里面要启用_source。

建过程中,还能对数据就行加工:
这里写图片描述

跟Java开发者最相关的:RestClient

相比之前的TransportClient,版本依赖绑定,集群升级麻烦,不支持跨Java版本的调用等问题,新的基于HTTP协议的客户端对Elasticsearch的依赖解耦,没有jar包冲突,提供了集群节点自动发现、日志处理、节点请求失败自动进行请求轮询,充分发挥Elasticsearch的高可用能力,并且性能不相上下。 #19055。

新增Wait for refresh功能

相当于是提供了文档级别的Refresh:
https://www.elastic.co/guide/en/elasticsearch/reference/master/docs-refresh.html
之前提供了索引层面的_refresh接口,但是这个接口工作在索引层面,我们不建议频繁去调用,如果你有需要修改了某个文档,需要客户端实时可见怎么办?

在 5.0中,Index、Bulk、Delete、Update这些数据新增和修改的接口能够在单个文档层面进行refresh控制了,有两种方案可选,一种是创建一个很小的段,然后进行刷新保证可见和消耗一定的开销,另外一种是请求等待es的定期refresh之后再返回。
这里写图片描述

新增:Ingest Node

https://www.elastic.co/guide/en/elasticsearch/reference/master/ingest.html
之前如果需要对数据进行加工,都是在索引之前进行处理,比如logstash可以对日志进行结构化和转换,现在直接在es就可以处理了,目前es提供了一些常用的诸如convert、grok之类的处理器,在使用的时候,先定义一个pipeline管道,里面设置文档的加工逻辑,在建索引的时候指定pipeline名称,那么这个索引就会按照预先定义好的pipeline来处理了;
这里写图片描述
首先创建了一个名为my-pipeline-id的处理管道,然后接下来的索引操作就可以直接使用这个管道来对foo字段进行操作了,上面的例子是设置foo字段为bar值。
原始字段message被拆分成了更加结构化的对象了。

脚本方面的改变

新增Painless Scripting

Groove脚本开启之后,如果被人误用可能带来的漏洞,为什么呢,主要是这些外部的脚本引擎太过于强大,什么都能做,用不好或者设置不当就会引起安全风险,基于安全和性能方面,我们自己开发了一个新的脚本引擎,名字就叫Painless,顾名思义,简单安全,无痛使用,和Groove的沙盒机制不一样,Painless使用白名单来限制函数与字段的访问,针对es的场景来进行优化,只做es数据的操作,更加轻量级,速度要快好几倍,并且支持Java静态类型,语法保持Groove类似,还支持Java的lambda表达式。

基础架构方面的变化

新增:Task Manager

任务调度管理机制,用来做离线任务的管理,比如长时间运行的reindex和update_by_query等都是运行在TaskManager机制之上的,并且任务是可管理的,你可以随时cancel掉,并且任务状态持久化,支持故障恢复;

新增:Depreated logging

调用的接口如果已经是废弃的接口,就会记录下日志

新增: Cluster allocation explain API

不知道是什么原因,只能尝试手动路由或者重启节点,但是不一定能解决。
目前为什么不能正常分配的原因,方便你去解决。

数据结构这块,新增: half_float 类型

https://www.elastic.co/guide/en/elasticsearch/reference/master/number.html
只使用 16 位 足够满足大部分存储监控数值类型的场景,支持范围:2负24次方 到 65504,但是只占用float一半的存储空间。

Aggregation新增: Matrix Stats Aggregation #18300

金融领域非常有用的,可计算多个向量元素协方差矩阵、相关系数矩阵等等

为索引写操作添加顺序号 #10708

es是在primary上写完然后同步写副本,这些请求都是并发的,虽然可以通过version来控制冲突,但是没法保证其他副本的操作顺序,通过写的时候产生顺序号,并且在本地也写入checkpoint来记录操作点,

在副本恢复的时候也可以知道当前副本的数据位置,而只需要从指定的数据开始恢复就行了,而不是像以前的粗暴的做完整的文件同步,另外这些顺序号也是持久化的,重启后也可以快速恢复副本信息,想想以前的大量无用拷贝吧和来回倒腾数据吧。

其他方面的改进

mapping

引入新的字段类型Text/Keyword 来替换 String
keyword类型的数据只能完全匹配,适合那些不需要分词的数据,对过滤、聚合非常友好,
text当然就是全文检索需要分词的字段类型了。
另外string类型暂时还在的,6.0会移除。

Index Settings 的改进

配置验证更加严格和保证原子性,如果其中一项失败,那个整个都会更新请求都会失败,不会一半成功一半失败。下面主要说两点:

设置可以重设会默认值,只需要设置为 null即可
获取设置接口新增参数?include_defaults,可以直接返回所有设置和默认值

集群处理的改进: Deleted Index Tombstones(墓碑)

在以前的es版本中,如果你的旧节点包含了部分索引数据,但是这个索引可能后面都已经删掉了,你启动这个节点之后,会把索引重新加到集群中,是不是觉得有点阴魂不散,现在es5.0会在集群状态信息里面保留500个删除的索引信息,所以如果发现这个索引是已经删除过的就会自动清理,不会再重复加进来了。

文档对象的改进: 字段名重新支持英文句号,再2.0的时候移除过dot在字段名中的支持,现在问题解决了,又重新支持了。

es会认为下面两个文档的内容一样:
这里写图片描述

其他改进

Cluster state的修改现在会和所有节点进行ack确认。
Shard的一个副本如果失败了,Primary标记失败的时候会和Master节点确认完毕再返回。
使用UUID来作为索引的物理的路径名,有很多好处,避免命名的冲突。
_timestamp 和 _ttl已经移除,需要在Ingest或者程序端处理。
ES可直接用HDFS来进行备份还原(Snapshot/Restore )了 #15191。
Delete-by-query和Update-by-query重新回到core,以前是插件,现在可以直接使用了,也是构建在Reindex机制之上。
HTTP请求默认支持压缩,当然http调用端需要在header信息里面传对应的支持信息。
创建索引不会再让集群变红了,不会因为这个卡死集群了。

默认使用BM25评分算法,效果更佳,之前是TF/IDF。
快照Snapshots添加UUID解决冲突 #18156。
限制索引请求大小,避免大量并发请求压垮ES #16011。
限制单个请求的shards数量,默认1000个 #17396。

移除 site plugins,就是说head、bigdesk都不能直接装es里面了,不过可以部署独立站点(反正都是静态文件)或开发kibana插件 #16038。

允许现有parent类型新增child类型 #17956。

支持分号(;)来分割url参数,与符号(&)一样 #18175。

Q:ik插件有没有计划支持同义词,专有名词热更新?对于词库更新比较频繁的应用场景,只能采取全部重新建立索引的方式吗?
A:同义词有单独的filter,可以和ik结合一起使用的,关于热更新这个确实是需要重建,词库变化之后,分词产生的term不一样了,不重建的话,倒排很可能匹配不上,查询会失败。

Q:老师,你好,我有个问题想咨询一下,我们原来的商品基本数据,商品评价数据,收藏量这些都在mysql里,但我们现在想上es,我们想把商品的基本数据放es,收藏、评价这些实时数据,还是放mysql,但做排序功能的时候,会参考一个商品的收藏量,评价量,这时候在还涉及数据分页的情况下,怎么结合es和mysql的数据进行排序呢?
A:这个问题得具体看业务场景,如果更新频繁,但是还在es承受能力范围和业务响应指标内,可以直接放es里面,在es里面做排序,如果太大,建议放外部存储,外部存储和es的结合方式又有很多种,收藏评价是否真的需要那么实时?另外es的评分机制是可以扩展的,在评分阶段使用自定义插件读取外部数据源,进行混合打分也是可行的。

Q:请问用于计算unique count的算法有变化吗?
A:有的,elasticsearch里面叫cardinality。这里有篇文章:https://www.elastic.co/blog/count-elasticsearch

Q:请问es中的如何做到按某个字段去重?具体问题是这样的,我们有一个文章索引,其中有2亿数据量,每次搜索的结果总是存在大量重复的title,我们希望在查询时能根据title进行去重。也就是Field Collapsing特性,官方有一个通过terms aggregation进行去重的方案,但效果不是很理想,仍然会有很多重复,我们希望哪怕是按title严格相等来去重也可以接受。 另外我们有一个通过simhash来去重的思路,就是计算title的simhash,一并存入索引,在搜索阶段通过simhash计算相似性,但这需要全量重新计算,数据量太大。所以还是希望能在不动现有索引的情况下,通过某种技巧,实现这个功能。
A:直接去重,这个目前没有比较好的方案,不过很多变通的做法,首先你的场景需要确认,title重复是不是不允许的,如果是,那么建索引的时候就可以hash掉作为主键,这样就不会有重复的了,如果你觉得原始数据也要,那么索引阶段产生一个独立的去除title的索引,来做join,当然还是要看你业务的场景具体研究。

阅读更多

没有更多推荐了,返回首页