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

比快更快，有傳說中的那么牛逼嗎？盤他！

通過本文，你能了解到：

• Elasticsearch&Kibana 7.部署體驗

• Elasticsearch7 革命性更新

• Elasticsearch 7升級注意事項

• Elasticsearch?版本更新太快了，學不動了，腫么辦？

1、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，而不是必須在很多地方打開黑暗模式，它將適用于所有應用程序。

2、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

3、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規范走，這樣升級會相對比較省事。

4、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

總結

以上是生活随笔為你收集整理的Elasticsearch 7.0 已经发布，盘他！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。