Indeed SearchType.COUNT would work great as it would ensure that a single
round-trip is performed. Other than that, if you want to filter content on
which you want to aggregate, make sure to put it in a filtered query as
opposed to a filter aggregation: since aggregations are executed on every
matching document, this would evaluate the filter against every document
(since the default query, match_all, matches them all) while if you put the
filter in the query, elasticsearch would be able to quickly skip over
non-matching documents.
Hm, Interesting.
I currently make one request that performs multiple aggregations. All my
aggregations have a filter aggregation as the top level item (all are
different).
Do you think it would be better performance executing multiple requests
with a filterQuery instead?
On Wednesday, 18 June 2014 17:09:32 UTC+1, Adrien Grand wrote:
Indeed SearchType.COUNT would work great as it would ensure that a single
round-trip is performed. Other than that, if you want to filter content on
which you want to aggregate, make sure to put it in a filtered query as
opposed to a filter aggregation: since aggregations are executed on every
matching document, this would evaluate the filter against every document
(since the default query, match_all, matches them all) while if you put the
filter in the query, elasticsearch would be able to quickly skip over
non-matching documents.
Mind you, I only have 10's of thousands of documents I am aggregating
over... maybe the perf difference is negligible?
On Wednesday, 18 June 2014 17:21:26 UTC+1, mooky wrote:
Hm, Interesting.
I currently make one request that performs multiple aggregations. All my
aggregations have a filter aggregation as the top level item (all are
different).
Do you think it would be better performance executing multiple requests
with a filterQuery instead?
On Wednesday, 18 June 2014 17:09:32 UTC+1, Adrien Grand wrote:
Indeed SearchType.COUNT would work great as it would ensure that a single
round-trip is performed. Other than that, if you want to filter content on
which you want to aggregate, make sure to put it in a filtered query as
opposed to a filter aggregation: since aggregations are executed on every
matching document, this would evaluate the filter against every document
(since the default query, match_all, matches them all) while if you put the
filter in the query, elasticsearch would be able to quickly skip over
non-matching documents.
If the union of the documents that match all your filters is much smaller
than your whole dataset then it would indeed help to run separate queries
(potentially in a multi search call).
Mind you, I only have 10's of thousands of documents I am aggregating
over... maybe the perf difference is negligible?
On Wednesday, 18 June 2014 17:21:26 UTC+1, mooky wrote:
Hm, Interesting.
I currently make one request that performs multiple aggregations. All my
aggregations have a filter aggregation as the top level item (all are
different).
Do you think it would be better performance executing multiple requests
with a filterQuery instead?
On Wednesday, 18 June 2014 17:09:32 UTC+1, Adrien Grand wrote:
Indeed SearchType.COUNT would work great as it would ensure that a
single round-trip is performed. Other than that, if you want to filter
content on which you want to aggregate, make sure to put it in a filtered
query as opposed to a filter aggregation: since aggregations are executed
on every matching document, this would evaluate the filter against every
document (since the default query, match_all, matches them all) while if
you put the filter in the query, elasticsearch would be able to quickly
skip over non-matching documents.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.