mirror of
https://github.com/apache/druid.git
synced 2025-02-25 20:48:05 +00:00
ec17a44e09
* Add result level caching to Brokers * Minor doc changes * Simplify sequences * Move etag execution * Modify cacheLimit criteria * Fix incorrect etag computation * Fix docs * Add separate query runner for result level caching * Update docs * Add post aggregated results to result level cache * Fix indents * Check byte size for exceeding cache limit * Fix indents * Fix indents * Add flag for result caching * Remove logs * Make cache object generation synchronous * Avoid saving intermediate cache results to list * Fix changes that handle etag based response * Release bytestream after use * Address PR comments * Discard resultcache stream after use * Fix docs * Address comments * Add comment about fluent workflow issue
26 lines
1.5 KiB
Markdown
26 lines
1.5 KiB
Markdown
---
|
|
layout: doc_page
|
|
---
|
|
# Query Caching
|
|
|
|
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.
|
|
|
|
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,
|
|
results from Historicals are returned on a per segment basis, and Historicals will not be able to do any local result merging.
|
|
Result level caching is enabled only on the Broker side.
|
|
|
|
## Query caching on Historicals
|
|
|
|
Larger production clusters should enable caching only on the Historicals to avoid having to use Brokers to merge all query
|
|
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.
|