suneet-s commented on a change in pull request #10848: URL: https://github.com/apache/druid/pull/10848#discussion_r589569175
########## File path: docs/querying/caching.md ########## @@ -22,63 +23,87 @@ title: "Query caching" ~ under the License. --> +You can enable caching in Apache Druid to improve query times for frequently accessed data. This topic defines the different types of caching for Druid. It describes the default caching behavior and provides guidance and examples to help you hone your caching strategy. -Apache Druid supports query result caching at both the segment and whole-query result level. Cache data can be stored in the -local JVM heap or in an external distributed key/value store. In all cases, the Druid cache is a query result cache. -The only difference is whether the result is a _partial result_ for a particular segment, or the result for an entire -query. In both cases, the cache is invalidated as soon as any underlying data changes; it will never return a stale -result. +If you're unfamiliar with Druid architecture, review the following topics before proceeding with caching: +- [Druid Design](../design/architecture.md) +- [Segments](../design/segments.md) +- [Query execution](./query-execution) -Segment-level caching allows the cache to be leveraged even when some of the underling segments are mutable and -undergoing real-time ingestion. In this case, Druid will potentially cache query results for immutable historical -segments, while re-computing results for the real-time segments on each query. Whole-query result level caching is not -useful in this scenario, since it would be continuously invalidated. +For instructions to configure query caching see [Using query caching](./using-caching.md). -Segment-level caching does require Druid to merge the per-segment results on each query, even when they are served -from the cache. For this reason, whole-query result level caching can be more efficient if invalidation due to real-time -ingestion is not an issue. +## Cache types +Druid supports the following types of caches: -## Using and populating cache +- **Per-segment** caching which stores _partial results_ of a query for a specific segment. Per-segment caching is enabled on Historicals by default. +- **Whole-query** caching which stores all results for a query. -All caches have a pair of parameters that control the behavior of how individual queries interact with the cache, a 'use' cache parameter, and a 'populate' cache parameter. These settings must be enabled at the service level via [runtime properties](../configuration/index.md) to utilize cache, but can be controlled on a per query basis by setting them on the [query context](../querying/query-context.md). The 'use' parameter obviously controls if a query will utilize cached results. The 'populate' parameter controls if a query will update cached results. These are separate parameters to allow queries on uncommon data to utilize cached results without polluting the cache with results that are unlikely to be re-used by other queries, for example large reports or very old data. +To avoid returning stale results, Druid invalidates the cache the moment any underlying data changes for both types of cache. -## Query caching on Brokers +Druid can store cache data the local JVM heap or in an external distributed key/value store. The default is a local cache based upon [Caffeine](https://github.com/ben-manes/caffeine). Maximum cache storage defaults to the minimum value of 1 GiB or the ten percent of the maximum runtime memory for the JVM with no cache expiration. See [Cache configuration](../configuration/index.md#cache-configuration) for information on how to configure cache storage. -Brokers support both segment-level and whole-query result level caching. Segment-level caching is controlled by the -parameters `useCache` and `populateCache`. Whole-query result level caching is controlled by the parameters -`useResultLevelCache` and `populateResultLevelCache` and [runtime properties](../configuration/index.md) -`druid.broker.cache.*`. +### Per-segment caching -Enabling segment-level 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 (< 5 servers). Populating segment-level caches on -the Broker is _not_ recommended for large production clusters, since when the property `druid.broker.cache.populateCache` is -set to `true` (and query context parameter `populateCache` is _not_ set to `false`), results from Historicals are returned -on a per segment basis, and Historicals will not be able to do any local result merging. This impairs the ability of the -Druid cluster to scale well. +The primary form of caching in Druid is the **per-segment cache** which stores query results on a per-segment basis. It is enabled on Historical services by default. -## Query caching on Historicals +When your queries include data from segments that are mutable and undergoing real-time ingestion, use a segment cache. In this case Druid caches query results for immutable historical segments when possible. It re-computes results for the real-time segments at query time. -Historicals only support segment-level caching. Segment-level caching is controlled by the query context -parameters `useCache` and `populateCache` and [runtime properties](../configuration/index.md) -`druid.historical.cache.*`. +For example, you have queries that frequently include incoming data from a Kafka or Kinesis stream alongside unchanging segments. Per-segment caching lets Druid cache results from older immutable segments and merge them with updated data. Whole-query caching would not be helpful in this scenario because the new data from real-time ingestion continually invalidates the cache. -Larger production clusters should enable segment-level cache population on Historicals only (not on Brokers) to avoid -having to use Brokers to merge all query results. Enabling cache population on the Historicals instead of the Brokers -enables the Historicals to do their own local result merging and puts less strain on the Brokers. +### Whole-query caching -## Query caching on Ingestion Tasks +If real-time ingestion invalidating the cache is not an issue for your queries, you can use **whole-query caching** on the Broker to increase query efficiency. The Broker performs whole-query caching operations before sending fan out queries to Historicals. Therefore Druid no longer needs to merge the per-segment results on the Broker. -Task executor processes such as the Peon or the experimental Indexer only support segment-level caching. Segment-level -caching is controlled by the query context parameters `useCache` and `populateCache` -and [runtime properties](../configuration/index.md) `druid.realtime.cache.*`. +For instance, whole-query caching is a good option when you have queries that include data from a batch ingestion task that runs every few hours or once a day. Per-segment caching would be less efficient in this case because it requires Druid to merge the per-segment results for each query, even when the results are cached. + +## Where to enable caching + +**Per-segment cache** is available as follows: + +- On Historicals, the default. Enable segment-level cache population on Historicals for larger production clusters to prevent Brokers from having to merge all query results. When you enable cache population on Historicals instead of Brokers, the Historicals merge their own local results and put less strain on the Brokers. + +- On ingestion tasks in the Peon or Indexer service. Larger production clusters should enable segment-level cache population on task execution services only to prevent Brokers from having to merge all query results. When you enable cache population on task execution services instead of Brokers, the the task execution services to merge their own local results and put less strain on the Brokers. + + Task executor services only support caches that store data locally. For example the `caffeine` cache. This restriction exists because the cache stores results at the level of intermediate partial segments generated by the ingestion tasks. These intermediate partial segments may not be identical across task replicas. Therefore task executor services ignore remote cache types such as `memcached`. + +- On Brokers for small production clusters with less than five servers. + + Do not use per-segment caches on the Broker for large production clusters. When `druid.broker.cache.populateCache` is `true` and query context parameter `populateCache` _is not_ `false`, Historicals return results on a per-segment basis without merging results locally thus negatively impacting cluster scalability. + +**Whole-query cache** is only available on Brokers. + +## Performance considerations for caching +Caching enables increased concurrency on the same system, therefore leading to noticeable performance improvements for queries on Druid clusters handling throughput for concurrent, mixed workloads. + +If you are looking to improve response time for a single query or page load, you should ignore caching. In general, response time for a single task should meet performance objectives even when the cache is cold. + +During query processing, the per-segment cache intercepts the query and sends the results directly to the Broker. This way the query bypasses the data server processing threads. For queries requiring minimal processing in the Broker, cached queries are very quick. If work done on the Broker causes a query bottleneck, enabling caching results in little noticeable query improvement. + +The largest performance gains from segment caching tend to apply to `topN` and time series queries. The impact is less for `groupBy` queries. The same applies to queries with or without joins. Review comment: > The impact is less for `groupBy` queries I think this undersells it a little bit. There is still an impact here, it's just that in some cases the bottleneck may be in merging results on the broker. Not sure exactly how to wordsmith this, but if I read this as is it sounds like there isn't much of a gain for groupBy queries ```suggestion The largest performance gains from segment caching tend to apply to `topN` and time series queries. For `groupBy` queries, if the bottleneck is in the merging phase on the broker, the impact is less. The same applies to queries with or without joins. ``` > The same applies to ... I don't think I understand this sentence ########## File path: docs/querying/caching.md ########## @@ -22,63 +23,87 @@ title: "Query caching" ~ under the License. --> +You can enable caching in Apache Druid to improve query times for frequently accessed data. This topic defines the different types of caching for Druid. It describes the default caching behavior and provides guidance and examples to help you hone your caching strategy. -Apache Druid supports query result caching at both the segment and whole-query result level. Cache data can be stored in the -local JVM heap or in an external distributed key/value store. In all cases, the Druid cache is a query result cache. -The only difference is whether the result is a _partial result_ for a particular segment, or the result for an entire -query. In both cases, the cache is invalidated as soon as any underlying data changes; it will never return a stale -result. +If you're unfamiliar with Druid architecture, review the following topics before proceeding with caching: +- [Druid Design](../design/architecture.md) +- [Segments](../design/segments.md) +- [Query execution](./query-execution) -Segment-level caching allows the cache to be leveraged even when some of the underling segments are mutable and -undergoing real-time ingestion. In this case, Druid will potentially cache query results for immutable historical -segments, while re-computing results for the real-time segments on each query. Whole-query result level caching is not -useful in this scenario, since it would be continuously invalidated. +For instructions to configure query caching see [Using query caching](./using-caching.md). -Segment-level caching does require Druid to merge the per-segment results on each query, even when they are served -from the cache. For this reason, whole-query result level caching can be more efficient if invalidation due to real-time -ingestion is not an issue. +## Cache types +Druid supports the following types of caches: -## Using and populating cache +- **Per-segment** caching which stores _partial results_ of a query for a specific segment. Per-segment caching is enabled on Historicals by default. +- **Whole-query** caching which stores all results for a query. -All caches have a pair of parameters that control the behavior of how individual queries interact with the cache, a 'use' cache parameter, and a 'populate' cache parameter. These settings must be enabled at the service level via [runtime properties](../configuration/index.md) to utilize cache, but can be controlled on a per query basis by setting them on the [query context](../querying/query-context.md). The 'use' parameter obviously controls if a query will utilize cached results. The 'populate' parameter controls if a query will update cached results. These are separate parameters to allow queries on uncommon data to utilize cached results without polluting the cache with results that are unlikely to be re-used by other queries, for example large reports or very old data. +To avoid returning stale results, Druid invalidates the cache the moment any underlying data changes for both types of cache. -## Query caching on Brokers +Druid can store cache data the local JVM heap or in an external distributed key/value store. The default is a local cache based upon [Caffeine](https://github.com/ben-manes/caffeine). Maximum cache storage defaults to the minimum value of 1 GiB or the ten percent of the maximum runtime memory for the JVM with no cache expiration. See [Cache configuration](../configuration/index.md#cache-configuration) for information on how to configure cache storage. Review comment: ```suggestion Druid can store cache data on the local JVM heap or in an external distributed key/value store. The default is a local cache based upon [Caffeine](https://github.com/ben-manes/caffeine). Maximum cache storage defaults to the minimum value of 1 GiB or the ten percent of the maximum runtime memory for the JVM with no cache expiration. See [Cache configuration](../configuration/index.md#cache-configuration) for information on how to configure cache storage. ``` ########## File path: docs/querying/using-caching.md ########## @@ -0,0 +1,91 @@ +--- +id: using-caching +title: "Using query caching" +--- + +<!-- + ~ Licensed to the Apache Software Foundation (ASF) under one + ~ or more contributor license agreements. See the NOTICE file + ~ distributed with this work for additional information + ~ regarding copyright ownership. The ASF licenses this file + ~ to you under the Apache License, Version 2.0 (the + ~ "License"); you may not use this file except in compliance + ~ with the License. You may obtain a copy of the License at + ~ + ~ http://www.apache.org/licenses/LICENSE-2.0 + ~ + ~ Unless required by applicable law or agreed to in writing, + ~ software distributed under the License is distributed on an + ~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + ~ KIND, either express or implied. See the License for the + ~ specific language governing permissions and limitations + ~ under the License. + --> + + +This topic covers how to configure services to populate and use the Druid query cache. For a conceptual overview and use cases, see [Query caching](./caching.md). For information on how to configure the caching mechanism, see [Cache configuration](../configuration/index.md#cache-configuration). + +All query caches have a pair of parameters that control the way individual queries interact with the cache: + +- `useCache` to instruct queries to use the cache for results. +- `populateCache` to instruct a query to cache its results. + +The separation of concerns, usage and population, lets you include cached results for queries on uncommon data without polluting the cache with results that are unlikely to be reused by other queries, for example, large reports or queries on very old data. + +To use caching, it must be enabled in the settings for at least one service in the runtime properties. By default, per-query cache is enabled on Historicals. For individual queries, you can control cache usage and population within the query context. + + +## Enabling query caching on Historicals +Historicals only support **segment-level** caching, which is enabled by default. To control caching on the Historical, set the `useCache` and `populateCache` runtime properties. For example, to set the Historical to both use and populate the segment cache for queries: + ``` + druid.broker.cache.useCache=true + druid.broker.cache.populateCache=true + ``` +See [Historical caching](../configuration/index.md#historical-caching) for a description of all available Historical cache configurations. + +## Enabling query caching on task executor services +Task executor services, the Peon or the Indexer, only support **segment-level** caching. To control caching on a task executor service, set the `useCache` and `populateCache` runtime properties. For example, to set the Peon to both use and populate the segment cache for queries: + +``` +druid.realtime.cache.useCache=true +druid.realtime.cache.populateCache=true +``` + +See [Peon caching](configuration/index.md#peon-caching) for a description of all available task executor service caching options. + +## Enabling query caching on Brokers +Brokers support both segment-level and whole-query result level caching. + +To control **segment caching** on the Broker, set the `useCache` and `populateCache`runtime properties. For example, to set the Broker to use and populate the segment cache for queries: +``` +druid.broker.cache.useCache=true +druid.broker.cache.populateCache=true +``` +To control **whole-query caching** on the Broker, set the `useResultLevelCache` and `populateResultLevelCache` runtime properties. For example, to set the Broker to use and populate the whole-query cache for queries: +``` +druid.broker.cache.useResultLevelCache=true +druid.broker.cache.populateResultLevelCache=true +``` +See [Broker caching](../configuration/index.md#broker-caching) for a description of all available Broker cache configurations. + +## Enabling caching in the query context +As long as one service is set to populate the cache, you can set cache options for individual queries in the query [context](./query-context.md). For example, you can `POST` a Druid SQL request to the HTTP POST API and include the context as a JSON object: Review comment: nit: ```suggestion As long as the service is set to populate the cache, you can set cache options for individual queries in the query [context](./query-context.md). For example, you can `POST` a Druid SQL request to the HTTP POST API and include the context as a JSON object: ``` ########## File path: docs/querying/using-caching.md ########## @@ -0,0 +1,91 @@ +--- +id: using-caching +title: "Using query caching" +--- + +<!-- + ~ Licensed to the Apache Software Foundation (ASF) under one + ~ or more contributor license agreements. See the NOTICE file + ~ distributed with this work for additional information + ~ regarding copyright ownership. The ASF licenses this file + ~ to you under the Apache License, Version 2.0 (the + ~ "License"); you may not use this file except in compliance + ~ with the License. You may obtain a copy of the License at + ~ + ~ http://www.apache.org/licenses/LICENSE-2.0 + ~ + ~ Unless required by applicable law or agreed to in writing, + ~ software distributed under the License is distributed on an + ~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + ~ KIND, either express or implied. See the License for the + ~ specific language governing permissions and limitations + ~ under the License. + --> + + +This topic covers how to configure services to populate and use the Druid query cache. For a conceptual overview and use cases, see [Query caching](./caching.md). For information on how to configure the caching mechanism, see [Cache configuration](../configuration/index.md#cache-configuration). + +All query caches have a pair of parameters that control the way individual queries interact with the cache: + +- `useCache` to instruct queries to use the cache for results. +- `populateCache` to instruct a query to cache its results. + +The separation of concerns, usage and population, lets you include cached results for queries on uncommon data without polluting the cache with results that are unlikely to be reused by other queries, for example, large reports or queries on very old data. + +To use caching, it must be enabled in the settings for at least one service in the runtime properties. By default, per-query cache is enabled on Historicals. For individual queries, you can control cache usage and population within the query context. Review comment: nit: When I read this, I think that if it's enabled on 1 service, it applies to all of my cluster. ```suggestion To use caching, it must be enabled in the settings for the service where caching should be enabled in the runtime properties. By default, per-segment cache is enabled on Historicals. For individual queries, you can control cache usage and population within the query context. ``` ^ it should say `per-segment`, not `per-query` (that's a little too close to whole query caching 😅 ) ########## File path: docs/querying/using-caching.md ########## @@ -0,0 +1,91 @@ +--- +id: using-caching +title: "Using query caching" +--- + +<!-- + ~ Licensed to the Apache Software Foundation (ASF) under one + ~ or more contributor license agreements. See the NOTICE file + ~ distributed with this work for additional information + ~ regarding copyright ownership. The ASF licenses this file + ~ to you under the Apache License, Version 2.0 (the + ~ "License"); you may not use this file except in compliance + ~ with the License. You may obtain a copy of the License at + ~ + ~ http://www.apache.org/licenses/LICENSE-2.0 + ~ + ~ Unless required by applicable law or agreed to in writing, + ~ software distributed under the License is distributed on an + ~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + ~ KIND, either express or implied. See the License for the + ~ specific language governing permissions and limitations + ~ under the License. + --> + + +This topic covers how to configure services to populate and use the Druid query cache. For a conceptual overview and use cases, see [Query caching](./caching.md). For information on how to configure the caching mechanism, see [Cache configuration](../configuration/index.md#cache-configuration). Review comment: nit: ```suggestion This topic covers how to configure services to populate and use the Druid query caches. For a conceptual overview and use cases, see [Query caching](./caching.md). For information on how to configure the caching mechanism, see [Cache configuration](../configuration/index.md#cache-configuration). ``` ########## File path: docs/querying/using-caching.md ########## @@ -0,0 +1,91 @@ +--- +id: using-caching +title: "Using query caching" +--- + +<!-- + ~ Licensed to the Apache Software Foundation (ASF) under one + ~ or more contributor license agreements. See the NOTICE file + ~ distributed with this work for additional information + ~ regarding copyright ownership. The ASF licenses this file + ~ to you under the Apache License, Version 2.0 (the + ~ "License"); you may not use this file except in compliance + ~ with the License. You may obtain a copy of the License at + ~ + ~ http://www.apache.org/licenses/LICENSE-2.0 + ~ + ~ Unless required by applicable law or agreed to in writing, + ~ software distributed under the License is distributed on an + ~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + ~ KIND, either express or implied. See the License for the + ~ specific language governing permissions and limitations + ~ under the License. + --> + + +This topic covers how to configure services to populate and use the Druid query cache. For a conceptual overview and use cases, see [Query caching](./caching.md). For information on how to configure the caching mechanism, see [Cache configuration](../configuration/index.md#cache-configuration). + +All query caches have a pair of parameters that control the way individual queries interact with the cache: + +- `useCache` to instruct queries to use the cache for results. +- `populateCache` to instruct a query to cache its results. + +The separation of concerns, usage and population, lets you include cached results for queries on uncommon data without polluting the cache with results that are unlikely to be reused by other queries, for example, large reports or queries on very old data. + +To use caching, it must be enabled in the settings for at least one service in the runtime properties. By default, per-query cache is enabled on Historicals. For individual queries, you can control cache usage and population within the query context. + + +## Enabling query caching on Historicals +Historicals only support **segment-level** caching, which is enabled by default. To control caching on the Historical, set the `useCache` and `populateCache` runtime properties. For example, to set the Historical to both use and populate the segment cache for queries: + ``` + druid.broker.cache.useCache=true + druid.broker.cache.populateCache=true + ``` +See [Historical caching](../configuration/index.md#historical-caching) for a description of all available Historical cache configurations. + +## Enabling query caching on task executor services +Task executor services, the Peon or the Indexer, only support **segment-level** caching. To control caching on a task executor service, set the `useCache` and `populateCache` runtime properties. For example, to set the Peon to both use and populate the segment cache for queries: + +``` +druid.realtime.cache.useCache=true +druid.realtime.cache.populateCache=true +``` + +See [Peon caching](configuration/index.md#peon-caching) for a description of all available task executor service caching options. Review comment: ```suggestion See [Peon caching](configuration/index.md#peon-caching) and [Indexer caching](configuration/index.md#indexer-caching) for a description of all available task executor service caching options. ``` ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
