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