ElasticSearch 2.3 _ поиск для более чем 10 000 выгружаемых элементов

#performance #elasticsearch #search #limit

#Производительность #elasticsearch #Поиск #ограничение

Вопрос:

В ElasticSearch 2.3 (и в последних версиях) есть параметр index.max_result_window, который ограничивает поисковый запрос значением from size , которое меньше 10 000 записей. например

 from: 0 size: 10,000 is ok
from: 0 size: 10,001 is not ok
from: 9,000 size: 1,001 is not ok

В последней версии 7.10 в документации говорится, что это можно обойти с помощью поиска после. Однако из-за устаревших данных мне нужно что-то подобное в ES 2.3. Мне любопытно, есть ли какие-нибудь хорошие варианты?

Зачем мне это нужно? В наших данных у нас есть дочерняя / родительская иерархия. Один запрос, который мы выполняем с этими данными, заключается в определении всех уникальных родительских элементов в определенном диапазоне дат. В настоящее время мы извлекаем эту информацию с помощью aggregate запроса. т.е.

 {
  "query": { "match_all_in_date_range": {} },
  "aggs": {
    "parents": {
      "terms": {
        "field": "parentId"
      }
    }
  }
}

Что, что интересно, возвращает все родительские элементы, даже если их более 10 000. т. Е. Ограничение, похоже, не влияет index.max_result_window .

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

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

Вместо подкачки я должен изменить запрос, чтобы исключить parentIds то, что я уже получил (недостатком является то, что выполнение может занять больше времени и приведет к увеличению запроса до конца)
Для перехода к более мощному API прокрутки (который может быть более подходящим для других применений)

Но мне было бы любопытно услышать, есть ли у меня другие варианты?

1. почему бы не увеличить index.max_result_window число до большего, чем документы в вашем индексе?

2. @Nate Я опасаюсь предупреждения в документации re: «куча памяти». Это может привести к проблемам с управлением памятью. Это усугубляется тем фактом, что я не уверен, что есть верхний предел, который я могу установить. Могут храниться миллионы объектов. Случайный выбор 10 миллионов в качестве index.max_result_window может дать более высокий потолок, но в некоторых случаях я все равно могу ударить головой.

Ответ №1:

Вы можете разделить поиск на более мелкие, например, по часам или по другим полям, чтобы каждый поиск возвращал менее 10 000 результатов