Elastic{ON}北京分享了Elasticsearch7.0在Speed,Scale,Relevance等方面的很多新特性。
比快更快，有傳說中的那麼牛逼嗎？盤他！
通過本文，你能瞭解到：
- Elasticsearch&Kibana 7.部署體驗
- Elasticsearch7 革命性更新
- Elasticsearch 7升級注意事項
- Elasticsearch 版本更新太快了，學不動了，腫麼辦？
1、ES&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.5 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的特性遠不止這些，更多新版本特性推薦閱讀：
1、https://www.elastic.co/cn/blog/elastic-stack-7-0-0-released?elektra=products&storm=main
2、https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking-changes-7.0.html#_literal_network_breaker_inflight_requests_overhead_literal_increased_to_2
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 新版本的變
變是永恆的，尤其是基於開源軟件加上上市公司的推動。
實際上，高版本較低版本，主要在性能上的提升和部分新功能點的實現。
- 1、新版本更高效。
比如：6.6+提出的ilm索引生命週期管理，你如果關注Elastic Meetup的話，印象ebay和阿里還有其他公司自己就實現過類似功能。
原有版本有類似的功能，只不過是非常、非常麻煩、繁瑣，所以，纔有了ilm的誕生。
- 2、新版本迎合了市場的需求。
比如：7.0的黑暗模式，實際在grafana或類似競品BI中都有類似的功能，猜測Kibana升級一方面是用戶需求，另一方面也是競品分析的結果。
- 3、新版本性能極大提升。
比如：7.0的terms融合新算法，有37倍的提升。
4.2 新版本的不變
《暗時間》作者劉未鵬說過“底層的技術永遠不過時”。
不必說倒排索引機制不會變，也不必說Lucene的改動也相對較小。單是：ES的基礎功能全文檢索、多種聚合等幾乎不會有太大的變動。
4.3 還存在學不動嗎？
夯實打牢基礎基本功，理解ELK更新的變與不變。80-90%+的時間關注基礎，10%左右的時間關注增量的變化即可。
以不變應萬變，方爲生存之道！
參考：
https://blog.csdn.net/yihucha166/article/details/8500247
https://mp.weixin.qq.com/s/JWSCT_rK6KLRr_cl7gAG9g
銘毅天下——Elasticsearch基礎、進階、實戰第一公衆號