5.0
支持Lucene 6.x
Instant Aggregations，在Shard層面提供了Aggregation緩存
新增 Sliced Scroll類型，現在Scroll接口可以併發來進行數據遍歷了。每個Scroll請求，可以分成多個Slice請求，可以理解爲切片，各Slice獨立並行，利用Scroll重建或者遍歷要快很多倍。
新增了Profile API
同時支持search和aggregation的profile
有一個新的 Search After 機制，其實和 scroll 類似，也是遊標的機制，它的原理是對文檔按照多個字段進行排序，然後利用上一個結果的最後一個文檔作爲起始值，拿 size 個文檔，一般我們建議使用 _uid 這個字段，它的值是唯一的 id
新增Shrink API
新增了Rollover API
新增Reindex
提供了第一個Java原生的REST客戶端SDK
基於HTTP協議的客戶端對Elasticsearch的依賴解耦，沒有jar包衝突，提供了集羣節點自動發現、日誌處理、節點請求失敗自動進行請求輪詢，充分發揮Elasticsearch的高可用能力
新增Wait for refresh，提供了文檔級別的Refresh
新增Ingest Node
新增Painless Scripting
新增Task Manager
新增Depreated logging
新增Cluster allocation explain API
新增 half_float 類型
新增 :Matrix Stats Aggregation
爲索引寫操作添加順序號
引入新的字段類型 Text/Keyword 來替換 String
關於 Index Settings
現在，配置驗證更加嚴格和保證原子性，如果其中一項失敗，那個整個都會更新請求都會失敗，不會一半成功一半失敗。下面主要說兩點：
1.設置可以重設會默認值，只需要設置爲 null即可
2.獲取設置接口新增參數include_defaults,可以直接返回所有設置和默認值
集羣管理方面，新增Deleted Index Tombstones
Cluster state 的修改現在會和所有節點進行 ack 確認。
Shard 的一個副本如果失敗了， Primary 標記失敗的時候會和 Master 節點確認完畢再返回。
使用 UUID 來作爲索引的物理的路徑名，有很多好處，避免命名的衝突。
_timestamp 和 _ttl 已經移除，需要在 Ingest 或者程序端處理。
ES 可直接用 HDFS 來進行備份還原（ Snapshot/Restore ）了
Delete-by-query 和 Update-by-query 重新回到 core ，以前是插件，現在可以直接使用了，也是構建在 Reindex 機制之上。(es1.x版本是直接支持，在es2.x中提取爲插件，5.x繼續迴歸直接支持)
HTTP 請求默認支持壓縮，當然 http 調用端需要在 header 信息裏面傳對應的支持信息。
創建索引不會再讓集羣變紅了，不會因爲這個卡死集羣了。
默認使用 BM25 評分算法，效果更佳，之前是 TF/IDF。
快照 Snapshots 添加 UUID 解決衝突
限制索引請求大小，避免大量併發請求壓垮 ES
限制單個請求的 shards 數量，默認 1000 個
移除 site plugins ，就是說 head 、 bigdesk 都不能直接裝 es 裏面了，不過可以部署獨立站點（反正都是靜態文件）或開發 kibana 插件
允許現有 parent 類型新增 child 類型
這個功能對於使用parent-child特性的人應該非常有用。
支持分號（；）來分割 url 參數，與符號（ & ）一樣
6.0
無宕機升級
使之能夠從 5 的最後一個版本滾動升級到 6 的最後一個版本，不需要集羣的完整重啓。無宕機在線升級，無縫滾動升級
跨多個 Elasticsearch 羣集搜索
和以前一樣，Elasticsearch 6.0 能夠讀取在 5.x 中創建的 Indices ，但不能讀取在 2.x 中創建的 Indices 。不同的是，現在不必重新索引所有的舊 Indices ，你可以選擇將其保留在 5.x 羣集中，並使用跨羣集搜索同時在 6.x 和 5.x 羣集上進行搜索
遷移助手
Kibana X-Pack 插件提供了一個簡單的用戶界面，可幫助重新索引舊 Indices ，以及將 Kibana、Security 和 Watcher 索引升級到 6.0 。 羣集檢查助手在現有羣集上運行一系列檢查，以幫助在升級之前更正任何問題。 你還應該查閱棄用日誌，以確保您沒有使用 6.0 版中已刪除的功能
使用序列號更快地重啓和還原
6.0 版本中最大的一個新特性就是序列 ID，它允許基於操作的分片恢復。 以前，如果由於網絡問題或節點重啓而從集羣斷開連接的節點，則節點上的每個分區都必須通過將分段文件與主分片進行比較並複製任何不同的分段來重新同步。 這可能是一個漫長而昂貴的過程，甚至使節點的滾動重新啓動非常緩慢。 使用序列 ID，每個分片將只能重放該分片中缺少的操作，使恢復過程更加高效
使用排序索引更快查詢
通過索引排序，只要收集到足夠的命中，搜索就可以終止。它對通常用作過濾器的低基數字段（例如 age, gender, is_published）進行排序時可以更高效的搜索，因爲所有潛在的匹配文檔都被分組在一起。
稀疏區域改進
以前，每個列中的每個字段都預留了一個存儲空間。如果只有少數文檔出現很多字段，則可能會導致磁盤空間的巨大浪費。現在，你付出你使用的東西。密集字段將使用與以前相同的空間量，但稀疏字段將顯着減小。這不僅可以減少磁盤空間使用量，還可以減少合併時間並提高查詢吞吐量，因爲可以更好地利用文件系統緩存
參考資料：
https://www.elastic.co/guide/en/elasticsearch/reference
elasticsearch是基於Lucene之上的，如果需要看Lucene版本特性 可以參考：
https://blog.csdn.net/jiangchao858/article/details/78897818
https://www.cnblogs.com/houzheng/p/9150314.html
https://blog.csdn.net/weixin_33843409/article/details/85533741