先森林後樹木：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

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

歡迎關注個人公衆號：架構師的修煉，得到獨家整理的學習資源和平常乾貨推送。

參考文章：

• 官方文檔 Elasticsearch7.0.0版本更新notes
• Elasticsearch Reference 官方文檔，英文好的能夠進入
• 01ElasticSearch簡介及其發展歷史
• Lucene的版本迭代