Elasticsearch搜索調優權威指南 （1/3）

英文原文：https://qbox.io/blog/elasticsearch-search-tuning-5-0-ultimate-guide
作者：Adam Vanderbush
譯者：楊振濤

目錄

1. 文檔建模
2. 全局序列號和延遲
3. 多代關系
4. 為文件系統緩存分配內存

Elasticsearch搜索調優權威指南，是QBOX在其博客上發布的系列文章之一，本文是該系列的第一篇，主要從文檔建模、內存分配、文件系統緩存、GC和硬件等方面介紹了優化查詢性能的一些經驗。

Elasticsearch 5.0.0確實是在2.x之后的一個大版本，為大家帶來了許多新東西。Elasticsearch現在作為Elastic Stack中的一員，與整個技術棧的其他產品的版本號已經對齊，現在Kibana、Logstash、Beats和Elasticsearch全都是5.0版本了。

這個版本的Elasticsearch是目前為止最快、最安全、最彈性，也是最易用的，而且還帶來了很多的改進和新特性。

我們已經通過“Elasticsearch性能調優權威指南”系列，介紹了一些性能調優的基本經驗和方法，解釋了每一步最關鍵的系統設置和衡量指標。該系列共分下列3個部分：

• The Authoritative Guide to Elasticsearch Performance Tuning (Part 1)?
• The Authoritative Guide to Elasticsearch Performance Tuning (Part 2)?
• The Authoritative Guide to Elasticsearch Performance Tuning (Part 3)

索引決策也很重要，它對如何搜索數據有很大的影響。如果是一個字符串字段，是否需要分詞或歸一化？如果是，怎么做？如果是一個數值型屬性，需要哪種精度？還有很多其他類型，比如date-time、geospatial shape以及父子關系等，需要更多特別的考慮。

我們也通過一個系列教程討論了“Elasticsearch索引性能優化”，介紹了一些通用的技巧和方法，來最大化索引的吞吐量并降低監控和管理的負載。該教程分如下3個部分：

• How to Maximize Elasticsearch Indexing Performance (Part 1)?
• How to Maximize Elasticsearch Indexing Performance (Part 2)?
• How to Maximize Elasticsearch Indexing Performance (Part 3)

本文旨在推薦一些搜索調優技術、策略以及Elasticsearch 5.0及以上的推薦特性。

1.文檔建模

內部對象屬性數組并不像期望的那樣工作。Lucene?中沒有內部對象的概念，所以Elasticsearch把對象層次展開到一個由屬性名稱和屬性值組成的簡單列表中。以下列文檔為例：

curl -XPUT 'localhost:9200/my_index/my_type/1?pretty' -H 'Content-Type: application/json' -d '{
 "group" : "fans",
 "user" : [
   {
     "first" : "John",
     "last" :  "Smith"
   },
   {
     "first" : "Alice",
     "last" :  "White"
   }
 ]
}'

該請求會在內部轉換為如下的文檔形式：

{
  "group" :        "fans",
  "user.first" : [ "alice", "john" ],
  "user.last" :  [ "smith", "white" ]
}

如果需要索引對象數組，并維護數組中每個對象的依賴關系，應當使用內嵌數據類型而不是對象數據類型。內嵌對象在內部會把數組中的每個對象當作單獨的隱藏文檔來索引，即使用下述內嵌查詢，可以單獨查詢每個內嵌對象：

curl -XPUT 'ES_HOST:ES_PORT/my_index?pretty' -H 'Content-Type: application/json' -d '{
 "mappings": {
   "my_type": {
     "properties": {
       "user": {
         "type": "nested"
       }
     }
   }
 }
}'

curl -XPUT 'ES_HOST:ES_PORT/my_index/my_type/1?pretty' -H 'Content-Type: application/json' -d '{
 "group" : "fans",
 "user" : [
   {
     "first" : "John",
     "last" :  "Smith"
   },
   {
     "first" : "Alice",
     "last" :  "White"
   }
 ]
}'

curl -XGET 'ES_HOST:ES_PORT/my_index/_search?pretty' -H 'Content-Type: application/json' -d '{
 "query": {
   "nested": {
     "path": "user",
     "query": {
       "bool": {
         "must": [
           { "match": { "user.first": "Alice" }},
           { "match": { "user.last":  "Smith" }}
         ]
       }
     }
   }
 }
}'

curl -XGET 'ES_HOST:ES_PORT/my_index/_search?pretty' -H 'Content-Type: application/json' -d '{
 "query": {
   "nested": {
     "path": "user",
     "query": {
       "bool": {
         "must": [
           { "match": { "user.first": "Alice" }},
           { "match": { "user.last":  "White" }}
         ]
       }
     },
     "inner_hits": {
       "highlight": {
         "fields": {
           "user.first": {}
         }
       }
     }
   }
 }
}'

當有一個主實體比如一篇博客文章，帶有一些有一定關系但又不是非常重要的其他實體比如評論時，內嵌對象會非常有用。如果能根據評論內容來查詢到博客文章，那就很不錯，而且內嵌查詢和過濾器一起提供了更快的join查詢能力。

內嵌對象模型的缺點如下：

為了 增加 、修改 或 刪除 一個內嵌對象文檔，整個文檔必須重建索引；這就導致內嵌文檔越多開銷就越大。

搜索請求返回整個文檔，而不是只返回匹配的內嵌文檔。雖然已經以后計劃支持返回根文檔的部分最配內嵌文檔，但目前仍然不支持。

有時候可能需要把主文檔和其關聯實體分離，這種分離由父子關系來提供。

通過建立另一個文檔的父類型mapping，可以在相同索引的文檔之間建立父子關系：

curl -XPUT 'ES_HOST:ES_PORT/my_index?pretty' -H 'Content-Type: application/json' -d '{
 "mappings": {
   "my_parent": {},
   "my_child": {
     "_parent": {
       "type": "my_parent"
     }
   }
 }
}'

curl -XPUT 'ES_HOST:ES_PORT/my_index/my_parent/1?pretty' -H 'Content-Type: application/json' -d '{
 "text": "This is a parent document"
}'

curl -XPUT 'ES_HOST:ES_PORT/my_index/my_child/2?parent=1&pretty' -H 'Content-Type: application/json' -d '{
 "text": "This is a child document"
}'

curl -XPUT 'ES_HOST:ES_PORT/my_index/my_child/3?parent=1&refresh=true&pretty' -H 'Content-Type: application/json' -d '{
 "text": "This is another child document"
}'

curl -XGET 'ES_HOST:ES_PORT/my_index/my_parent/_search?pretty' -H 'Content-Type: application/json' -d '{
 "query": {
   "has_child": {
     "type": "my_child",
     "query": {
       "match": {
         "text": "child document"
       }
     }
   }
 }
}'

父子join對管理實體關系非常有用，尤其是在索引時間比檢索時間很重要的情形下，但是它會帶來較大的開銷；父子查詢比同等的內嵌查詢要慢5到10倍。

2.全局序列號和延遲

父子關系使用了全局序列號來加速join操作。無論父子map是否使用了內存緩存或磁盤上的doc value，全局序列號仍然需要在索引發生任何改變時進行重建。

分片中的父代越多，全局序列號構建就越耗時。相對于需要父代和較少的子代， 父子關系最適合每個父代有很多子代的情形。

全局序列號默認是 延遲 構建：refresh后的第一個父子查詢或聚合請求將會觸發構建全局序列號。這會讓用戶感知到一個明顯的潛在峰值。可以使用eager_global_ordinals 來把查詢期構建全局序列號的成本轉移到refresh期，通過如下方式mapping _parent屬性：

curl -XPUT 'ES_HOST:ES_PORT/company -d ‘{
  "mappings": {
    "branch": {},
    "employee": {
      "_parent": {
        "type": "branch",
        "fielddata": {
          "loading": "eager_global_ordinals"
        }
      }
    }
  }
}’

這里，_parent屬性的全局序列號將會在一個新的段搜索可見時被構建。

對于很多的父代，全局序列號要花費數秒鐘來構建。此時，需要增加refresh_interval，以便refresh的頻率更低，而全局序列號保持可用的時間更長。這將大幅減少每秒鐘重建全局序列號的CPU消耗。

3.多代關系

對多代數據的Join（參考Grandparents and Grandchildren）能力聽起來很吸引人，但需要思考其代價：

• Join越多，性能越差。
• 每一個父代都需要把自己的string _id屬性保存在內存，這可能會消耗大量RAM。
• 當考慮關系型方案及父子關系是否適合時，可參考下列關于父子關系的建議：
• 保守使用父子關系，僅當子代比父代多很多時才考慮。
• 避免在單個查詢中使用多父子關系來join。
• 避免對使用has_child過濾器，或score_mode為 none 的has_child查詢來打分。
• 父ID盡量簡短，以便在doc value中更好地壓縮，從而在瞬時加載時消耗更少的內存。

4.為文件系統緩存分配內存

對于運行中Elasticsearch，內存是需要密切監控的重要資源之一。Elasticsearch和Lucene通過JVM堆內存和文件系統緩存兩種方式來消耗內存。由于Elasticsearch運行在Java虛擬機（JVM）中，所以JVM的GC周期和頻率也需要重點監控。

JVM堆內存

對于Elasticsearch一個“剛好合適”的JVM堆大小是非常重要的——不能設置過大或過小，原因見后文。一般來說Elasticsearch的經驗值是分配少于50%的可用RAM給JVM堆，且不要超過32GB。

為Elasticsearch分配過少的堆內存，那么就會留給Lucene更多內存，而Lucene重度依賴于文件系統緩存來快速處理請求。不管怎樣也不能設置過小的堆內存，因為當應用由于頻繁GC而面臨短時中斷時，可能會遭遇內存溢出錯誤或吞吐量下降。

Elasticsearch默認安裝時設置的JVM堆大小為1GB，這在大多數情況下都偏小。可以通過環境變量來設置期望的對大小并重啟Elasticsearch：

export ES_HEAP_SIZE=10g

設置JVM堆大小的另一種方式（相當于設置一樣的最小值和最大值，以防止重新調整堆大小），是在每次啟動Elasticsearch時通過命令行參數指定：

ES_HEAP_SIZE="10g" ./bin/elasticsearch

這兩種示例方式都是設置了10GB的堆大小，為了驗證是否設置成功，執行：

curl -XGET http://ES_HOST:9200/_cat/nodes?h=heap.max

返回的輸出會顯示已正確地更新了最大堆內存。

垃圾回收

Elasticsearch依靠GC過程來釋放堆內存。由于GC本身也要消耗資源（為了釋放資源！），所以應當留意GC頻率和持續時間，以確認是否需要調整堆內存大小。設置過大的堆內存，換來的是更長的GC時間；這種過多的停頓非常危險，因為可能導致集群誤認為該節點網絡異常而失聯。

因此，Elasticsearch重度依賴文件系統緩存來加速搜索。一般需要保證至少有一半的可用內存用于文件系統緩存，這樣Elasticsearch才能保持索引數據的熱點區域都在物理內存中。

使用更快的硬件

如果搜索受限于I/O，應當考慮為文件系統緩存分片更多內存（參考前文），或者購買更快的驅動。特別地，SSD公認地比機械磁盤性能好很多。盡可能使用本地存儲，避免使用像 NFS 或 SMB 之類的遠程或網絡文件系統，也要注意像Amazon EBS這樣的虛擬化存儲。

Elasticsearch使用虛擬化存儲工作是沒有問題的，它因為快速和安裝簡單而受歡迎，但同樣不幸的是，在基礎上與專用的本地存儲相比它天生就比較慢。如果在EBS上創建了一個索引庫，請確認使用預分配的IOPS，否則很快就會被限流。

如果搜索受限于CPU，那么應當考慮購買更快的CPU。