Кеш запросов Elasticsearch _count

Взято из документов: https://www.elastic.co/guide/en/elasticsearch/reference/7.9/shard-request-cache.html#shard-request-cache.

По умолчанию кэш запросов будет кэшировать только результаты поисковых запросов, где size=0, поэтому попадания не будут кэшироваться, но будут кэшироваться hits.total, aggregations и suggestions.

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

Запросы по сценариям, использующие недетерминированные вызовы API, такие как Math.random() или new Date(), не кэшируются.

Однако как это работает с запросами _count? Запросы _count ведут себя почти так же, как запросы _search с size=0?

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


elasticsearch-7
person Evaldas Buinauskas    schedule 10.09.2020    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Если в документации не сказано, перейдите к источнику ;-)

В этом случае, если мы посмотрим на источник _ 1_ (т.е. класс, обрабатывающий конечную точку _count), мы видим, что на самом деле он создает SearchRequest с size: 0

    a search request
          |
          v
    SearchRequest countRequest = new SearchRequest(Strings.splitStringByCommaToArray(request.param("index")));
    countRequest.indicesOptions(IndicesOptions.fromRequest(request, countRequest.indicesOptions()));
    SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder().size(0).trackTotalHits(true);
                                                                          ^
                                                                          |
                                                                     with size 0

Кроме того, когда построение ответа, мы видим, что значение count на самом деле является значением hits.total из SearchResponse:

    builder.field("count", response.getHits().getTotalHits().value);

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

person Val    schedule 10.09.2020
comment
и opster, я явно использовал request_cache=true для моих тяжелых / дорогостоящих поисковых запросов и, согласно документу, он также кешировал бы hits, но даже после нескольких раз и попыток выполнения разных запросов я не вижу большой разницы в производительности запросов - person ; 10.09.2020
comment
Пожалуйста, дайте мне знать, что может быть причиной, одна вещь, которую я заметил, это то, что hits.total также изменился, поскольку мой индекс также получает запрос на запись, и я чувствую, что это может быть причиной, так как сегмент обновляется, а кеш становится недействительным - person ; 10.09.2020
comment
@PrernaGupta, может быть, вы хотите создать собственный вопрос для вашего конкретного случая использования? Это было не совсем то, о чем вы спрашиваете - person Val; 10.09.2020
comment
@PrernaGupta из ссылки, которой поделился OP: Cached results are invalidated automatically whenever the shard refreshes, but only if the data in the shard has actually changed., так что довольно ясно, что если у вас есть запросы на запись, кеш очищается - person Val; 10.09.2020
comment
поэтому, даже если данные не изменяются (нет нового индексированного запроса) и для параметра refresh_interval установлено значение 1 секунда (по умолчанию и то же самое в моем случае), результаты поиска будут удалены из кеша? - person ; 10.09.2020
comment
прочтите еще раз ...but only if the data in the shard has actually changed, но вы сказали, что ваш индекс получал запросы на запись - person Val; 10.09.2020
comment
Позвольте нам продолжить это обсуждение в чате. - person ; 10.09.2020