ElasticSearch 查詢很慢，第一次查詢總是花費太多時間

Question

我是elasticsearch的新手，當我確實應該與多個搜索詞匹配以及匹配嵌套文檔時，我的查詢很慢，基本上第一次查詢需要7-10秒，之后由於elasticsearch緩存需要5-6秒，但是對僅匹配的非嵌套對象的查詢速度很快，即在 100 毫秒內。

我在具有 250GB RAM 和 500GB 磁盤空間的 aws 實例中運行彈性搜索，我有一個模板和 204 個索引，總共有大約 1.07 億個文檔，在單個節點中每個索引有 2 個分片索引，並且我保持了 30GB 的堆大小。

以下是我的內存使用情況：

我可以有超過 50k 的嵌套對象，所以我將長度增加到 500k，在這個嵌套對象上搜索需要太多時間，並且對嵌套以外的字段的任何 OR（應該匹配）操作也需要時間，有什么方法可以提升我對嵌套對象的查詢性能？ 還是我的配置有問題？ 有什么辦法可以讓我的第一次查詢也更快嗎？

{
  "index_patterns": [
    "product_*"
  ],
  "template": {
    "settings": {
      "index.store.type": "mmapfs",
      "number_of_shards":2,
      "number_of_replicas": 0,
      "index": {
        "store.preload": [
          "*"
        ],
        "mapping.nested_objects.limit": 500000,
        "analysis": {
          "analyzer": {
            "cust_product_name": {
              "type": "custom",
              "tokenizer": "standard",
              "filter": [
                "lowercase",
                "english_stop",
                "name_wordforms",
                "business_wordforms",
                "english_stemmer",
                "min_value"
              ],
              "char_filter": [
                "html_strip"
              ]
            },
            "entity_name": {
              "type": "custom",
              "tokenizer": "standard",
              "filter": [
                "lowercase",
                "english_stop",
                "business_wordforms",
                "name_wordforms",
                "english_stemmer"
              ],
              "char_filter": [
                "html_strip"
              ]
            },
            "cust_text": {
              "type": "custom",
              "tokenizer": "standard",
              "filter": [
                "lowercase",
                "english_stop",
                "name_wordforms",
                "english_stemmer",
                "min_value"
              ],
              "char_filter": [
                "html_strip"
              ]
            }
          },
          "filter": {
            "min_value": {
              "type": "length",
              "min": 2
            },
            "english_stop": {
              "type": "stop",
              "stopwords": "_english_"
            },
            "business_wordforms": {
              "type": "synonym",
              "synonyms_path": "<some path>/business_wordforms.txt"
            },
            "name_wordforms": {
              "type": "synonym",
              "synonyms_path": "<some path>/name_wordforms.txt"
            },
            "english_stemmer": {
              "type": "stemmer",
              "language": "english"
            }
          }
        }
      }
    },
    "mappings": {
      "dynamic": "strict",
      "properties": {
        "product_number": {
          "type": "text",
          "analyzer": "keyword"
        },
        "product_name": {
          "type": "text",
          "analyzer": "cust_case_name"
        },
        "first_fetch_date": {
          "type": "date",
          "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||yyyy-MM||yyyy"
        },
        "last_fetch_date": {
          "type": "date",
          "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||yyyy-MM||yyyy"
        },
        "review": {
          "type": "nested",
          "properties": {
            "text": {
              "type": "text",
              "analyzer": "cust_text"
            },
            "review_date": {
              "type": "date",
              "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||yyyy-MM||yyyy"
            }
          }
        }
      }
    },
    "aliases": {
      "all_products": {}
    }
  },
  "priority": 200,
  "version": 1,
}

如果我在評論文本中搜索任何特定術語，響應會花費太多時間。

{
    "_source":{
        "excludes":["review"]
    },
    "size":1,
    "track_total_hits":true,
    "query":{
        "nested":{
            "path":"review",
            "query":{
                "match":{
                    "review.text":{
                        "query":"good",
                        "zero_terms_query":"none"
                    }
                }
            }
        }
    },
    "highlight":{
        "pre_tags":[
            "<b>"
        ],
        "post_tags":[
            "</b>"
        ],
        "fields":{
            "product_name":{
                
            }
        }
    }
}

我確定我遺漏了一些明顯的東西。

Answer 1

簡單的事情： track_total_hits 應該設置為 false。 通過強制合並進行維護也可能有所幫助。

第一次和下一次請求時間之間的差異是由於elasticsearch 緩存造成的。

但是如果我的理解力很好，你可以對一個文檔有超過 50k 的評論嗎？ 如果是對的，那就太多了。 你能想到反轉你的映射嗎？ 具有將相關產品嵌入到對象中的評論索引。 它應該快得多。

PUT reviews 
{
  "mappings": {
    "properties": {
      "text": {
        "type": "text"
      },
      "review_date": {
        "type": "date",
        "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||yyyy-MM||yyyy"
      },
      "product": {
        "properties": {
          "product_number": {
            "type": "text",
            "analyzer": "keyword"
          },
          "product_name": {
            "type": "text"
          },
          "first_fetch_date": {
            "type": "date",
            "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||yyyy-MM||yyyy"
          },
          "last_fetch_date": {
            "type": "date",
            "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||yyyy-MM||yyyy"
          }
        }
      }
    }
  }
}