一、記憶體文件系統足夠的緩存 Elasticsearch嚴重依賴於文件系統緩存，以加快搜索速度。通常，您應確保至少有一半的可用記憶體分配給文件系統緩存，以便Elasticsearch可以將索引的熱區保留在物理記憶體中。二、使用更快的硬體如果搜索是受CPU限制的，那就加大CPU。ES對CPU的要求，使用 ...

一、記憶體文件系統足夠的緩存

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

二、使用更快的硬體

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

如果搜索是在I/O上受限制的話，就需要提供更多的記憶體和更快的硬碟。SSD硬碟性能優於機械硬碟，本地硬碟性能優於遠程虛擬硬碟。

三、文檔建模設計

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

四、搜索儘可能少的欄位

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

五、預索引數據

您應該利用查詢中的模式來優化數據索引的方式。例如：你有一個類型的文檔所有文檔都包含一個欄位 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"
      }
    }
  }
}

六、將標識符映射為keyword類型

有些欄位雖然是數字類型的，但是實際上並不是都要映射為數字類型。ES能夠通過數字類型優化range查詢，但是terms查詢使用keyword更適合。一般的像ISBN(國際標準書號)這樣的標識符(ID)都是適合映射為keyword而不是數字的。

七、避免使用腳本

通常，應避免使用腳本。如果絕對需要它們，則應首選painless和expressions引擎。

八、搜索舍入日期

對日期欄位的查詢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之間的所有內容。而且，如果多個用戶在同一分鐘內運行包含此範圍的查詢，則查詢緩存可以幫助加快速度。用於舍入的時間間隔越長，查詢緩存可以提供的幫助越多，但是請註意，過於激進的舍入也會損害用戶體驗。

九、強制合併只讀索引

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

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

十、預熱全局序數詞

全局序數詞是一種數據結構，用於在keyword欄位上運行terms聚合。它們被延遲載入到記憶體中，因為Elasticsearch不知道terms聚合中將使用哪些欄位，而哪些欄位則不會。您可以通過如下所述配置映射，讓Elasticsearch在刷新時緊急載入全局序數詞：

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

十一、預熱文件緩存系統

如果重新啟動運行Elasticsearch的電腦，則文件系統緩存將為空，因此，操作系統需要一些時間才能將索引的熱區載入到記憶體中，以便快速進行搜索操作。您可以使用該index.store.preload設置明確告訴操作系統哪些文件應該急切地載入到記憶體中，具體取決於文件擴展名。

十二、使用索引排序來加快連接的

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

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

有多個可以幫助提高搜索性能的緩存，例如文件系統緩存，請求緩存或查詢緩存。但是所有這些緩存都在節點級別維護，這意味著如果您連續兩次運行相同的請求，具有一個或多個副本，並使用預設路由演算法round-robin，則這兩個請求將轉到不同的分片副本，從而阻止了節點級緩存的幫助。

由於搜索應用程式的用戶通常會依次運行類似的請求（例如為了分析索引的較窄子集），因此使用標識當前用戶或會話的首選項值可以幫助優化緩存的使用。

十四、副本可能有助於提高吞吐量，但並非總是可以

除了提高彈性之外，副本還可以幫助提高吞吐量。例如，如果您有一個單碎片索引和三個節點，則需要將副本數設置為2，以便總共擁有3個碎片副本，以便利用所有節點。
現在，假設您有一個2碎片索引和兩個節點。在一種情況下，副本數為0，這意味著每個節點都擁有一個分片。在第二種情況下，副本數為1，這意味著每個節點都有兩個分片。哪種設置在搜索效果方面效果最好？通常，每個節點的分片總數較少的設置會更好地執行。這樣做的原因是，它為每個分片提供了更多的可用文件系統緩存份額，並且文件系統緩存可能是Elasticsearch的第一性能因素。同時，請註意，在單節點故障的情況下，沒有副本的安裝會失敗，因此在吞吐量和可用性之間要進行權衡。

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

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

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

ES集群調整搜索速度