Важные термины вызывают исключение CircuitBreakingException

У меня есть индекс эластичного поиска среднего размера (1,46T или ~ 1e8 документов). Он работает на 4 серверах, каждый из которых имеет 64 ГБ оперативной памяти, равномерно распределенной между эластичной и ОС (для кэширования).

Я хочу опробовать новую агрегацию значимых терминов, поэтому я запустил следующий запрос...

{
  "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] байт];

через минуту или две и, кажется, означает, что у меня недостаточно памяти.

Рассматриваемые эластичные серверы на самом деле являются виртуальными машинами, поэтому я отключил другие виртуальные машины и выделил каждому эластичному экземпляру 96 ГБ, а каждой ОС — еще 96 ГБ.

Возникла та же проблема (разные номера, заняло больше времени). У меня нет аппаратного обеспечения с более чем 192 ГБ доступной памяти, поэтому я не могу увеличить.

Разве агрегации не предназначены для использования с индексом в целом? Я делаю ошибку в отношении формата запроса?


circuit-breaker search elasticsearch
person Basic    schedule 23.04.2014    source источник

Ответы (1)


arrow_upward
5
arrow_downward

В документации для этой агрегации есть предупреждение об использовании оперативной памяти в полях с произвольным текстом для очень больших индексов [1]. На больших индексах он работает нормально для полей с меньшей кардинальностью и меньшим словарным запасом (например, хэштеги), но сочетание многих терминов с произвольным текстом и многих документов требует памяти. Вы можете посмотреть, как указать фильтр при загрузке кэша FieldData [2] для поля Body, чтобы обрезать длинный хвост низкочастотных терминов (например, частота документа ‹2), что уменьшит накладные расходы ОЗУ.

Раньше я использовал вариант этого алгоритма, в котором только выборка наиболее подходящих документов анализировалась на наличие значимых терминов, и этот подход требует меньше оперативной памяти, поскольку только первые N документов считываются с диска и размечаются (с использованием TermVectors или Analyzer). Однако на данный момент реализация в Elasticsearch полагается на кеш FieldData и ищет термины для ВСЕХ совпадающих документов.

Еще один момент: когда вы говорите, что хотите «сравнить тело указанного документа», обратите внимание, что обычный режим работы заключается в сравнении набора документов с фоном, а не только одного. Весь анализ основан на подсчете частоты документов, поэтому с набором образцов, состоящим всего из одного документа, все термины будут иметь частоту переднего плана, равную 1, что означает, что у вас будет меньше доказательств для подкрепления любого анализа.

person MarkH    schedule 23.04.2014
comment
Спасибо за совет по поводу фильтрации, и вы правы, я пропустил это предупреждение. - person Basic; 24.04.2014