Я использую 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 "добавляет незначительное значение объем работы по сравнению с «без фильтра» (фактически добавляет ту же незначительную стоимость, что и «ненулевой фильтр»).Кто-нибудь может более убедительно подтвердить, что этот безоперационный фильтр дешев (или оптимизирован)?