先森林後樹木：Elasticsearch各版本升級核心內容必看

在學習Elasticsearch 時候，因為各個版本的問題，搞不清，非常的頭疼，官方也給出了各個版本更新的情況，不過是英文版本，版本更新信息又特別多，最近學習，看了很多資料，沒有一個整理很清楚的，然後自己就統一整理下,首先聲明下麵的整理都是各個版本個人認為比較重要點，因為每個大版本更新內容太多，也不 ...

在學習Elasticsearch 時候，因為各個版本的問題，搞不清，非常的頭疼，官方也給出了各個版本更新的情況，不過是英文版本，版本更新信息又特別多，最近學習，看了很多資料，沒有一個整理很清楚的，然後自己就統一整理下,首先聲明下麵的整理都是各個版本個人認為比較重要點，因為每個大版本更新內容太多，也不能一一舉例，詳細需要參閱官方文檔，文章底部有鏈接，我也是為了自己方便在整體上，瞭解Elasticsearch 各個版本的迭代，可以更好的理解和使用Elasticsearch 產品，所以有了這篇文章。

初始版本 0.7.0

2010年5月14日發佈,第一個可以查詢到發版信息的版本，重要特性：

Zen Discovery 自動發現模塊
Groovy Client支持
簡單的插件管理機制
更好支持ICU分詞器
更多的管理API

初始化的版本，暫時不多介紹，先來這麼多。

升級1.0.0 版本

2014年2月14日發佈，重要特性： -Snapshot/Restore API 備份恢復API

支持聚合分析Aggregations
CAT API 支持
支持聯盟查詢
斷路器支持
Doc values 引入

2.0.0 版本

2015年10月28日發佈，重要特性：

增加了 pipleline Aggregations
query/filter 查詢合併，都合併到query中，根據不同的上下文執行不同的查詢
存儲壓縮可配置
Rivers 模塊被移除
Multicast 組播發現被移除，成為一個插件，生產環境必須配置單播地址

新特性5.0.0 版本

2016年10月26日發佈，重要特性：

Lucene 6.x 的支持，磁碟空間少一半；索引時間少一半；查詢性能提升25%；支持IPV6。
Internal engine級別移除了用於避免同一文檔併發更新的競爭鎖，帶來15%-20%的性能提升
Shrink API ，它可將分片數進行收縮成它的因數，如之前你是15個分片，你可以收縮成5個或者3個又或者1個，那麼我們就可以想象成這樣一種場景，在寫入壓力非常大的收集階段，設置足夠多的索引，充分利用shard的並行寫能力，索引寫完之後收縮成更少的shard，提高查詢性能
提供了第一個Java原生的REST客戶端SDK
IngestNode，之前如果需要對數據進行加工，都是在索引之前進行處理，比如logstash可以對日誌進行結構化和轉換，現在直接在es就可以處理了
提供了 Painless 腳本，代替Groovy腳本
移除 site plugins ，就是說 head 、 bigdesk 都不能直接裝 es 裡面了，不過可以部署獨立站點（反正都是靜態文件）或開發 kibana 插件
新增 Sliced Scroll類型，現在Scroll介面可以併發來進行數據遍歷了。每個Scroll請求，可以分成多個Slice請求，可以理解為切片，各Slice獨立並行，利用Scroll重建或者遍歷要快很多倍。
新增了Profile API
新增了Rollover API
新增Reindex
提供了第一個Java原生的REST客戶端SDK 基於HTTP協議的客戶端對Elasticsearch的依賴解耦，沒有jar包衝突，提供了集群節點自動發現、日誌處理、節點請求失敗自動進行請求輪詢，充分發揮Elasticsearch的高可用能力
引入新的欄位類型 Text/Keyword 來替換 String
限制索引請求大小，避免大量併發請求壓垮 ES
限制單個請求的 shards 數量，預設 1000 個

新特性6.0.0 版本

2017年8月31日發佈，重要特性：

稀疏性 Doc Values 的支持
Index sorting，即索引階段的排序。
順序號的支持，每個 es 的操作都有一個順序編號（類似增量設計）
無縫滾動升級
Removal of types，在 6.0 裡面，開始不支持一個 index 裡面存在多個 type
Index-template inheritance，索引版本的繼承，目前索引模板是所有匹配的都會合併，這樣會造成索引模板有一些衝突問題， 6.0 將會只匹配一個，索引創建時也會進行驗證
Load aware shard routing，基於負載的請求路由，目前的搜索請求是全節點輪詢，那麼性能最慢的節點往往會造成整體的延遲增加，新的實現方式將基於隊列的耗費時間自動調節隊列長度，負載高的節點的隊列長度將減少，讓其他節點分攤更多的壓力，搜索和索引都將基於這種機制。
已經關閉的索引將也支持 replica 的自動處理，確保數據可靠。

新特性7.0.0 版本

2019年4月10日發佈，重要特性：

集群連接變化：TransportClient被廢棄以至於，es7的java代碼，只能使用restclient。然後，個人綜合了一下，對於java編程，建議採用 High-level-rest-client 的方式操作ES集群
ES程式包預設打包jdk：以至於7.x版本的程式包大小突然邊300MB+ 對比6.x發現，包大了200MB+，正是JDK的大小
Lucene9.0
重大改進-正式廢除單個索引下多Type的支持 es6時，官方就提到了es7會刪除type，並且es6時已經規定每一個index只能有一個type。在es7中使用預設的_doc作為type，官方說在8.x版本會徹底移除type。 api請求方式也發送變化，如獲得某索引的某ID的文檔：GET index/_doc/id其中index和id為具體的值
7.1開始，Security功能免費使用
ECK-ElasticSearch Operator on Kubernetes
引入了真正的記憶體斷路器，它可以更精準地檢測出無法處理的請求，並防止它們使單個節點不穩定
Zen2 是 Elasticsearch 的全新集群協調層，提高了可靠性、性能和用戶體驗，變得更快、更安全，並更易於使用
新功能
- New Cluster coordination
- Feature - Complete High Level REST Client
- Script Score Query
性能優化
- Weak-AND演算法提高查詢性能
- 預設的Primary Shared數從5改為1，避免Over Sharding
- 更快的前 k 個查詢
- 間隔查詢(Intervals queries) 某些搜索用例（例如，法律和專利搜索）引入了查找單詞或短語彼此相距一定距離的記錄的需要。 Elasticsearch 7.0中的間隔查詢引入了一種構建此類查詢的全新方式，與之前的方法（跨度查詢span queries）相比，使用和定義更加簡單。與跨度查詢相比，間隔查詢對邊緣情況的適應性更強。

總結

通過各個版本的迭代升級會發現，Elasticsearch 的產品的重大改善體驗，瞭解了版本間的不同，會讓你認知提高一個檔次，網上文章一大片，有的時候你發現，文章作者操作的時候成功的，到了你這裡就失敗了，百思不得其中的奧秘，或者我的一個方法或者對象怎麼就沒了，誰對誰錯，沒有定論，懂得事情的本質才是重點，回到問題的根源，才是解決問題的根本。

希望本篇的介紹可以讓你在學習 Elasticsearch 的路上更順暢，等你學完了Elasticsearch最新版本後，回過頭來再看這篇文章的時候，感覺是不是一樣的，我覺得學習一門技術的時候，心裡要對全部輪廓有個認知，不至於鑽進一個空間，看不到整個森林的尷尬無效的境地。就像本文標題所說，先看整個森林，再去鑽研一課樹木，才會更懂。

END

如有收穫，請幫忙轉發，後續會有更好文章貢獻，您的鼓勵是作者最大的動力！

歡迎關註我的公眾號：架構師的修煉，獲得獨家整理的學習資源和日常乾貨推送。

參考文章：