ES集羣調整搜索速度

1、內存文件系統足夠的緩存

Elasticsearch嚴重依賴於文件系統緩存，以加快搜索速度。一般，您應確保至少有一半的可用內存分配給文件系統緩存，以便Elasticsearch能夠將索引的熱區保留在物理內存中。

2、使用更快的硬件

若是搜索是受CPU限制的，那就加大CPU。ES對CPU的要求，使用多核CPU優於單核CPU。

若是搜索是在I/O上受限制的話，就須要提供更多的內存和更快的硬盤。SSD硬盤性能優於機械硬盤，本地硬盤性能優於遠程虛擬硬盤。

3、文檔建模設計

文檔應該建模設計，是搜索儘量的快。避免使用 nested（慢幾倍）和父子關係（慢百倍），能夠經過對文檔進行非規範化的建模設計來達到相同的目的，解決問題。

4、搜索儘量少的字段

query_string或 multi_match查詢目標的字段越多，它的速度就越慢。

5、預索引數據

您應該利用查詢中的模式來優化數據索引的方式。例如：你有一個類型的文檔全部文檔都包含一個字段 price，而且你大多數查詢的時候都是使用比較固定的大小範圍查詢或者聚合，此時若是把這個時間分爲預索引到文檔中，而且使用terms聚合查詢會更快。

例如，你有一類型的數據以下

PUT index/_doc/1
{
  "designation": "spoon",
  "price": 13
}

而且你搜索的時候常用如下範圍查詢

GET index/_search
{
  "aggs": {
    "price_ranges": {
      "range": {
        "field": "price",
        "ranges": [
          { "to": 10 },
          { "from": 10, "to": 100 },
          { "from": 100 }
        ]
      }
    }
  }
}

此時你就應該在文檔索引時添加一個price_range字段，而且映射成keyword類型的

PUT index
{
  "mappings": {
    "_doc": {
      "properties": {
        "price_range": {
          "type": "keyword"
        }
      }
    }
  }
}
PUT index/_doc/1
{
  "designation": "spoon",
  "price": 13,
  "price_range": "10-100"
}

而後查詢、聚合的時候就使用這個新的字段來代替price的range聚合

GET index/_search
{
  "aggs": {
    "price_ranges": {
      "terms": {
        "field": "price_range"
      }
    }
  }
}

6、將標識符映射爲keyword類型

有些字段雖然是數字類型的，可是實際上並非都要映射爲數字類型。ES可以經過數字類型優化range查詢，可是terms查詢使用keyword更適合。通常的像ISBN(國際標準書號)這樣的標識符(ID)都是適合映射爲keyword而不是數字的。

7、避免使用腳本

一般，應避免使用腳本。若是絕對須要它們，則應首選painless和expressions引擎。

8、搜索舍入日期

對日期字段的查詢now一般是不可緩存的，由於匹配一直是在變化的。可是，就用戶體驗而言，切換到舍入日期一般是能夠接受的，而且具備更好地利用查詢緩存的好處。

例以下面的查詢

PUT index/_doc/1
{
  "my_date": "2016-05-11T16:30:55.328Z"
}
GET index/_search
{
  "query": {
    "constant_score": {
      "filter": {
        "range": {
          "my_date": {
            "gte": "now-1h",
            "lte": "now"
          }
        }
      }
    }
  }
}

可使用下面的查詢代替

GET index/_search
{
  "query": {
    "constant_score": {
      "filter": {
        "range": {
          "my_date": {
            "gte": "now-1h/m",
            "lte": "now/m"
          }
        }
      }
    }
  }
}

在這種狀況下，咱們四捨五入爲分鐘，所以，若是當前時間爲16:31:29，則範圍查詢將匹配my_date字段值介於15:31:00和16:31:59之間的全部內容。並且，若是多個用戶在同一分鐘內運行包含此範圍的查詢，則查詢緩存能夠幫助加快速度。用於舍入的時間間隔越長，查詢緩存能夠提供的幫助越多，可是請注意，過於激進的舍入也會損害用戶體驗。

9、強制合併只讀索引

只讀的索引將從合併到單個段中受益 。對於基於時間的索引，一般是這種狀況：只有當前時間範圍的索引才能獲取新文檔，而較舊的索引則爲只讀。

提示
不要合併正在寫入的索引。

10、預熱全局序數詞

全局序數詞是一種數據結構，用於在keyword字段上運行terms聚合 。它們被延遲加載到內存中，由於Elasticsearch不知道terms聚合中將使用哪些字段，而哪些字段則不會。您能夠經過以下所述配置映射，讓Elasticsearch在刷新時緊急加載全局序數詞：

PUT index
{
  "mappings": {
    "_doc": {
      "properties": {
        "foo": {
          "type": "keyword",
          "eager_global_ordinals": true
        }
      }
    }
  }
}

11、預熱文件緩存系統

若是從新啓動運行Elasticsearch的計算機，則文件系統緩存將爲空，所以，操做系統須要一些時間才能將索引的熱區加載到內存中，以便快速進行搜索操做。您可使用該index.store.preload設置明確告訴操做系統哪些文件應該急切地加載到內存中，具體取決於文件擴展名 。

12、使用索引排序來加快鏈接的

索引排序可能有用，以便使鏈接更快，但以稍微慢一些的索引爲代價。在索引排序文檔中閱讀有關它的更多信息。

十3、使用preference以優化緩存利用率

有多個能夠幫助提升搜索性能的緩存，例如 文件系統緩存， 請求緩存或查詢緩存。可是全部這些緩存都在節點級別維護，這意味着若是您連續兩次運行相同的請求，具備一個或多個副本，並使用默認路由算法round-robin，則這兩個請求將轉到不一樣的分片副本，從而阻止了節點級緩存的幫助。

因爲搜索應用程序的用戶一般會依次運行相似的請求（例如爲了分析索引的較窄子集），所以使用標識當前用戶或會話的首選項值能夠幫助優化緩存的使用。

十4、副本可能有助於提升吞吐量，但並不是老是能夠

除了提升彈性以外，副本還能夠幫助提升吞吐量。例如，若是您有一個單碎片索引和三個節點，則須要將副本數設置爲2，以便總共擁有3個碎片副本，以便利用全部節點。
如今，假設您有一個2碎片索引和兩個節點。在一種狀況下，副本數爲0，這意味着每一個節點都擁有一個分片。在第二種狀況下，副本數爲1，這意味着每一個節點都有兩個分片。哪一種設置在搜索效果方面效果最好？一般，每一個節點的分片總數較少的設置會更好地執行。這樣作的緣由是，它爲每一個分片提供了更多的可用文件系統緩存份額，而且文件系統緩存多是Elasticsearch的第一性能因素。同時，請注意，在單節點故障的狀況下，沒有副本的安裝會失敗，所以在吞吐量和可用性之間要進行權衡。

那麼正確的副本數是多少？若是您的集羣中有num_nodes節點，則總共有 num_primaries主要分片，而且若是您但願max_failures一次最多能處理節點故障，那麼適合您的副本數是 max(max_failures, ceil(num_nodes / num_primaries) - 1)。

十5、打開自適應副本選擇

當存在多個數據副本時，elasticsearch可使用一組稱爲自適應副本選擇的條件來根據響應時間，服務時間和包含每一個碎片副本的節點的隊列大小來選擇最佳數據副本。這能夠提升查詢吞吐量並減小大量搜索應用程序的延遲。