Question

我们使用远程方法的reindex将2.4群集升级到6.2群集。在2.4中，我们使用了catch-all _all字段来执行搜索，并且我们所有查询的响应时间都在500毫秒以下。

在6.2中，_all字段不再适用于新索引，因此我们最终创建了一个名为all的新文本类型字段，如"all": {"type": "text"}并设置copy_to在我们所有其他领域（约2000个）。但是现在，对这个新的全能字段all的搜索所花费的时间比2.4 _all字段上的搜索长2到10倍。（在执行查询之前，我们刷新了两个集群上的缓存。）

两个集群都是单个数据中心，同一AWS区域上的单节点8GB内存，通过弹性云托管。两个索引具有相同数量的文档（大约6M）并且具有大约150个Lucene段文件。

有关原因的任何线索？

UPDATE：两个索引都返回没有catch-all字段的文档，即它们不存储catch-all字段。

以下是一个示例查询和响应：

$ curl --user "$user:$password" \
> -H 'Content-Type: application/json' \
> -XGET "$es/$index/$mapping/_search?pretty" -d'
> {
>     "size": 1,
>     "query" : {
>         "match" : { "all": "sherlock" }
>     }
> }
> '
{
  "took" : 42,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "failed" : 0
  },
  "hits" : {
    "total" : 28133,
    "max_score" : 2.290815,
    "hits" : [ {
      "_index" : "sherlock",
      "_type" : "doc",
      "_id" : "513763",
      "_score" : 2.290815,
      "_source" : {
        "docid" : 513763,
        "age" : 115,
        "essay" : "Has Mr. Sherlock Holmes?",
        "name" : {
          "last" : "Pezzetti",
          "first" : "Lilli"
        },
        "ssn" : 834632279
      }
    } ]
  }
}

更新2 ：我忘了提到的另一点是2.4群集当前正被暂存应用程序使用，该应用程序每隔几分钟就会向其发送一些查询。这会带来其他因素如操作系统缓存吗？

Answer 1

您是否存储了_all字段并将其恢复为原始设置？你现在还回来吗？如果你没有，那么现在你做的是你看到的响应开销，而不是搜索开销。基本上你应该在你的回复中省略那个字段（来自你的_source），如果你不需要它（以及任何其他字段）。

检查_source filtering了解更多

升级后Elasticsearch catch-all字段缓慢

1 个答案: