2. 程式人生 > >先森林後樹木：Elasticsearch各版本升級核心內容必看

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

阿新 • • 發佈：2019-10-01

在學習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

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

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

參考文章：