Queries vs Filters

Hello,

I am building an application that performs aggregations over time-series
data.

The prevailing advice for my situation seems to be that I should use
filters rather than queries to provide scope for my aggregations. The
reasons being
1) I have no need for scoring
2) I will be able to take advantage of filter caching.

However, a very common use case is for my users to scope aggregations to a
completely arbitrary time range. This means it is relatively unlikely to
receive many requests scoped to exactly the same time range.

If I implement this using a range filter, does this mean for filter
caching? Is ElasticSearch going waste time and memory building a separate
filter cache for each individual range it sees? (and should I hence use a
query?) Or is it smarter than that?

cheers
Perryn

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAFps6aCX1BDHDEhU8R7eLhOduerYgNFeAhmgH0kijrbTNZJbAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Hi ,

Yes , Elasticsearch is going to create filter cache per filter.
But then if you want to over run this behavior , you can put _cache as
false in your query as follows -

    "filter" : {
        "fquery" : {
            "query" : {
                "query_string" : {
                    "query" : "this AND that OR thus"
                }
            },
            "_cache" : false
        }

Filter cache disable -
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-query-filter.html#_caching_15

Thanks
Vineeth Mohan,
Elasticsearch consultant,
qbox.io ( Elasticsearch service provider http://qbox.io/)

On Tue, Jan 13, 2015 at 10:23 AM, Perryn Fowler perryn.fowler@gmail.com
wrote:

Hello,

I am building an application that performs aggregations over time-series
data.

The prevailing advice for my situation seems to be that I should use
filters rather than queries to provide scope for my aggregations. The
reasons being
1) I have no need for scoring
2) I will be able to take advantage of filter caching.

However, a very common use case is for my users to scope aggregations to a
completely arbitrary time range. This means it is relatively unlikely to
receive many requests scoped to exactly the same time range.

If I implement this using a range filter, does this mean for filter
caching? Is ElasticSearch going waste time and memory building a separate
filter cache for each individual range it sees? (and should I hence use a
query?) Or is it smarter than that?

cheers
Perryn

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/CAFps6aCX1BDHDEhU8R7eLhOduerYgNFeAhmgH0kijrbTNZJbAA%40mail.gmail.com
https://groups.google.com/d/msgid/elasticsearch/CAFps6aCX1BDHDEhU8R7eLhOduerYgNFeAhmgH0kijrbTNZJbAA%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAGdPd5kH29t3X26MyuSeVvxVKJsiFdw2602kGpjRh3dXb78g0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Thanks vineeth.

I may look at some sort of 'snap to grid' functionality in my app to try
and get at least some re-use of date ranges.

cheers
Perryn

On Tue, Jan 13, 2015 at 4:41 PM, vineeth mohan vm.vineethmohan@gmail.com
wrote:

Hi ,

Yes , Elasticsearch is going to create filter cache per filter.
But then if you want to over run this behavior , you can put _cache as
false in your query as follows -

    "filter" : {
        "fquery" : {
            "query" : {
                "query_string" : {
                    "query" : "this AND that OR thus"
                }
            },
            "_cache" : false
        }

Filter cache disable -
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-query-filter.html#_caching_15

Thanks
Vineeth Mohan,
Elasticsearch consultant,
qbox.io ( Elasticsearch service provider http://qbox.io/)

On Tue, Jan 13, 2015 at 10:23 AM, Perryn Fowler perryn.fowler@gmail.com
wrote:

Hello,

I am building an application that performs aggregations over time-series
data.

The prevailing advice for my situation seems to be that I should use
filters rather than queries to provide scope for my aggregations. The
reasons being
1) I have no need for scoring
2) I will be able to take advantage of filter caching.

However, a very common use case is for my users to scope aggregations to
a completely arbitrary time range. This means it is relatively unlikely to
receive many requests scoped to exactly the same time range.

If I implement this using a range filter, does this mean for filter
caching? Is ElasticSearch going waste time and memory building a separate
filter cache for each individual range it sees? (and should I hence use a
query?) Or is it smarter than that?

cheers
Perryn

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/CAFps6aCX1BDHDEhU8R7eLhOduerYgNFeAhmgH0kijrbTNZJbAA%40mail.gmail.com
https://groups.google.com/d/msgid/elasticsearch/CAFps6aCX1BDHDEhU8R7eLhOduerYgNFeAhmgH0kijrbTNZJbAA%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/CAGdPd5kH29t3X26MyuSeVvxVKJsiFdw2602kGpjRh3dXb78g0g%40mail.gmail.com
https://groups.google.com/d/msgid/elasticsearch/CAGdPd5kH29t3X26MyuSeVvxVKJsiFdw2602kGpjRh3dXb78g0g%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAFps6aAoEs2D4%3DWrCKf5LqPD-vcgDVXYFR2BCw8ux7dr8D-kvw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.