Elasticsearch 7.0 正式发布，盘他！

Elastic{ON}北京分享了Elasticsearch7.0在Speed,Scale,Relevance等方面的不少新特性。

比快更快，有传说中的那么牛逼吗？盘他！

经过本文，你能了解到：

Elasticsearch&Kibana 7.部署体验

Elasticsearch7 革命性更新

Elasticsearch 7升级注意事项

Elasticsearch 版本更新太快了，学不动了，肿么办？

一、Elasticsearch&Kibana 7.部署体验
1.1 Elasticsearch 7.0 默认自带 JDK
不用再为安装什么版本的 JDK和环境冲突而苦恼了，下载安装便可使用。

对比可知，包大了200MB+，正是JDK的大小。

在这里插入图片描述
1.2 默认节点名称为主机名。

不过仍然能够在elasticsearch.yml中显式配置。

实际业务场景中，以主机名区分不一样节点比随机起名字更便于甄别，不易混淆。

1.3 默认分片数改成1，再也不是5。

1.4 Elasticsearch 7.0 没有 Type 了，包括 API 层面的。
以下所示，确切的说，正确的使用方法，使用默认的_doc做为type就能够了。
type会在8.X版本完全移除。

1.5 hits.total返回对象，而非仅结果值
如今，与搜索请求匹配的总命中数将做为具备值和关系的对象返回。
value表示匹配的匹配数，

关系表示值是准确的（eq）仍是非准确的（gte）。

1.6 Kibana 支持全局开启“黑暗”模式
用户能够选择打开主题：Kibana->高级设置->dark Mode，而不是必须在不少地方打开黑暗模式，它将适用于全部应用程序。

二、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增长了几个零并带来了纳秒精度，这提升了高频数据采集用户存储和排序所需数据的精度。

显然，7.0的特性远不止这些，更多新版本特性推荐阅读：

http://t.cn/EXyStrW

http://t.cn/EXyStrO

三、Elasticsearch 7升级注意事项
3.0 升级前必知必会
查看新版本的重大更改特性，并对7.0.0的代码和配置进行必要的更改。

若是您使用自定义插件，请确保兼容版本可用。

在升级生产集群以前，在开发环境中测试升级。

备份您的数据！ 您必须拥有数据快照才能回滚到早期版本。

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

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

3.2 版本升级路线
小版本之间升级：举例:5.4.1升级到5.6

平滑升级——从5.6版本到6.7版本

平滑升级——从6.7版本到7.0.0版本

3.3 借助Reindex升级索引数据
Elasticsearch能够读取在先前主要版本中建立的索引。若是您在5.x或以前建立了索引，则必须在升级到7.0.0以前从新索引或删除它们。

若是存在不兼容的索引，Elasticsearch节点将没法启动。

3.4 ELK Stack要一块儿升级
升级到新版本的Elasticsearch时，须要升级Elastic Stack中的每一个产品。

3.5 6.6或更早版本集群，须要先关闭
要从6.6或更早版本直接升级到7.0.0，必须关闭群集，安装7.0.0并从新启动。

3.6 切记，7.0+版本无type的索引结构。
这点，若是考虑将来更新版本，在6.X或者更早版本的项目中，就严格按照7.x规范走，这样升级会相对比较省事。

四、Elasticsearch 版本更新太快了，学不动了，肿么办？

一方面，咱们感叹ES的更新速度，的确从2016年的2.X到2019年的7.0，版本更新速度超乎想象。

另外一方面，实际业务开发中，还在使用1.X,2.X,5.X，甚至尚未用过6.X的朋友很是多，小伙伴不由有了“学不动了”的感慨。

4.1 新版本的变
变是永恒的，尤为是基于开源软件加上上市公司的推进。

实际上，高版本较低版本，主要在性能上的提高和部分新功能点的实现。

新版本更高效。
好比：6.6+提出的ilm索引生命周期管理，你若是关注Elastic Meetup的话，印象ebay和阿里还有其余公司本身就实现过相似功能。

原有版本有相似的功能，只不过是很是、很是麻烦、繁琐，因此，才有了ilm的诞生。

新版本迎合了市场的需求。
好比：7.0的黑暗模式，实际在grafana或相似竞品BI中都有相似的功能，猜想Kibana升级一方面是用户需求，另外一方面也是竞品分析的结果。

新版本性能极大提高。
好比：7.0的terms融合新算法，有37倍的提高。

4.2 新版本的不变
《暗时间》做者刘未鹏说过“底层的技术永远不过期”。

没必要说倒排索引机制不会变，也没必要说Lucene的改动也相对较小。单是：ES的基础功能全文检索、多种聚合等几乎不会有太大的变更。

4.3 还存在学不动吗？
夯实打牢基础基本功，理解ELK更新的变与不变。80-90%+的时间关注基础，10%左右的时间关注增量的变化便可。

以不变应万变，方为生存之道！

参考：

http://t.cn/EXySp7K

http://t.cn/EMg3uRw