Может ли включение определенных полей изменить набор результатов эластичного поиска?

Question

У меня есть запрос ES, который возвращает 414 документов, если я исключаю определенное поле из результатов.

Если я включу это поле, количество документов уменьшится до 328.

Документы, которые получаютпропущенные значения соответствуют друг другу, и это происходит независимо от того, прокручиваю ли я результаты или запрашиваю напрямую.

Карта полей для поля, которое уменьшает результирующий набор, выглядит следующим образом:

"completion": {
     "type": "object",
     "enabled": false
}

Ничего особенного, и у меня есть другие «включенные»: ложные поля типа объекта, которые возвращают просто отличнов этом запросе.

Я протестировал несколько индексов с одинаковыми данными, чтобы исключить повреждение (надеюсь).

Этот объект 'завершения' является вложенным и игнорируемым объектом, который имеет 4 или 5 уровней вложенности, но, опять же, у меня есть другие аналогично вложенные объекты, которые прекрасно возвращаются для этого запроса.

запрос представляет собой простое совпадение терминов для 414 терминов (да, это ужасно, мы переосмысливаем нашу стратегию по этому вопросу):

  var { _scroll_id, hits } = await elastic.search({
    index: index,
    type: type,
    body: shaQuery,
    scroll: '10s',
    _source_exclude: 'account,layout,surveydata,verificationdata,accounts,scores'
  });
  while (hits && hits.hits.length) {
    // Append all new hits
    allRecords.push(...hits.hits)

    var { _scroll_id, hits } = await elastic.scroll({
      scrollId: _scroll_id,
      scroll: '10s'
    })
  }

Запрос:

"query": {
        "terms": {
            "_id": [
                "....",
                "....",
                "...."
            }
        }
}

В этом примереЯ вернусь только 328 результатов.Если я добавлю «завершение» в _source_exclude, то получу полный набор обратно.

Итак, мой вопрос: каковы сценарии, в которых включение поля в результат может ограничить поиск, когда это поле совершенно не связанок поиску.

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

Также важно, чтобы в этом поле завершения были одинаковые данные и формат как для включенных, так и исключенных записей, я не вижу ничего, что могло бы вызвать проблему.

Answer 1

Проблема была найдена, и она была неясной. То, что мы видели, было то, что он всегда терпел неудачу в одной и той же точке, и когда он был рассмотрен чуть более внимательно, появлялась одна и та же ошибка:

{ took: 158,
 timed_out: false,
 _shards:
  { total: 5,
    successful: 4,
    skipped: 0,
    failed: 1,
    failures: [ [Object] ] },
[ { shard: 0,
   index: ‘theindexname’,
   node: ‘4X2vwouIRriYbQTQcHQ_sw’,
   reason:
    { type: ‘illegal_argument_exception’,
      reason:
       ‘cannot write xcontent for unknown value of type class java.math.BigInteger’ } } ]

Хорошо, это странно, мы вообще не используем BigIntegers. Но, благодаря силе Google, эта проблема в трекере проблем эластичного поиска была обнаружена:

https://github.com/elastic/elasticsearch/pull/32888

«XContentBuilder для обработки BigInteger и BigDecimal», который является ошибкой в ​​6.3, когда поля, которые использовали BigInteger и BigDecimal, не смогли бы сериализоваться и, таким образом, перестали работать, когда была применена фильтрация источника. Мы работали 6.3.

Неясно, почему наши системы вызывают эту проблему, но обновление до 6.5 решило ее полностью.

Неясный, неясный, неясный, но решаемый благодаря настойчивости Хавьера .