es7.0新特性

一、Elasticsearch&Kibana 7.部署体验

1.1、Elasticsearch 7.0 默认自带 JDK

不用再为安装什么版本的 JDK和环境冲突而苦恼了，下载安装即可使用。 
对比可知，包大了200MB+，正是JDK的大小。

1.2、默认节点名称为主机名

不过仍然可以在elasticsearch.yml中显式配置。
实际业务场景中，以主机名区分不同节点比随机起名字更便于甄别，不易混淆。

1.3、默认主分片数改为1，不再是5。

"number_of_shards" :   5,    // 7.0之后改为1
"number_of_replicas" : 1

1.4、Elasticsearch 7.0 没有 Type 了，包括 API 层面的。

确切的说，正确的使用方法，使用默认的_doc作为type就可以了。
type会在8.X版本彻底移除

1.5、hits.total返回对象，而非仅结果值（注意：可能会影响到应用程序）

"hits":{
  "total":{
    "value":100,            // value表示匹配的匹配数
    "relation":"eq"         // relation表示值是准确的（eq）还是非准确的（gte）
  }
}

1.6、Kibana 支持全局开启“黑暗”模式

二、Elasticsearch7 革命性更新

2.1、查询相关性速度优化

Weak-AND算法在Term Query查询场景有3700%的性能提升。
如下所示，除了Term检索，Fuzzy，Phrase, Bool And .Bool OR都有大幅的性能提升！

啥是weak-and算法？核心原理：取TOP N结果集，估算命中记录数。

简单来说，一般我们在计算文本相关性的时候，会通过倒排索引的方式进行查询，
通过倒排索引已经要比全量遍历节约大量时间，但是有时候仍然很慢。
原因是很多时候我们其实只是想要top n个结果，一些结果明显较差的也进行了复杂的相关性计算，
而weak-and算法通过计算每个词的贡献上限来估计文档的相关性上限，从而建立一个阈值对倒排中的结果进行减枝，从而得到提速的效果。

2.2、间隔查询(Intervals queries)

某些搜索用例（例如，法律和专利搜索）引入了查找单词或短语彼此相距一定距离的记录的需要。 

Elasticsearch 7.0中的间隔查询引入了一种构建此类查询的全新方式，与之前的方法（跨度查询span queries）相比，使用和定义更加简单。 

与跨度查询相比，间隔查询对边缘情况的适应性更强。

2.3、引入新的集群协调子系统

移除 minimum_master_nodes 参数，让 Elasticsearch 自己选择可以形成仲裁的节点。
典型的主节点选举现在只需要很短的时间就可以完成。 
集群的伸缩变得更安全、更容易，并且可能造成丢失数据的系统配置选项更少了。
节点更清楚地记录它们的状态，有助于诊断为什么它们不能加入集群或为什么无法选举出主节点。

2.4、升级 Elasticsearch 7,0 ，不再内存溢出

新的 Circuit Breaker 在JVM 堆栈层面监测内存使用，Elasticsearch 比之前更加健壮。

设置indices.breaker.fielddata.limit的默认值已从JVM堆大小的60％降低到40％。

2.5、时间戳纳秒级支持，提升数据精度

利用纳秒精度支持加强时间序列用例

到目前为止，Elasticsearch仅以毫秒精度存储时间戳。
7.0增加了几个零并带来了纳秒精度，这提高了高频数据采集用户存储和排序所需数据的精度。

三、Elasticsearch 7升级注意事项

3.1、升级前必知必会

1、查看新版本的重大更改特性，并对7.0.0的代码和配置进行必要的更改。
2、如果您使用自定义插件，请确保兼容版本可用。
3、在升级生产集群之前，在开发环境中测试升级。
4、备份您的数据！ 您必须拥有数据快照才能回滚到早期版本。

3.2、升级API

Rolling upgrade ——滚动升级允许Elasticsearch集群一次升级一个节点，升级不会中断服务。

不支持在升级期间在同一群集中运行多个版本的Elasticsearch，因为无法将已升级的节点复制到运行旧版本的节点。