Понимает ли оптимизатор запросов ElasticSearch, что фильтр временных интервалов `{from: null, to: null}` запрещен? - PullRequest
1 голос
/ 27 сентября 2019

Я использую ElasticSearch 1.5.2.

В Java я составляю запрос, подобный следующему:

public QueryBuilder composeQuery(
    String brand,
    String product,
    /** inclusive, nullable */
    Instant start,
    /** inclusive, nullable */
    Instant end
    ) {
    final QueryBuilder nominalQuery = QueryBuilders.boolQuery()
        .must(QueryBuilders.matchQuery("brand", brand))
        .must(QueryBuilders.matchQuery("product", product));

    final QueryBuilder withRangeApplied;
    if (start == null && end == null) {
        withRangeApplied = nominalQuery;
    } else {
        final RangeFilterBuilder rangeFilter
            = FilterBuilders.rangeFilter("timestamp");
        rangeFilter.gte(start);
        rangeFilter.lte(end);
        withRangeApplied = QueryBuilders.filteredQuery(
            nominalQuery,
            rangeFilter);
    }
    return withRangeApplied;
}

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

public QueryBuilder composeQuery(
    String brand,
    String product,
    /** inclusive, nullable */
    Instant start,
    /** inclusive, nullable */
    Instant end
    ) {
    final QueryBuilder nominalQuery = QueryBuilders.boolQuery()
        .must(QueryBuilders.matchQuery("brand", brand))
        .must(QueryBuilders.matchQuery("product", product));

    final RangeFilterBuilder rangeFilter
            = FilterBuilders.rangeFilter("timestamp");
        rangeFilter.gte(start);
        rangeFilter.lte(end);
    return QueryBuilders.filteredQuery(
        nominalQuery,
        rangeFilter);
}

Это означало бы, что мы без необходимости накладываем на наш запрос { start: null, end: null } фильтр диапазона.Создает ли это дополнительную работу для ElasticSearch?

Я использовал Profile API (для пустой базы данных ES 2.4.1 с аналогичными индексами и сопоставлениями - не честный тест, а единственный доступный мне ресурс) длязадайте несколько вопросов о запросе.

{ start: null, end: null } отображается в плане запроса как:

{
    query_type: "MultiTermQueryConstantScoreWrapper",
    lucene: "timestamp:[* TO *]",
    time: "0.0003ms",
    breakdown: {
        create_weight: 344
    }
}

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

Наличие этого «нулевого фильтра» не увеличило время перезаписи (по сравнению с «без фильтра»).

Принимая во внимание «не-null filter "удвоил время перезаписи либо" null filter ", либо" null filter ".

Исходя из этих результатов: я считаю, что" null filter "добавляет незначительное значение объем работы по сравнению с «без фильтра» (фактически добавляет ту же незначительную стоимость, что и «ненулевой фильтр»).Кто-нибудь может более убедительно подтвердить, что этот безоперационный фильтр дешев (или оптимизирован)?

...