1、首先看看跟效能有關的

1.1 aggregation 的改進也是非常大， Instant Aggregations。
Elasticsearch已經在Shard層面提供了Aggregation快取，如果你的資料沒有變化，ES能夠直接返回上次的快取結果，但是有一個場景比較特殊，就是 date histogram，大家kibana上面的條件是不是經常設定的相對時間，如：from:now-30d to:now，好吧，now是一個變數，每時每刻都在變，所以query條件一直在變，快取也就是沒有利用起來。經過一年時間大量的重構，現在可以做到對查詢做到靈活的重寫：
　　　　首先，now關鍵字最終會被重寫成具體的值；
　　　　其次 ， 每個shard會根據自己的資料的範圍來重寫查詢為 match_all

現在新增了一個：Sliced Scroll型別

　　用過Scroll介面吧，很慢？如果你資料量很大，用Scroll遍歷資料那確實是接受不了，現在Scroll介面可以併發來進行資料遍歷了。

　　每個Scroll請求，可以分成多個Slice請求，可以理解為切片，各Slice獨立並行，利用Scroll重建或者遍歷要快很多倍。

　　看看這個demo
　　
　　可以看到兩個 scroll 請求， id 分別是 0 和 1 ， max 是最大可支援的並行任務，可以各自獨立進行資料的遍歷獲取。

2、es在查詢優化

新增了一個Profile API。

　　都說要致富先修路，要調優當然需要先監控啦，elasticsearch在很多層面都提供了stats方便你來監控調優，但是還不夠，其實很多情況下查詢速度慢很大一部分原因是糟糕的查詢引起的，玩過SQL的人都知道，資料庫服務的執行計劃（execution plan）非常有用，可以看到那些查詢走沒走索引和執行時間，用來調優，elasticsearch現在提供了Profile API來進行查詢的優化，只需要在查詢的時候開啟profile：true就可以了，一個查詢執行過程中的每個元件的效能消耗都能收集到。
　　
　　　那個子查詢耗時多少，佔比多少，一目瞭然。

　　同時支援search和aggregation的profile。

　　還有一個和翻頁相關的問題，就是深度分頁 ，是個老大難的問題，因為需要全域性排序（ number_of_shards * (from + size) ），所以需要消耗大量記憶體，以前的 es 沒有限制，有些同學翻到幾千頁發現 es 直接記憶體溢位掛了，後面 elasticsearch 加上了限制， from+size 不能超過 1w 條，並且如果需要深度翻頁，建議使用 scroll 來做。

　　但是 scroll 有幾個問題，第一個是沒有順序，直接從底層 segment 進行遍歷讀取，第二個實時性沒法保證， scroll 操作有狀態， es 會維持 scroll 請求的上下文一段時間，超時後才釋放，另外你在 scroll 過程中對索引資料進行了修改了，這個時候 scroll介面是拿不到的，靈活性較差， 現在有一個新的 Search After 機制，其實和 scroll 類似，也是遊標的機制，它的原理是對文件按照多個欄位進行排序，然後利用上一個結果的最後一個文件作為起始值，拿 size 個文件，一般我們建議使用 _uid 這個欄位，它的值是唯一的 id 。
　　
　　Search After

　　根據你的排序條件來的，三個排序條件，就傳三個引數。

3、索引與分片管理相關

新增了一個 Shrink API

　　相信大家都知道elasticsearch索引的shard數是固定的，設定好了之後不能修改，如果發現shard太多或者太少的問題，之前如果要設定Elasticsearch的分片數，只能在建立索引的時候設定好，並且資料進來了之後就不能進行修改，如果要修改，只能重建索引。

　　現在有了Shrink介面，它可將分片數進行收縮成它的因數，如之前你是15個分片，你可以收縮成5個或者3個又或者1個，那麼我們就可以想象成這樣一種場景，在寫入壓力非常大的收集階段，設定足夠多的索引，充分利用shard的並行寫能力，索引寫完之後收縮成更少的shard，提高查詢效能。

　　這裡是一個API呼叫的例子
　　
　　上面的例子對 my_source_index 伸縮成一個分片的 my_targe_index, 使用了最佳壓縮。

　　有人肯定會問慢不慢？非常快！ Shrink的過程會藉助作業系統的Hardlink進行索引檔案的連結，這個操作是非常快的，毫秒級Shrink就可收縮完成，當然windows不支援hard link，需要拷貝檔案，可能就會很慢了。

新增了一個Rollover API。

　　前面說的這種場景對於日誌類的資料非常有用，一般我們按天來對索引進行分割（資料量更大還能進一步拆分），我們以前是在程式裡設定一個自動生成索引的模板，大家用過logstash應該就記得有這麼一個模板logstash-[YYYY-MM-DD]這樣的模板，現在es5.0裡面提供了一個更加簡單的方式：Rollover API

　　API呼叫方式如下：
　　
　　從上面可以看到，首先建立一個 logs-0001 的索引，它有一個別名是 logs_write, 然後我們給這個 logs_write 建立了一個 rollover 規則，即這個索引文件不超過 1000 個或者最多儲存 7 天的資料，超過會自動切換別名到 logs-0002, 你也可以設定索引的 setting 、 mapping 等引數 , 剩下的 es 會自動幫你處理。這個特性對於存放日誌資料的場景是極為友好的。

新增：Reindex
另外關於索引資料，大家之前經常重建，資料來源在各種場景，重建起來很是頭痛，那就不得不說說現在新加的Reindex介面了，Reindex可以直接在Elasticsearch叢集裡面對資料進行重建，如果你的mapping因為修改而需要重建，又或者索引設定修改需要重建的時候，藉助Reindex可以很方便的非同步進行重建，並且支援跨叢集間的資料遷移。

　　比如按天建立的索引可以定期重建合併到以月為單位的索引裡面去。

　　當然索引裡面要啟用_source。

　　來看看這個demo吧，重建過程中，還能對資料就行加工。
　　
　　5.0裡面提供了第一個Java原生的REST客戶端SDK，相比之前的TransportClient，版本依賴繫結，叢集升級麻煩，不支援跨Java版本的呼叫等問題，新的基於HTTP協議的客戶端對Elasticsearch的依賴解耦，沒有jar包衝突，提供了叢集節點自動發現、日誌處理、節點請求失敗自動進行請求輪詢，充分發揮Elasticsearch的高可用能力，並且效能不相上下。

4、其他特性

　4.1 新增了一個 Wait for refresh 功能。

　　索引操作新增refresh引數，大家知道elasticsearch可以設定refresh時間來保證資料的實時性，refresh時間過於頻繁會造成很大的開銷，太小會造成資料的延時，之前提供了索引層面的_refresh介面，但是這個介面工作在索引層面，我們不建議頻繁去呼叫，如果你有需要修改了某個文件，需要客戶端實時可見怎麼辦？

　　在 5.0中，Index、Bulk、Delete、Update這些資料新增和修改的介面能夠在單個文件層面進行refresh控制了，有兩種方案可選，一種是建立一個很小的段，然後進行重新整理保證可見和消耗一定的開銷，另外一種是請求等待es的定期refresh之後再返回。

　　再一個比較重要的特性就是IngestNode了，大家之前如果需要對資料進行加工，都是在索引之前進行處理，比如logstash可以對日誌進行結構化和轉換，現在直接在es就可以處理了，目前es提供了一些常用的諸如convert、grok之類的處理器，在使用的時候，先定義一個pipeline管道，裡面設定文件的加工邏輯，在建索引的時候指定pipeline名稱，那麼這個索引就會按照預先定義好的pipeline來處理了；

　　Demo again：
　　
　　　上圖首先建立了一個名為my-pipeline-id的處理管道，然後接下來的索引操作就可以直接使用這個管道來對foo欄位進行操作了，上面的例子是設定foo欄位為bar值。

　　上面的還不太酷，我們再來看另外一個例子，現在有這麼一條原始的日誌，內容如下：

{

“message”: “55.3.244.1 GET /index.html 15824 0.043”

}

　　google之後得知其Grok的pattern如下：）

%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration}

　　那麼我們使用Ingest就可以這麼定義一個pipeline：
　　
　　那麼通過我們的 pipeline 處理之後的文件長什麼樣呢，我們獲取這個文件的內容看看：
　　
　　　很明顯，原始欄位 message 被拆分成了更加結構化的物件了。