重要的术语会导致CircuitBreakingException

我有一个中等规模的弹性搜索指数(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的可用内存,所以不能更高.

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

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

我之前使用过这种算法的一种变体,其中只有顶级匹配文档的样本被分析了重要的术语,这种方法需要更少的RAM,因为只有前N个文档从磁盘中读取并被标记化(使用TermVectors或Analyzer).但是,目前Elasticsearch中的实现依赖于FieldData缓存并查找所有匹配文档的术语.

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