2016-01-06 00:27:52 -05:00
|
|
|
---
|
|
|
|
layout: doc_page
|
|
|
|
---
|
|
|
|
# Query Caching
|
|
|
|
|
2018-03-23 22:11:52 -04:00
|
|
|
Druid supports query result caching through an LRU cache. Results are stored as a whole or either on a per segment basis along with the
|
|
|
|
parameters of a given query. Segment level caching allows Druid to return final results based partially on segment results in the cache
|
|
|
|
and partially on segment results from scanning historical/real-time segments. Result level caching enables Druid to cache the entire
|
|
|
|
result set, so that query results can be completely retrieved from the cache for identical queries.
|
2016-01-06 00:27:52 -05:00
|
|
|
|
|
|
|
Segment results can be stored in a local heap cache or in an external distributed key/value store. Segment query caches
|
|
|
|
can be enabled at either the Historical and Broker level (it is not recommended to enable caching on both).
|
|
|
|
|
|
|
|
## Query caching on Brokers
|
|
|
|
|
|
|
|
Enabling caching on the broker can yield faster results than if query caches were enabled on Historicals for small clusters. This is
|
|
|
|
the recommended setup for smaller production clusters (< 20 servers). Take note that when caching is enabled on the Broker,
|
2016-03-15 19:09:33 -04:00
|
|
|
results from Historicals are returned on a per segment basis, and Historicals will not be able to do any local result merging.
|
2018-03-23 22:11:52 -04:00
|
|
|
Result level caching is enabled only on the Broker side.
|
2016-01-06 00:27:52 -05:00
|
|
|
|
|
|
|
## Query caching on Historicals
|
|
|
|
|
|
|
|
Larger production clusters should enable caching only on the Historicals to avoid having to use Brokers to merge all query
|
2016-03-15 19:09:33 -04:00
|
|
|
results. Enabling caching on the Historicals instead of the Brokers enables the Historicals to do their own local result
|
|
|
|
merging and puts less strain on the Brokers.
|