1.Elasticsearch&Kibana 7.哪些需要修改？
2.Elasticsearch7 有哪些新特性？
3.Elasticsearch 7升級有哪些注意事項？
Elastic{ON}北京分享了Elasticsearch7.0在Speed,Scale,Relevance等方面的很多新特性。
1、Elasticsearch&Kibana 7.部署體驗
1.1 Elasticsearch 7.0 默認自帶 JDK
不用再為安裝什么版本的 JDK和環境沖突而苦惱了，下載安裝即可使用。
對比可知，包大了200MB+，正是JDK的大小。
<ignore_js_op>
</ignore_js_op>
1.2 默認節點名稱為主機名。
<ignore_js_op>
</ignore_js_op>
不過仍然可以在elasticsearch.yml中顯式配置。
實際業務場景中，以主機名區分不同節點比隨機起名字更便於甄別，不易混淆。
1.3 默認分片數改為1，不再是5。
<ignore_js_op>
</ignore_js_op>
1.4 Elasticsearch 7.0 沒有 Type 了，包括 API 層面的。
如下所示，確切的說，正確的使用方法，使用默認的_doc作為type就可以了。
type會在8.X版本徹底移除。
<ignore_js_op>
</ignore_js_op>
1.5 hits.total返回對象，而非僅結果值
現在，與搜索請求匹配的總命中數將作為具有值和關系的對象返回。
value表示匹配的匹配數，
關系表示值是准確的（eq）還是非准確的（gte）。
<ignore_js_op>
</ignore_js_op>
1.6 Kibana 支持全局開啟“黑暗”模式
用戶可以選擇打開主題：Kibana->高級設置->dark Mode，而不是必須在很多地方打開黑暗模式，它將適用於所有應用程序。
<ignore_js_op>
</ignore_js_op>
<ignore_js_op>
</ignore_js_op>
2、Elasticsearch7 革命性更新
2.1 查詢相關性速度優化
Weak-AND算法在Term Query查詢場景有3700%的性能提升。
如下所示，除了Term檢索，Fuzzy，Phrase, Bool And .Bool OR都有大幅的性能提升！
<ignore_js_op>
</ignore_js_op>
啥是weak-and算法？
核心原理：取TOP N結果集，估算命中記錄數。
簡單來說，一般我們在計算文本相關性的時候，會通過倒排索引的方式進行查詢，通過倒排索引已經要比全量遍歷節約大量時間，但是有時候仍然很慢。
原因是很多時候我們其實只是想要top n個結果，一些結果明顯較差的也進行了復雜的相關性計算，
而weak-and算法通過計算每個詞的貢獻上限來估計文檔的相關性上限，從而建立一個閾值對倒排中的結果進行減枝，從而得到提速的效果。
2.2 間隔查詢(Intervals queries)
某些搜索用例（例如，法律和專利搜索）引入了查找單詞或短語彼此相距一定距離的記錄的需要。
Elasticsearch 7.0中的間隔查詢引入了一種構建此類查詢的全新方式，與之前的方法（跨度查詢span queries）相比，使用和定義更加簡單。
與跨度查詢相比，間隔查詢對邊緣情況的適應性更強。
2.3 引入新的集群協調子系統
移除 minimum_master_nodes 參數，讓 Elasticsearch 自己選擇可以形成仲裁的節點。
典型的主節點選舉現在只需要很短的時間就可以完成。
集群的伸縮變得更安全、更容易，並且可能造成丟失數據的系統配置選項更少了。
節點更清楚地記錄它們的狀態，有助於診斷為什么它們不能加入集群或為什么無法選舉出主節點。
新的 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. 新版本的變
4.1實際上，高版本較低版本，主要在性能上的提升和部分新功能點的實現。
新版本更高效。
比如：6.6+提出的ilm索引生命周期管理，你如果關注Elastic Meetup的話，印象ebay和阿里還有其他公司自己就實現過類似功能。
原有版本有類似的功能，只不過是非常、非常麻煩、繁瑣，所以，才有了ilm的誕生。
新版本迎合了市場的需求。
比如：7.0的黑暗模式，實際在grafana或類似競品BI中都有類似的功能，猜測Kibana升級一方面是用戶需求，另一方面也是競品分析的結果。
新版本性能極大提升。
比如：7.0的terms融合新算法，有37倍的提升。
4.2 新版本的不變
《暗時間》作者劉未鵬說過“底層的技術永遠不過時”。
不必說倒排索引機制不會變，也不必說Lucene的改動也相對較小。單是：ES的基礎功能全文檢索、多種聚合等幾乎不會有太大的變動。
原文 鏈接
作者： 銘毅天下