Question

我有一个中型弹性搜索索引（1.46T或~1e8 docs）。它运行在4台服务器上，每台服务器在弹性和OS之间均匀分配64GB Ram（用于缓存）。

我想尝试新的“重要条款”聚合，所以我解雇了以下查询......

{
  "query": {
    "ids": {
      "type": "document",
      "values": [
        "xCN4T1ABZRSj6lsB3p2IMTffv9-4ztzn1R11P_NwTTc"
      ]
    }
  },
  "aggregations": {
    "Keywords": {
      "significant_terms": {
        "field": "Body"
      }
    }
  },
  "size": 0
}

哪个应该将指定的文档正文与索引的其余部分进行比较，并找到对于索引中不常见的文档有重要意义的术语。

不幸的是，这总是导致

ElasticsearchException [org.elasticsearch.common.breaker.CircuitBreakingException：数据太大，数据会大于[25741911654]字节的限制];

嵌套：UncheckedExecutionException [org.elasticsearch.common.breaker.CircuitBreakingException：数据太大，数据会大于[25741911654]字节的限制];

嵌套：CircuitBreakingException [数据太大，数据会大于[25741911654]字节的限制];

一两分钟后，似乎暗示我没有足够的记忆。

有问题的弹性服务器实际上是虚拟机，因此我关闭了其他虚拟机，每个弹性实例为96GB，每个操作系统为96GB。

发生了同样的问题（数字不同，需要更长时间）。我没有硬件可以提供超过192GB的内存，所以不能更高。

聚合是否不适合作为整体使用？我是否在查询格式方面犯了错误？

Answer 1

此聚合的文档中有关于非常大的索引[1]的自由文本字段上的RAM使用的警告。对于大型索引，它适用于具有较小词汇量的较低基数字段（例如，主题标签），但许多自由文本术语和许多文档的组合是记忆性的。您可以查看为Body字段加载FieldData缓存[2]时指定一个过滤器，以修剪低频项的长尾（例如doc frequency＆lt; 2），这将减少RAM开销。

我之前使用了此算法的变体，其中只对顶部匹配文档的样本进行了重要术语分析，并且此方法需要较少的RAM，因为只有前N个文档从磁盘读取并标记化（使用TermVectors或分析仪）。但是，目前Elasticsearch中的实现依赖于FieldData缓存并查找所有匹配文档的术语。

还有一件事 - 当你说你想“比较指定文件的正文”时，注意通常的操作方式是将一组文件与背景进行比较，而不仅仅是一组。所有分析都基于doc频率计数，因此只使用一个doc的样本集，所有术语的前景频率都为1，这意味着您没有足够的证据来强化任何分析。

重要的术语会导致CircuitBreakingException

1 个答案: