Elasticsearch前沿：ES 5.x改進詳解與ES6展望

曾勇（Medcl），Elastic 工程師與佈道師，2015 年加入 Elastic 公司。加入 Elastic 之前，在搜索和運維等方面積累了超過七年的經驗。Elasticsearch 國內首批用戶，自 2010 年起就開始接觸 Elasticsearch，是 ES 中文社區發起人，也是 Elastic 在中國的首位員工。

我最早是從 2010 年 3 月開始接觸 Elasticsearch ，後面在 2015 年 9 月加入了 Elastic ，即 Elasticsearch 這款開源軟體背後的公司，一直圍繞在 ES 打轉，也算是 ES 半個老司機了。

自去年 10 月正式發布 5.0 以來， Elasticsearch 又新增了不少東西，讓我們一起來看一下都有哪些值得關注的特性和改進吧。

數據結構方面

首先是索引這塊的改進，大家知道 ES 的數據支持增刪改查，比如修改文檔的時候其實是需要通過 ID 找到 Lucene 文件里對應的文檔先刪除然後再插入一個新的，所有寫操作需要進行相應的版本檢查來確保沒有衝突。

如果你的場景是日誌，那麼基本上數據進去之後是不需要進行修改的，所以現在 ES 新增了一個 append-only 的索引模式，也就是當 ES 是自動生成 ID 的時候， ES 可以跳過不必要的版本檢測，大概可以提升 20% 左右的索引性能。

我們來看一組前後對比圖吧，單這一塊的提升還是可圈可點的。

在數據結構方面，新增了多個 range 欄位類型，有什麼用呢，現在你可以計算連續數據的交並集，可以是時間範圍，也可以是數值範圍。

比如數據存放的是會議信息，航班有一個 range 欄位，裡面存的是會議的開始和結束時間，你通過對應的 range 查詢可以很方便的查詢，得到某個時間點哪些會議同時正在進行，那段時間會議室有空閑，可以預訂等等。

常見的場景，比如日曆，電視節目單。

怎麼使用呢？看例子會比較清晰一點。

首先看看怎麼定義吧，下面的這個例子， mapping 裡面設置欄位的 type 為 date_range 即表示一個時間的範圍欄位：

然後我們插入一些數據，可以看到指定的是一個範圍，有起始值。

查詢呢？

大概就是這麼簡單。

下一個特性值得介紹的就是 _all 欄位的移除

關於 _all 這個欄位，場景其實就是為了滿足快速檢索的需求，當你不知道 mapping 裡面有什麼欄位的情況下，你也能夠自由的進行搜索， 所以為了實現這個需求，就有一個 _all 欄位，它會把其他欄位的內容都拷貝到這個欄位裡面，然後都當成 string 類型來處理，所以就存在了數據的冗餘了，另外數字當成 string 也不能很好的壓縮，並且都在 _all 一個欄位，所以只能用一種分析器，在高亮的時候也是對這個 _all 欄位進行的高亮，而不是真實的欄位值，顯示起來效果也不好。

現在 query_string 和 simple_query_string 查詢引入了一個 all_fields 模式，在沒有指定欄位的情況下，默認可以自動選擇相關類型的欄位分別執行查詢，自動幫你展開，使用起來更加簡單，另外， _all 欄位將在 6.0 默認禁用且不可配置。

這裡有一個去掉 _all 欄位的前後對比，可以看到磁碟佔用少了不少，索引性能也有一些提升。

索引性能的提升，圖上轉折點就是。下面是對應的磁碟空間的下降。

接下來，我們看看搜索的高亮，我們知道文本高亮是搜索體驗的重要的一環，通過顯示匹配結果的文本塊並對關鍵字進行高亮能夠讓我們對搜索結果有一個直觀的認識。

現在有一個新的高亮器： Unified Highlighter，大家可能會問，目前 ES 默認已經提供了 3 種不同的高亮器，為什麼還會有一個新的輪子呢，因為之前的用法有點複雜 , 用戶選擇起來比較困難，新的 unified highlighter 目的就是簡化高亮的使用，可以支持前面 3 種高亮類型的自動選擇。

還有一個是 keyword 類型可以通過 normalizer 來進行標準化了， keyword 類型相比 text 類型就是不能分詞，但是可能同樣需要進行相應的標準化處理，比如統一轉成小寫，移除標點符號等等，使用方式和 analyzer 一樣，比如下面的需求：

儘管設置了 keyword 類型，但是我同樣是需要對文本進行處理的啊，用戶不可能輸入的完全都是一樣，錯一個大小寫，可能就查不出來了。

新的 normalizer 使用起來 很簡單，和 analyzer 基本一樣，專門用於 keyword 類型，如下：

另一個就是 Multi-Word Synonyms，之前是不支持同義詞中間有空格分割的，分詞的時候會幫你切分開，搜索的時候不能正確處理片語這種同義詞，如下面的場景。

這裡有一組同義詞，看起來沒毛病。

有一個 phrase 查詢，看起來也沒毛病。

我的同義詞過濾器就不對了，如下：

new is old ？這是什麼情況？

因為分詞的時候，把他們單個字拆開進行的同義處理。新的多詞同義詞採用 graph 方式處理，很好的解決了上面的問題。

同義詞現在可以支持片語了，也就是說同義詞如果是由多個片語成的，不會在分詞的時候被傻傻的拆開，而是正確的處理。

還一個就是欄位摺疊（ Field collapsing），這個特性比較有意思，你可以在搜索的時候，按某個欄位作為維度進行去重，我這裡寫過一篇詳細的博客，有興趣的可以去看看：

http://elasticsearch.cn/article/132

Cancellable searches

ES 的搜索，對於一些耗時較長的查詢，以前是沒有辦法取消的，除了幹掉節點重來或者等待結束，沒有辦法，現在可以通過 ES 的任務管理機制來進行取消了， 5.3 已經提供。感興趣的可以查看文檔：

https://www.elastic.co/guide/en/Elasticsearch/reference/5.3/search.html#global-search-cancellation

Partitioned term aggs

ES 的聚合功能很強大吧， term aggs 相信也是大家常用的一種，如果遇到欄位裡面唯一 term 很多的場景，聚合起來不只是慢，可能還沒法正常運行。

現在 term aggs 提供了一種分區的概念，你可以對一個欄位，分 n 次進行聚合，分而治之，有興趣的可以看看文檔：

https://www.elastic.co/guide/en/Elasticsearch/reference/5.3/search-aggregations-bucket-terms-aggregation.html#_filtering_values_with_partitions

另外，當你的集群變紅的時候，你是不是手忙腳亂過，檢查一大堆配置，訪問一大堆介面來查看到底是哪裡出了問題。

現在方便了，新增的 /_cluster/allocation/explain 介面能夠直接告訴你哪裡出了問題：

Java REST Client 也有了更新， ES 之前提供了一個偏底層的 Java HTTP REST client，但是用起來太費勁，需要手動拼 JSON，現在， Java REST Client 分成了 Java High Level REST Client 和 Java Low Level REST Client， High Level 基於 Low Level 來實現，顧名思義，提供更多用戶方便的介面調用， High Level REST Client 將提供和 Transport Client 類似的介面，不用手動去拼接 QueryDSL 的 JSON 了，目測在 5.5 版本提供。

聽說你們有很多集群在跑？那你有沒有用過 tribe node 來訪問多個集群呢？， tribe-node 的工作方式是合并多個集群的元數據到一起，負責請求的轉發。

大概就是這個圖。

不過 tribe-node 有幾個問題，首先，他需要和各個集群的每個節點建立連接，另外 tribe-node 的 配置的靜態的，修改之後需要重啟 tribe-node，每個集群的元數據變化之後都需要進行合并，頻繁的操作十分影響性能，並且集群的索引名稱必須保證不能相同，同時，通過 tribe-node 只能只讀，無法創建索引，再者，跨集群查詢，會將所有的分片的數據都放到 tribe-node 上進行 reduce，如果分片很多，可能出現 OOM 等問題。

新引入的 cross-cluster 跨集群功能就是為了方便以一種更優雅的方式來替換掉 tribe-node。

先來上一張圖，裡面可以看到如何創建一個 cross-cluster。

可以看到，集群的任何節點都能執行跨集群操作，節點的元數據不需要頻繁更新，集群間索引基於命名空間進行了隔離。

什麼是命名空間？

GET sales:*,r_and_d:logs*/_search

{

"query": { … }

}

可以看到上面的 QueryDSL，正常的索引前面有 namespace：這樣的前綴，這就是命名空間，也就是選擇不同的集群。

不僅可以動態設置多個集群的訪問，也不需要重啟節點。集群間互相不受影響，更沒有頻繁的元數據的同步。

Kibana 能夠完全訪問多個集群，且能創建索引和進行修改，具備完整訪問許可權。

跨集群訪問只需要很輕量級的幾個連接，不需要和每個節點都建立連接，這個功能在 5.3 已經支持。

Batched Search Reduce Phases

另外，以前的搜索的 reduce 操作都是要等到把每個分片的結果都拿到本地之後再做合并，所以為了避免海量分片造成的資源大量佔用的問題，之前是有一個最多 1000 個分片的軟限制，也就是一個搜索最多只能檢索 1000 個分片，現在新增的 batched search reduce phases 提供了分批進行 reduce 的行為，也就是不用全部拿到之後再做 reduce，而是拿到足夠的分片（默認 512）之後就開始 做 reduce，然後拿到合并結果，釋放相關的資源，繼續獲取其他的分片數據繼續進行 reduce，這樣就能處理海量的數據了，這個功能在 5.4 發布。

ES 6.0 展望

上面的這些功能基本會在 5.x 提供，而 es6.0 早已在路上了，有很多特性值得期待：

1. 稀疏性 Doc Values 的支持，大家知道 es 的 doc values 是列式存儲，文檔的原始值都是存放在 doc values 裡面的，而稀疏性是指，一個索引裡面，文檔的結構其實是多樣性的，但是鬱悶的是只要一個文檔有這個欄位，其他所有的文檔儘管沒有這個欄位，可也都要承擔這個欄位的開銷，所以會存在磁碟空間的浪費，而這塊的改進就是這個問題。

2. Index sorting，即在索引階段的排序，即我們查詢的時候有時候會根據某個欄位的值進行排序，比如時間、編號等等，如果在索引的時候提取排好序，那麼搜索或聚合的時候就會非常快，相應的直接走預先排序好的索引就行了。當然索引的時候會要增加額外開銷，適合不怎麼變化的索引的場景。

3. 順序號的支持，每個 es 的操作都有一個順序編號，這個屬於 es 內部的一個功能，可以提供：快速的分片副本恢復或同步；跨數據中心的節點恢復；甚至提供一個 Changes API 等等；

4. 無縫滾動升級，使之能夠從 5 的最後一個版本滾動升級到 6 的最後一個版本，不需要集群的完整重啟。無縫滾動升級，也就是不用停服務，在線升級，補充一下。

什麼是最後一個版本？

也就是 6 發布第一個版本，比如 6.0 的時候， 5 的對應的那個最後的發布的版本，比如 5.5，那麼 5.5 可以直接滾動升級到 6.0。並且這兩個版本我們稱為主要版本，他們還支持跨大版本的搜索。就是前面提到的 cross-cluster 特性，不同的版本也能支持跨集群訪問，如下：

下面還有一些：

• Removal of types，在 6.0 裡面，開始不支持一個 index 裡面存在多個 type 了，所有的新的 index 都將只有一個虛擬的固定的 type： doc 來代替，基於 type 的 parent-child 關係將通過單獨的 join 欄位來實現， type 會在 7.0 徹底移除。

• Index-template inheritance，索引版本的繼承，目前索引模板是所有匹配的都會合并，這樣會造成索引模板有一些衝突問題， 6.0 將會只匹配一個，索引創建時也會進行驗證。

• Load aware shard routing， 基於負載的請求路由，目前的搜索請求是全節點輪詢，那麼性能最慢的節點往往會造成整體的延遲增加，新的實現方式將基於隊列的耗費時間自動調節隊列長度，負載高的節點的隊列長度將減少，讓其他節點分攤更多的壓力，搜索和索引都將基於這種機制。

• 已經關閉的索引將也支持 replica 的自動處理，確保數據可靠。

X-Pack 的部分特性：

6.0 的部分特性預告就上面這些，我猜下面的特性你也同樣感興趣：

Elasticsearch-SQL

Elasticsearch 官方也要支持的 SQL 特性了。

默認提供了一個 CLI 工具，可以很方便的執行 SQL 查詢，主要面向管理人員，提高常見操作的使用效率。

Kibana 裡面也可以直接執行。

另外也兼容 JDBC 協議，現存的很多基於 JDBC 協議的各種 SQL 工具及 BI 工具都能直接把 es 當資料庫來連接和進行數據分析。

支持在 Java 裡面通過 Java.sql 和 javax.sql API 介面訪問 ES 數據。

使用 ES 變得更加輕量級，使用起來無依賴。

機器學習

去年 Elastic 收購了業界領先的行為數據分析廠商 Prelert，現在相關產品已經集成進入了 X-Pack 的機器學習模塊，可以快速的實現基於 ES 數據的行為分析，藉助 ES 的海量實時處理能力，採用非監督機器學習來識別異常行為。

上圖是機器學習自動識別出來的異常數據點。

本文只是 ES 最近的眾多改進的一部分，有關更詳細的更新內容還以具體的版本發布記錄為準。

ElasticStack 的其他開源項目也有很多有意思的改進和 feature，願意了解更多的，可以關注我們官方及社區的活動：

http://elasticsearch.cn/article/141

Q&A

提問：能否說說 ES 是如何在 lucene 上實現分布式的？

這個不是一句話能夠說清楚點，可以參考我們的權威指南：

http://elasticsearch.cn/book/elasticsearch_definitive_guide_2.x/distributed-docs.html

提問：可否組織一些 ES 常見的複雜模型構建思路探討這樣的論題。主要是探討如何實現與優化。我想這是在座的同學都會有遇到的問題。

曾勇：複雜模型需要具體分析，可以參看我們的權威指南：

http://elasticsearch.cn/book/elasticsearch_definitive_guide_2.x/modeling-your-data.html

提問：ES 與 solr 對比有什麼優勢？技術選型時如何考慮？

曾勇：網上的對比有很多，我就不一一贅述了，如果沒有用過 solr，那建議直接使用 ES 吧，上手更快更簡單。另外網上的優劣比較其實也要結合自己的實際場景，實踐出真知。

問：請問下，如果我有 9G 的數據導入，如何導最快？之前 curl @xxx.txt 方式，但是數據文件一大 curl 標準格式導入就不行了。

曾勇：走 bulk 方式肯定是最快的，txt 內容是什麼格式呢，利用一些現存的工具，可以試試，比如 logstash，記得選擇 bulk 模式。導入的時候，有很多參數也對速度有幫助，這個就要去看看索引的優化這塊的內容了。